At Mon, 12 Dec 2011 14:17:35 -0600, Eric Haszlakiewicz
<erh%nimenees.com@localhost> wrote:
Subject: Re: Lost file-system story
>
> On Mon, Dec 12, 2011 at 11:39:38AM -0800, Greg A. Woods wrote:
> > 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.
>
> hmm.. so then how can you claim that it is "entirely different" (as you did
> in an earlier email)? It sounds like you're talking our of your, ahem..
> depth.
As I said, I'm trying to be careful to avoid making claims one way or
another about non-Unix-based filesystems.
I'm also trying to keep in mind that MNT_ASYNC can be an attribute of
the OS implementation well above the filesystems and I'm also trying to
avoid making claims about non-Unix filesytem structures which may be
faced with this "feature" for the first time.
Once upon a time I was quite familiar with the use of the tools that
came before fsck. I have a great deal of experience with the on-disk
structure of V7fs, SysVfs, and many of the minor variants of these
filesystems. I'm experienced with many of the things that can go wrong
with these filesystems and I'm moderately experienced with how they can
be repaired as best as is humanly possible with low-level bit
manipulating tools when bugs in either the kernel or fsck cause
unexpected failures (not unlike what can happen when MNT_ASYNC is used).
I'm moderately experienced with more modern filesystems such as with
SysVr4's native FS and Berkeley FFS, though less experienced with
low-level on-disk repair of those filesystems (since on these modern
Unix-based filesystems the standard repair tools, especially fsck, have
been vastly improved; and kernel bugs which destroy the ordered writing
of metadata have effectively been eliminated).
> > 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.
>
> Have you tried actually comparing the current NetBSD ffs sources against
> whatever "Unix" sources you are talking about? While I'm sure that there
> are many "attributes" that are shared, if you even compare the current NetBSD
> sources with those from, say, 1994, you will find a ton of differences.
This has nothing to do with any given pile of source code per se. The
issues that affect repariability of a Unix-based filesystem are higher
level design considerations that are common to the implementations of
fsck and the filesystems they can repair from the v7 addenda tape all
the way through to the implementation of modern day NetBSD's
fsck_ffs(8).
You might find McKusick and Kowalski's paper about BSD FFS fsck
enlightening. (I can supply a copy if you can't find it elsewhere. It
would be nice if it could be included in the NetBSD distribution, even
if not cleaned up to reflect the current implementation. It was in
4.4BSD-Lite2, after all.)
Like I said earlier:
Perhaps the superblock(s) 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:
pgpSBCjn9LsLC.pgp
Description: PGP signature