Re: Tux3 Report: Initial fsck has landed

[Theodore Ts'o <tytso@mit.edu>]

On Sun, Jan 27, 2013 at 10:13:37PM -0800, Daniel Phillips wrote:
> > The thing that jumps out at me with this is the question of how you will
> > avoid the 'filesystem image in a file' disaster that reiserfs had (where
> > it's fsck could mix up metadata chunks from the main filesystem with
> > metadata chunks from any filesystem images that it happened to stumble
> > across when scanning the disk)
> >
> Only superficially. Deep thoughts are in order. First, there needs to be a
> hole in the filesystem structure, before we would even consider trying to
> plug something in there. Once we know there is a hole, we want to
> narrow down the list of candidates to fill it. If a candidate already lies
> within a perfectly viable file, obviously we would not want to interpret
> that as lost metadata. Unless the filesystem is really mess up...
> 
> That is about as far as I have got with the analysis. Clearly, much more
> is required. Suggestions welcome.

The obvious answer is what resierfs4 ultimately ended up using.  Drop
a file system UUID in the superblock; mix the UUID into a checksum
which protects each of the your metadata blocks.  We're mixing in the
inode number as well as the fs uuid in in ext4's new metadata checksum
feature to protect against an inode table block getting written to the
wrong location on disk.  It will also mean that e2fsck won't mistake
an inode table from an earlier mkfs with the current file system.
This will allow us to avoid needing to zero the inode table for newly
initialized file systems.

Regards,

						- Ted