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@xxxxxxxxxxxxxxx address will probably either bounce or black hole - not sure which. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
