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 18:49:31 -0500 (EST), "Matt W. Benjamin" 
<matt%linuxbox.com@localhost> wrote:
Subject: Re: Lost file-system story
> 
> Why would sync not be effective under MNT_ASYNC?  Use of sync is not
> required to lead to consistency expect with respect to an arbitrary
> point in time, but I don't think anyone ever believed otherwise.
> However, there should be no question of metadata never being written
> out if sync was run?

Well sync(2) _could_ be effective even in the face of MNT_ASYNC, though
I'm not sure it will, or indeed even should be required to, have a
guaranteed ongoing beneficial affect to the on-disk consistency of
filesystem that was mounted with MNT_ASYNC while activity continues to
proceed on the filesystem.

I.e. I don't expect sync(2) to suddenly enforce order on the writes that
it schedules to a MNT_ASYNC-mounted filesystem.  The ordering _may_ be a
natural result of the implementation, but if it's not then I wouldn't
consider that to be a bug, and I certainly wouldn't write any
documentation that suggested it might be a possible outcome.  MNT_ASYNC
means, to me at least, that even sync(2) can get away with doing writes
to a filesystem mounted with that flag in an order other than one which
would guarantee on-disk consistency to a level where fsck could repair
it.

I.e. sync(2) could possibly make things worse for MNT_ASYNC mounted
filesystems before it makes them better, and I don't see how that could
be considered to be a bug.

I do agree that IFF the filesystem is made quiescent, AND all writes
necessary and scheduled by sync(2) are allowed to come to completion,
THEN the on-disk state of an MNT_ASYNC-mounted filesystem must be
consistent (and all data blocks must be flushed to the disk too).

However if you're going to go to that trouble (i.e. close all files open
on the MNT_ASYNC-mounted filesystem and somehow prevent any other file
operations of any kind on that filesystem until such time that you think
the sync(2) scheduled writes are all done), then it should be just as
easy, if not even easier, to do a "mount -u -r" (or "mount -u -o
noasync", or even "umount"), in which case you'll not only be sure that
the filesystem is consistent and secure, but you'll know when it reaches
this state (i.e. you won't have to guess about when sync(2)'s scheduled
work completes).

-- 
                                                Greg A. Woods
                                                Planix, Inc.

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

Attachment: pgp1_ZhS_f9pT.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index