tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Lost file-system story



On Sun, Dec 11, 2011 at 06:53:26PM -0800, Greg A. Woods wrote:
 > > You would be sure if you'd read my posts carefully. The difference is
 > > whether the probability of an async-mounted filesystem is near zero or
 > > near one.
 > 
 > I think perhaps the misunderstanding between you and everyone else is
 > because you haven't fully appreciated what everyone has been trying to
 > tell you about the true meaning of "async" in Unix-based filesystems,
 > and in particular about NetBSD's current implementation of Unix-based
 > filesystems, and what that all means to implementing algorithms that can
 > relibably repair the on-disk image of a filesystem after a crash.

No, as far as I can tell he understands perfectly well; he just
doesn't consider the behavior acceptable.

It appears that currently a ffs volume mounted -oasync never writes
back metadata. I don't think this behavior is acceptable either.

The fact that mounting -oasync violates assumptions made by fsck_ffs,
with the result that fsck may not be able to recover after a crash
(either without making a huge mess in lost+found, or not at all) is
secondary at the moment, because in the absence of the previous
glaring bug it's impossible to even estimate what the probability of
it choking is.

(Note that with ext2 on Linux from time to time fsck will not be able
to recover after a crash and make a huge mess in lost+found. It
never happened all that often and is probably less common now after 15
years or so of incremental work on e2fsck.)

 > DO NOT confuse any Linux-based filesystem with any Unix-based
 > filesystem.  They may have nearly identical semantics from the user
 > programming perspective (i.e. POSIX), but they're all entirely different
 > under the hood.
 > 
 > Unix-based filesystems (sans WABPL, and ignoring the BSD-only LFS) have
 > never ever Ever EVER given any guarantee about the repariability of the
 > filesystem after a crash if it has been mounted with MNT_ASYNC.

What on earth do you mean by "Unix-based filesystems" such that this
statement is true?

 > Perhaps this sentence from McKusick's memo about fsck will help you to
 > understand:  "fsck is able to repair corrupted file systems using
 > procedures based upon the order in which UNIX honors these file system
 > update requests."  This is true for all Unix-based filesystems.

No, it is true for ffs, and possibly for our ext2 implementation
(which shares a lot of code with ffs) but nothing else.

-- 
David A. Holland
dholland%netbsd.org@localhost


Home | Main Index | Thread Index | Old Index