From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] Fossil; is the time right? From: "Russ Cox" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Fri, 14 Mar 2003 14:00:35 -0500 Topicbox-Message-UUID: 80b6f112-eacb-11e9-9e20-41e7f4b1d025 cross@math.psu.edu: > Okay, I'm going to be setting up a new file server for home in the next > week or so. What's the official recommendation at this point: Should I > go with Fossil, or with the current fileserver? Is Fossil considered > stable enough? Is the on-disk format likely to change a lot? (Not a > huge deal, but something that would necessitate inconvenient recoveries > from venti.) When does Bell Labs plan to become fossilized? Thanks. comparing pseudo-worm old fs with fossil is a no-brainer -- use fossil. if the on-disk format changes, you only use snapshots not dumps. the on-venti format will not change. hence all you have to do is reinitialize your write buffer. i've changed the on-disk format a handful of times but never had to restart my file system. you make it sounds like ``recoveries from venti'' is a big deal. it's not. it's just a format command and then you're up and running again. look at the wiki walkthrough -- it does one of these as an example. rog@vitanuova.com: > it's been stable for me... for all of two days, running it on my > laptop :-). it's survived lots of rebooting, and kernel crashing, > with no probs, as advertised. i've had similar experience, and i've been running it since november. the only time i lost a significant amount of data was when i zeroed the first few megabytes of the disk while trying to set up a second fossil server elsewhere (oops). and even that was just old snapshots. > it seems quite a lot slower than kfs (a naive measurement showed that > it read 15MB 50% slower than kfs). presumably this will change if > it gets a read cache. read performance is slow but not sluggish. there's a lot of room for improvement. reads from the in-memory cache are about the same speed as kfs. if you give your fossil more memory cache (the default is 1000 blocks, typically 8MB, and can be set with the -c option to open) it gets better. kfs's reads from disk are obviously faster than fossil's reads from venti. a read cache will probably help there. > i have one query about its integrity: soft updates preserve the > integrity of the write buffer; venti is log structured, and has no > problem with being killed. > > however, i wonder if it's possible to "lose" a block in between fossil > and venti if one is running venti -w. e.g. fossil writes a block to > venti, marks it as archived, reuses that block, and then the machine > crashes before venti has got around to actually writing the block. > > how does fossil guard against such an eventuality? when running venti -w, there is a sync rpc that doesn't return until all buffered blocks are on disk. fossil does not mark a block as archived and does not update any pointers to that block until it has synced to make sure the block is on disk. i was very paranoid about this. --- the main gotcha in the current fossil code is that there is no warning when the write buffer is getting full, and no easy way to check how much space is actually used. 'fossil/flchk -f |[2] grep used' will do most of this but it's not convenient. i need to make this better.