9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: ron minnich <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] boot error walking
Date: Sat, 14 Feb 2004 08:45:42 -0700	[thread overview]
Message-ID: <Pine.LNX.4.44.0402140832360.5703-100000@maxroach.lanl.gov> (raw)
In-Reply-To: <00a701c3f2cd$11e93720$8201a8c0@cc77109e>

On Sat, 14 Feb 2004, Bruce Ellis wrote:

> often kfs is enough.  and it co-exists with fossil/venti.  venti
> fkd over a few of my files last week.  some scrambled
> message about a mismatch obscured by other windows
> being updated.  fortunately i could recreate both of them
> easy.  a pity if had been /bin/rc.
>
> i think there are some concurrency issues (in f/v).

Was it venti that really did that? Or was it some f/v miscommunication?

I no longer trust fossil after my last experience, but I do trust venti.
Venti saved my neck. It seems from what I read here and have experienced
that venti is rock solid, fossil less so. If you're telling me venti is
also less solid, then I'm worried. Maybe it's time to just revive kfs with
long file names.

For me anyway, a file system is not a real file system until (at least)
you can cycle power in the middle of each and every operation without ill
effects, recovery is comprehensible and complete, and finally improper
operation (e.g.  letting the disk fill up) should not result in an
unbootable machine. By these standards fossil is a very interesting
experiment but not exactly a file system; it has a long way to go to equal
what I'm used to in the Unix/Linux world. It's quite nice, with the
snapshots etc., but not to be trusted. People tell me fossil is ok if you
treat it nice, but in the real world I want to be able to be mean to the
file system and have it survive anyway.

Venti on the other hand, based on everything I've seen, is to be trusted.
I hope that is true.

The concurrency point is interesting. Another thing I wonder about is
order of operations. Fossil is a set of processes. Most file systems I've
worked with depend on controlling the ordering of disk writes for data vs.
metadata I/O. "Smart" disk drives that reorder disk writes have been known
to play havoc with file systems. I keep wondering if the kinds of
guarantees on I/O ordering that a file system needs for its activities can
be met outside a kernel? It just seems easy for fossil to get confused
about what is where and when, and then all is lost. Just wondering.

ron



  reply	other threads:[~2004-02-14 15:45 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-13 14:34 Tiit Lankots
2004-02-13 13:46 ` andrey mirtchovski
2004-02-14  4:02   ` boyd, rounin
2004-02-14  3:32 ` boyd, rounin
2004-02-14  7:33   ` Bruce Ellis
2004-02-14 15:45     ` ron minnich [this message]
2004-02-14 16:00       ` Charles Forsyth
2004-02-14 16:10       ` David Presotto
2004-02-14 15:26         ` andrey mirtchovski
2004-02-14 16:12       ` David Presotto
2004-02-14 16:18         ` Bruce Ellis
2004-02-15  0:14           ` Christopher Nielsen
2004-02-15  0:22             ` boyd, rounin
2004-02-15  2:13             ` ron minnich
  -- strict thread matches above, loose matches on Subject: below --
2004-02-17 23:21 Herbert B. Hancock
2004-02-13 12:43 Tiit Lankots
2004-02-13 12:28 Herbert B. Hancock
2004-02-13 13:36 ` andrey mirtchovski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0402140832360.5703-100000@maxroach.lanl.gov \
    --to=rminnich@lanl.gov \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).