Alexandre Ratchov <alexandre.ratchov@xxxxxxxx> 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
-
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
