On Fri, Apr 08, 2011 at 12:27:48PM -0700, Mingming Cao wrote:

On Wed, 2011-04-06 at 15:44 -0700, Darrick J. Wong wrote:

quoted

Hi all,

I spent last week analyzing a client's corrupted ext3 image to see if I could
determine what had gone wrong and caused the filesystem to blow apart.  As best
as I could tell, a data block got miswritten into a different sector ... which
happened to be an indirect block.  Some time later the indirect block, which
now pointed at one of the inode tables (among other things that shouldn't ever
become file data) was loaded as part of a file write, which caused that inode
table to be blown to smithereens.  Just for fun I tried reading from one of
these busted-inode files and ... failed to encounter any errors.  Somehow, they
didn't find it funny that ext3 would read block numbers from a table with the
contents "ibm.com" with a straight face.  Fortunately there were backups. :)

The client at this point asked if ext4 would do a better job of sanity
checking, which got me to wonder why ext4 checksums block groups but not
inodes.  It's on Ted's todo list, but apparently nobody wrote any patch, so I
did.  The following two patches are a first draft of adding inode checksum
support to both the kernel driver and to the various e2fsprogs.

We had some discussion about this week at SF (at the ext4 bof at the
linux colloboration summit). Beyond checksumming the inode itself, it
would be more useful to checksum the extent indexing blocks, as the ext3
corruption actually happen at the indirect block.  

The idea is to reduce the eh_max (the max # of extents stored in this
block) to save some space to store the checksums in the block, 

/*
 * Each block (leaves and indexes), even inode-stored has header.
 */
struct ext4_extent_header {
        __le16  eh_magic;       /* probably will support different
formats */
        __le16  eh_entries;     /* number of valid entries */
        __le16  eh_max;         /* capacity of store in entries */
        __le16  eh_depth;       /* has tree real underlying blocks? */
        __le32  eh_generation;  /* generation of the tree */

Does anyone use eh_generation?  Linux 3.0 shows no users and it didn't look like
the snapshot patches do either.  If nobody intends to start using this field,
(part of) it could become eh_checksum.

--D