Re: [RFC] TileFS - a proposal for scalable integrity checking

[Valerie Henson <val@nmt.edu>]

On Wed, May 09, 2007 at 02:51:41PM -0500, Matt Mackall wrote:
>
> We will, unfortunately, need to be able to check an entire directory
> at once. There's no other efficient way to assure that there are no
> duplicate names in a directory, for instance.

I don't see that being a major problem for the vast majority of
workloads.

> In summary, checking a tile requires trivial checks on all the inodes
> and directories that point into a tile. Inodes, directories, and data
> that are inside a tile get checked more thoroughly but still don't
> need to do much pointer chasing.

Okay, I'm totally convinced - checking a tile-at-a-time works!  I'm
going to steal as many of your ideas as possible and write ChileFS. :)
Per-block inode rmap in particular has so many advantages that I'm
ranking it up with checksums as a must-have feature.

Now for the hard part: repair.  If you find an indirect block or
extent with a bad checksum, how much of the file system are you going
to have to read to fix the dangling blocks?  I can see a speed-up by
reading just the rmaps and looking for the associated inode number.
What about an inode that has been corrupted?  You could at least get
the inode number out of the rmap, but your pointers to your first
level indirect blocks are gone.  A directory block?  No way to get
useful information out of the rmap there.  Ad nauseum.  This is where
I really like having the encapsulation of chunkfs, despite all the
nasty continuation inode bits.

-VAL

P.S. Note the email address change - I'm leaving Intel as of Tuesday
and my val_henson@linux.intel.com address will probably either bounce
or black hole - not sure which.