lkml.org 
[lkml]   [2011]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/2] Add inode checksum support to ext4
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


\
 
 \ /
  Last update: 2011-07-27 10:29    [W:0.900 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site