From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <43E78582.3060908@asgaard.homelinux.org> Date: Mon, 6 Feb 2006 18:21:06 +0100 From: =?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?= User-Agent: Thunderbird 1.5 (Windows/20051201) 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: f486a268-ead0-11e9-9d60-3106f5b1d025 Llu=EDs Batlle wrote: > 2006/2/6, Russ Cox : >>> Hi... I've been reading the papers about Venti. There is an >>> explanation about the low probability of the repetition of a hash >>> string in a normal-sized nowadays hard disk. 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. > 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?) Isn't the probability of such hash collisions "pretty" low ? (lower than the probability of hardware errors passing through undetected )