Re: Lost file-system story

[Ignatios Souvatzis <presse%ycm-bonn.de@localhost>]

On Tue, Dec 06, 2011 at 12:44:16PM -0500, Donald Allen wrote:
> On Tue, Dec 6, 2011 at 11:58 AM, Thor Lancelot Simon 
> <tls%panix.com@localhost> 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

You left out part of the warning. From NetBSD 5.1:

   async       All I/O to the file system should be done asyn-
               chronously.  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.  You
               should only use this option if you have an applica-
               tion-specific data recovery mechanism, or are willing
               to recreate the file system from scratch.

Isn't the last sentence of that paragraph in your version?

Basically, there are two situations where -o async on ffs is sort of safe:

a) you're installing or restore(8)ing on a freshly newfs'd filesystem,
   plan to unmount (or shutdown) as soon as you're finished before using 
   the file system, and could do that again, with the same source data,
   in the event of a power failure during the operation; you get the
   benefit of a fast installation/restore.

b) the file system is on volatile memory and would be gone anyway on
   shutdown, crash, or power failure.

FFS in its default mode has been designed to do part of operations
in an async fashion, but to guarantee enough writes that the remaining 
inconsistencies after a power failure can be cleaned up by fsck_ffs. 
fsck_ffs is designed for this task. It's not designed for arbitrary 
repairs.

(When ffs does async, it really does it.)

Regards,
        -is