From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <9384d5b4e8e8e41b43bb7a8714b83dc2@quanstro.net>
To: 9fans@9fans.net
From: erik quanstrom <quanstro@quanstro.net>
Date: Wed,  7 Jan 2009 20:11:13 -0500
In-Reply-To: <1231375012.5141.205.camel@goose.sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Changelogs & Patches?
Topicbox-Message-UUID: 7bd2cd66-ead4-11e9-9d60-3106f5b1d025

> Lets see. May be its my misinterpretation of what venti does. But so
> far I understand that it boils down to: I give venti a block of any
> length, it gives me a score back. Now internally, venti might decide

just a clarification.  this is done by the client.  from venti(6):
       Files and Directories
          Venti accepts blocks up to 56 kilobytes in size. By conven-
          tion, Venti clients use hash trees of blocks to represent
          arbitrary-size data files. [...]


> But even in the former case I don't see how the corruption could be
> possible. Please elaborate.

i didn't say there would be corruption.  i assumed corruption
and outlined how one could recover the maximal set of data
and have a consistent fs (assuming the damage doesn't cut a
full strip across all backups) by simply picking a good
block at each lba from the available damaged and/or incomplete
backups, which may originate at different times.  (russ was the
first that i know of to put this into practice.)

in the case of zfs, my claim is that since zfs can reuse blocks, two
vdev backups, each with corruption or missing data in different places
are pretty well useless.

- erik