From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 20 Jan 2009 17:43:44 -0800 From: "Roman V. Shaposhnik" In-reply-to: <87b90d8b1794b7b63737e9b0815d1288@quanstro.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-id: <1232502224.11686.63.camel@goose.sun.com> MIME-version: 1.0 Content-type: text/plain Content-transfer-encoding: 7BIT References: <87b90d8b1794b7b63737e9b0815d1288@quanstro.net> Subject: Re: [9fans] Changelogs & Patches? Topicbox-Message-UUID: 838236a0-ead4-11e9-9d60-3106f5b1d025 On Tue, 2009-01-20 at 18:36 -0500, erik quanstrom wrote: > > > > Got it. However, I'm still not fully convinced there's a definite edge > > > > one way or the other. Don't get me wrong: I'm not trying to defend > > > > ZFS (I don't think it needs defending, anyway) but rather I'm trying > > > > to test my mental model of how both work. > > > > > > if you end up rewriting a free block in zfs, there sure is. you > > > can't decide which one is correct. > > > > You don't have to "decide". You get use generation # for that. > > > > what generation number? I'm talking about a field in each ZFS block pointer. The field is actually called "birth txg", but I thought alluding to VtEntry.gen would make it easier to understand what I had in mind. > are there other things that your argument > depends on that you haven't mentioned yet? Fair question. It depends on at leas cursory reading of ZFS-on-disk specification. I felt uneasy in this conversation precisely because I had a very vague recollection of Venti/Fossil paper. I guess it cuts both ways: http://opensolaris.org/os/community/zfs/docs/ondiskformat0822.pdf > > term% fossil/fossil -f /tmp/fossil.bin > > fsys: dialing venti at net!$venti!venti > > warning: connecting to venti: Connection refused > > well, there's your problem. you corrupted > the cache, not the venti store. (you have no > venti store in this example.) I was specifically referring to a "normal operations" to conjure an image of a typical setup of fossil+venti. In such a setup a corrupted block from a fossil partition will go undetected and could end up being stored in venti. At that point it will become venti "problem". > i should have been more clear that venti does the > checking. there are many things that fossil doesn't > do that it should. Sure, but I can't really use venti without using fossil (again: we are talking about a typical setup here not something like vac/vacfs), can I? If I can NOT than fossil becomes a weak link that can let corrupted data go undetected all the way to a venti store. This is quite worrisome for me. At least compared to ZFS it is. Thanks, Roman.