From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <43E78698.9020103@lanl.gov> Date: Mon, 6 Feb 2006 10:25:44 -0700 From: Ronald G Minnich User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) MIME-Version: 1.0 To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] Venti and the hash / public key in plan9 References: <45219fb00602060836q7aa16bf7q@mail.gmail.com> <45219fb00602060916p5b354e0r@mail.gmail.com> In-Reply-To: <45219fb00602060916p5b354e0r@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Topicbox-Message-UUID: f4a21dcc-ead0-11e9-9d60-3106f5b1d025 Llu=EDs Batlle wrote: > 2006/2/6, Russ Cox : >=20 >>> Anyway I've don't >>>understood what does Venti do when a hash is found in the stored >>>blocks, and the contents of the blocks are different (the >>>low-probability case). I imagine there is some code which does not >>>give a data-loss... Can someone give a small explanation about that? >> >>It responds to the write RPC with an error. >=20 > So what should manage that error? The application? Maybe it try a > different write size? > In fact there should be another application layer between 9p and the > RPC for venti, isn't it? (which?) Lluis, in a system like this, if two blocks have the same hash, they are=20 by definition the same. It therefore makes no sense to say 'what if the=20 data is different'. The data is not, from the viewpoint of venti. So a=20 write of a block with hash X, when a block of hash X already exists in=20 venti, is an error. It's the same data. So you get an error on the write=20 RPC. So your real question is, 'what if a block B' has the same hash as a=20 block B? What does venti do?" It returns B, not B', as it should. That's=20 the underlying rule. That's one reason you want a long hash, with a good=20 design :-) Now, let's see if I got this right :-) ron