Re: [9fans] plan 9 ports to unix (including libdraw)

["Russ Cox" <rsc@swtch.com>]

> I'm still waiting for fossil to settle down.  I haven't yet been able
> to shutdown a fossil gracefully (with "fsys sync", a pause, then "fsys
> halt") and come back up without any missing blocks.

The missing block thing is a red herring, I think.
I suspect that flchk misses some blocks that are actually
reachable, and that we leak maybe a block or two per snapshot.
Either way it hasn't seemed major enough to make time to
track it down.

What I really like about fossil is that once the data
hits Venti you know it's not going to be corrupted by
bugs in Fossil.  Almost all of the fossil development
that I did was done using fossil itself as my file server.
When I trashed the write buffer, I always had the score
from the last archival snapshot (I took archival snapshots
before rebooting with any new code) to save my neck.

That alone makes me feel good enough about it to use for
real data.  Especially now that my Venti server is mirrored
across two different-model 200GB IDE drives.

> I've had good experience with Ken's file server, though perhaps the
> best part of that is automatic nightly dumps to stable, write-once
> optical storage.

Right, this is how I feel about the Venti archives.

> I haven't had bad experiences with Linux file systems; I was saying
> that I'd be queasy to swap out a Plan 9 kernel and replace it with a
> Linux kernel.  I can't see how replacing a relatively small and
> well-written kernel with a large and sprawling kernel written by a
> cast of hundreds, if not thousands, could improve reliability,
> robustness or correctness of the kernel.

I have talked to a few people who independently claim that if you
start Linux running lots of fs accesses and then pull the plug,
fsck never fully recovers, even in ext3.  I haven't verified these
claims, but I trust the people who told me.

Russ