Subject: Re: File system performance
To: Christoph Hellwig <chhellwig@gmx.net>
From: Jaromír <jdolecek@netbsd.org>
List: tech-perform
Date: 02/23/2001 21:02:07
Christoph Hellwig wrote:
> Right - exactly the statment I wanted to hear.  What does it help me to have a
> 'consinstent' fs that lost my data.  Fsck should (and actually e2fsck does,
> even if you sometimes have to press 'y' very often) be able to fix the
> consistency - losing the data is irreperable.

Well, one of us is confused. IMHO it's not me :)

If you lost power and dirty buffers didn't all get written to disk,
you already lost some data. They are lost as lost, cannot be recovered.
No magic incarnation, no technical (even less software) tools can recover
the data which didn't get written to the disk.

The only issue left how much of damage such event does to the filesystem.

If you write metadata synchronously, there is very hight chance
the inode information and indirect block information would be ~correct.
So, fsck can recover most (~all) metadata information and you know
where each filesystem block belongs. This means that quite often,
information on how individual blocks fit together is known and the
only thing fsck has to do is cross-check allocated/free space + reconnect
blocks which belonged to the very recently changed files, for which
the metadata were not written (since metadata is written synchronously,
this is often just couple of files).

Sure, contents of files (file data which are written asynchronously)
may be trashed, since not all blocks may have been written.
But you know how the fs blocks fit together. You get one
continual file, with as much information correct as possible.

For fully asynchronous file systems, you are not guaranteed the metadata
are correct. After fsck is run, you end up with plenty of individual
file blocks and you don't know at all how they fit together. Files
can just vanish (get reconnected under lost+found). The contents of
files has to be recovered manually, which is almost impossible to
do for bigger filesystems. If you are unlucky enough, directory
contents are lost, so whole directory subtrees can vanish. The
filesystem may end up completely hosed. Backups may be the only
way to recover.

I don't quite see why you think fully asynchronous file system
is more reliable. Can you explain advantages of fully asynchronous
file system besides speed ?

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
@@@@  Wanna a real operating system ? Go and get NetBSD, dammit!  @@@@