On Wed, Aug 31, 2011 at 05:36:22PM -0700, Darrick J. Wong wrote: > diff --git a/lib/ext2fs/ext2_fs.h b/lib/ext2fs/ext2_fs.h > index 1f08673..367bfdf 100644 > --- a/lib/ext2fs/ext2_fs.h > +++ b/lib/ext2fs/ext2_fs.h > @@ -169,7 +169,8 @@ struct ext4_group_desc > __u16 bg_free_inodes_count_hi;/* Free inodes count MSB */ > __u16 bg_used_dirs_count_hi; /* Directories count MSB */ > __u16 bg_itable_unused_hi; /* Unused inodes count MSB */ > - __u32 bg_reserved2[3]; > + __u32 bg_inode_bitmap_csum; /* crc32c(uuid+group+ibitmap) */ > + __u32 bg_reserved2[2]; > }; One of the reasons why I like to coalesce the patches to the data structures into their own separate commit, is it's hard when I'm reviewing individual patches in a mail reader what's going on from a big picture spective. (Heck, even just *finding* the patches that modify the on-disk format is hard....) But as near as I can tell, your patch series only uses one of the 32-bit fields in bg_reserved. Is there a good reason why bg_inode_bitmap_csum can't also used one of the two fields in bg_reserved? That way we get two 32-bit checksums for both struct ext2_group_desc and struct ext4_group_desc. Is there a third 32-bit per-block group checksum I'm forgetting about? - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
