tech-kern archive

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

Re: Lost file-system story



At Tue, 6 Dec 2011 12:44:16 -0500, Donald Allen 
<donaldcallen%gmail.com@localhost> wrote:
Subject: Re: Lost file-system story
> 
> much more clear. When I read this before the fun started, I took it to
> mean, perhaps unjustifiably, what I know to be true -- there is some
> non-zero probability that fsck of an async file-system will not be
> able to verify and/or restore the filesystem to correctness  after a
> crash. You are saying that the probability, in the case of NetBSD, is
> 1. If that's true, that there's no periodic sync, I would say that's
> *really* a mistake. It should be there with a knob the administrator
> can turn to adjust the sync frequency.

Just to be clear:  There is such a knob, or rather binary switch.  It's
called umount(2).

sync(2) might work too, but I seem to vaguely remember something about
it not working for async-mounted filesystems, and some obscure reason
why it wouldn't/couldn't work for them, though that doesn't seem logical
to me any more.  sync(2) should, IMHO, even go so far as to cause the
dirty flag to be cleared on the disk once all the writes to flush all
necessary updates have completed (and assuming of course that no further
changes of any kind are made to the filesystem after sync(2) scheduled
all the writes, and assuming of course that writes cached in the storage
interface controller or in the drive controller will be written out in
order.

In theory "mount -u -r" should work too, but then there's PR#30525.

Steve Bellovin asked a question some time ago on netbsd-users about why
umount(2) works, but "mount -u -r" doesn't, and to the best of my
understanding it hasn't been answered yet (though mention was made of a
possible fix to be found in FreeBSD, followed by some musings on how
hard it is to find and use such fixes in the diverging code bases of
FreeBSD and NetBSD).

Perhaps sync(2) will fail for async-mounted filesystems, or even without
MNT_ASYNC, for the same reason that "mount -u -r" fails, though that's
pure speculation based on my vague ideas, and is not based on anything
in the code.  The question was asked in PR#30525 about "mount -u -r"
vs. filesystems mounted with MNT_SYNC, but nobody knew if that would
make any significant difference or not (and I would naively suspect not).

Perhaps the superblock should also record when a filesystem has been
mounted with MNT_ASYNC so that fsck(8) can print a warning such as:

"FS is dirty and was mounted async.  Demons will fly out of your nose"

-- 
                                                Greg A. Woods
                                                Planix, Inc.

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

Attachment: pgp5N1iZw4NAJ.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index