Re: ext4 compat flag assignments

[Andi Kleen <ak@suse.de>]

Alexandre Ratchov <alexandre.ratchov@bull.net> writes:

> here is a list of fields we plan to use for the 64bit support, they must be
> zero on file systems without the EXT4_FEATURE_INCOMPAT_64BIT.
> 
> struct ext4_super_block
> {
> 	/* at offset 0xfe */
> 	__le32	s_desc_size;		/* Group descriptor size */
> 	/* at offset 0x150 */
> 	__le32	s_blocks_count_hi;	/* Blocks count */
> 	__le32	s_r_blocks_count_hi;	/* Reserved blocks count */
> 	__le32	s_free_blocks_count_hi;	/* Free blocks count */
> 	__le32	s_jnl_blocks_hi[17];	/* Backup of the journal inode */
> };
> 
> struct ext4_group_desc
> {
> 	/* at offset 0x20 */
> 	__le32	bg_block_bitmap;	/* Blocks bitmap block hi bits */
> 	__le32	bg_inode_bitmap;	/* Inodes bitmap block hi bits */
> 	__le32	bg_inode_table;		/* Inodes table block hi bits */
> 	__le16	bg_free_blocks_count;	/* Free blocks count hi bits */
> 	__le16	bg_free_inodes_count;	/* Free inodes count hi bits */
> 	__le16	bg_used_dirs_count;	/* Directories count hi bits */
> };
> 
> basically, we make 64bit all block numbers and we double the size of all
> xxx_count in the block group descriptor.

When you do this have you considered at least reserving fields in the 
new 64bit indirect blocks for checksums for each block? 

IMHO it would be a great advantage to checksum all metadata 
(as demonstrated by ZFS) and CPU cycles are cheap enough now that it is 
basically free.

The checksums could be different feature flags, but it would be useful
to reserve space in any new format. 16 byte free on each block should be enough.

-Andi