At Mon, 12 Dec 2011 16:15:56 -0500, Greg Troxel <gdt%ir.bbn.com@localhost>
wrote:
Subject: Re: Lost file-system story
>
> Donald came here not complaining, just surprised that things were
> somewhat worse than one would have expected. And he's right - "async"
> doesn't mean "and data might never be written indefinitely", just that
> there are no ordering or completion guarantees.
Are you sure?
I see nothing which says MNT_ASYNC will write anything at all out at any
time before a umount(2) call. Personally I think that's a good thing --
it is, perhaps, an indication that MNT_ASYNC is being as efficient as it
can possibly be, though of course it may also just be accidental that
NetBSD's implemenation doesn't behave more as some folks seem to expect
it to do.
In any case I'm not so sure it matters in the long run.
The relative damage to the filesystem is all a matter of circumstance.
The fact is that use of MNT_ASYNC means the filesystem is very easily
damaged beyond the ability of fsck's algorithms to repair it in a useful
manner.
One can concoct special circumstances where NetBSD's implementation
fairs worse than others, but equally it is possible to concoct
circumstances where no true fully async implementation can ever do very
well.
> I'm not 100% clear what
> is wrong, but it seems likely that this discussion has surfaced a bug or
> two
The only real bug I see is that "mount -u -o noasync" might not work
(just as "mount -u -r" is known not to work). But I seem to be the only
one really focusing on that side of the issue here.
Indeed it might be nice if an otherwise idle system would _eventually_
clean all its dirty buffers one way or another even if they are part of
a filesystem that has been mounted with MNT_ASYNC, but I don't see that
as a requirement of MNT_ASYNC, and I certainly wouldn't want that to
give allowance for the manual to be less foreboding than it already is.
Indeed I would still want to see fsck spit out the warning I suggested,
or at least one with as much or even more force in setting the user's
expectations for failure.
Perhaps it is so simple that fixing the known accepted bug(s), i.e. such
that "mount -u -r" and "mount -u -o noasync" work will have the fallout
of also making MNT_ASYNC mounted filesystems also eventually gain better
consistency on idle systems.
:-)
(I am waffling though on whether I think sync(2) should have any
beneficial affect on the consistency of MNT_ASYNC-mounted filesytems.)
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 250 762-7675 http://www.planix.com/
Attachment:
pgpknETqapfJ2.pgp
Description: PGP signature