Re: [PATCH 0/2] Add inode checksum support to ext4

["Darrick J. Wong" <djwong@us.ibm.com>]

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:
> > 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