linux-ext4 - Re: ext4 compat flag assignments

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <p73u02rivk8.fsf@verdi.suse.de>
Date:	28 Sep 2006 22:29:43 +0200
From:	Andi Kleen <ak@...e.de>
To:	Alexandre Ratchov <alexandre.ratchov@...l.net>
Cc:	Theodore Ts'o <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Re: ext4 compat flag assignments

Alexandre Ratchov <alexandre.ratchov@...l.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
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html