At Mon, 12 Dec 2011 14:17:35 -0600, Eric Haszlakiewicz <e...@nimenees.com> 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. <wo...@planix.com> +1 250 762-7675 http://www.planix.com/
pgprM7NvSBuE4.pgp
Description: PGP signature