On Tue, Dec 6, 2011 at 11:58 AM, Thor Lancelot Simon <t...@panix.com> wrote: > On Tue, Dec 06, 2011 at 11:10:44AM -0500, Donald Allen wrote: >> >> 2. I'm a little bit surprised that the filesystem was as much of a >> mess as it was. > > I'm not. You mounted the filesystem async and had a crash. With the > filesystem mounted async *nothing* pushes out most metadata updates, > with the result that the filesystem's metadata can quickly enter a > fatally inconsistent state. The only way home safe is a clean unmount.
So unwritten meta-data from an async filesystem can sit in the buffer cache for arbitrarily long periods of time in NetBSD? I just want to be sure I understand what you are saying. Because that essentially guarantees, as you imply above, that if the system crashes, you will lose the filesystem. That makes the following warning, in the mount(8) man page, in the description of the async option: "In the event of a crash, it is impossible for the system to verify the integrity of data on a file system mounted with this option." 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. There are uses for async filesystems (hell, google used ext2 for years and now uses journal-less ext4) and, as I said in my original post, with the assumed periodic sync'ing, fsck can put the system back together after a crash, in my case that has been invariably true. > > If you mount an FFS filesystem async you are playing with fire. Sure, > it can be useful, but asbestos clothing is not optional. > > Thor