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

From: Darrick J. Wong
Date: Wed Jul 27 2011 - 04:27:34 EST


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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/