4. Anyone who is shutting down their system by pulling the plug
rather than doing an orderly shutdown is asking for trouble.
Yes, it is a situation we want to deal with fairly gracefully,
but filesystem recovery in journaling filesystems and fsck in
others is there to 'recover' from problems, not to cater to
lazy users. umount is there for a reason.

Yes, but crashes can ocur in a perfect world.

5. With XFS it looks like this:

o write system call comes in looks for space in the file, if
there is none it asks the filesystem for some, the filesystem
records the fact that space was requested at this point in the
file. A buffer is allocated as before, it is marked dirty, it
is also marked delayed allocate. The write returns.

o Possibly an inode flush or a log flush pushes the new inode
out to disk.

o The bdflush daemon comes along and sees the buffers as being
delayed allocate, it calls the filesystem to allocate the space.
The allocate is done, and the buffers are written out to disk.
The transaction which records the extents is still in memory
and will not be flushed for a few seconds yet.

This last sentence is the major difference, and is probably what is
biting here, the write has not really happened until this metadata
makes it out to disk. We may be having some issues with how long
this is taking in Linux.

Weird, I expected the data to get written first and then the metadata. If
that would happen you would have no file, or in our case, the old file.

So the upshot of all of this is that I suspect we do have an issue, and we
will get to it at some point. In the mean time there is no need to start
discarding filesystems which do not behave as you want them to do if you
pull the plug.

Hey, we have lot's of time to fix it. I could have used all those 30
minutes of time that I saved from fscking my filesystem but I used it to
play Quake 3 instead.

Cheers

--
Seth
Every program has two purposes one for which
it was written and another for which it wasn't
I use the last kind.