tech-kern archive

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

Re: Lost file-system story



At Mon, 12 Dec 2011 15:08:40 +0000, David Holland 
<dholland-tech%netbsd.org@localhost> wrote:
Subject: Re: Lost file-system story
> 
> On Sun, Dec 11, 2011 at 06:53:26PM -0800, Greg A. Woods wrote:
> 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.

I agree there are conditions and operations which _should_ guarantee
that the on-disk state of the filesystem is identical to what the user
perceives and thus that the filesystem is 100% consistent and secure.

It seems umount(2) works to make this guarantee, for example.

The two other most important of these that come to mind are:

        mount -u -r /async-mounted-fs

and

        mount -u -o noasync /async-mounted-fs

It is my understanding that neither works at the moment, and that this
is a known and reported and accepted bug, as I outlined in an earlier
post to this thread.

I think sync(2) should probably also work, but _only_ if the filesystem
is made entirely quiescent from before the time sync() is called, and
until after the time all the writes it has scheduled have completed, all
the way to the disk media.  (and of course once activity starts on the
filesystem again, all guarantees are lost again)

It might be nice if sync(2) could schedule all the needed writes to
happen in an order which would ensure consistency and repairability of
the on-disk image at any given time, but I'm guessing this might be too
much to ask, at least without some more significant effort.

However without enforcing the "synchronous" ordering of writes, sync(2)
is effectively useless for the purposes Mr. Allen appears to have,
though perhaps his level of risk tollerance would still make it useful
to him while others of us would still be unable to tolerate its dangers
in any scenarios where we were not prepared to use newfs to recover.

Besides, the only way I know to guarantee a filesystem remains quiescent
is to unmount it, so if you do that first then there's nothing for
sync(2) to do afterwards, so nothing new to implement.  :-)


>  > 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?

I mean exactly what it sounds like -- nothing more.

Having almost no knowledge about ext2 or any other non-Unix-based
filesystems, I'm trying to be careful to avoid making any claims about
those non-Unix-based filesystems.

I included FFS as a Unix-based filesystem because I know for sure that
it shares many of the attributes of the original Unix filesystems with
respect to the issues surrouding MNT_ASYNC.

>  > 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.

Well, if you follow what I by Unix-based filesystems, and you ignore LFS
and options like WABPL, as I've said, then I believe it is entirely true
since within my definition that leaves just FFS, and.....

V7, though it didn't have MNT_ASYNC, would suffer the same as if
MNT_ASYNC were implemented for it -- indeed I'm guessing that NetBSD's
reimplementation of v7fs will have the same problems with MNT_ASYNC.

As I say, I don't know enough about the non-Unix-based filesystems in
NetBSD, such as those compatible AmigaDOS, Acorn, Windows NT, or even
MS-DOS, to know if they would be adversely affected by MNT_ASYNC.
Indeed I'm not even sure if they all have reasonable filesystem repair
tools (NetBSD has none, except maybe for ext2fs and msdos, though in my
experience NetBSD's MS-DOS filesystem implementation is very fragile and
it does not have a truly useful fsck_msdos, even without trying to use
MNT_ASYNC with it).  SysVbfs may suffer too, but I don't know enough
about it either despite it being by definition Unix-based, and we don't
have an fsck for it in any case.

I'd also be guessing about EFS, and I'm not sure I'd categorize it as
Unix-based any more than I do LFS.

-- 
                                                Greg A. Woods
                                                Planix, Inc.

<woods%planix.com@localhost>       +1 250 762-7675        http://www.planix.com/

Attachment: pgpLSfszPjVGO.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index