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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 06 Oct 2006 15:33:53 +0200
From:	Valerie Clement <valerie.clement@...l.net>
To:	Theodore Tso <tytso@....edu>
Cc:	Andreas Dilger <adilger@...sterfs.com>, linux-ext4@...r.kernel.org
Subject: Re: ext4 compat flag assignments

Theodore Tso wrote:
> On Thu, Sep 28, 2006 at 10:55:15AM +0200, Alexandre Ratchov wrote:
>> 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 */
>> };
> 
> Why do we need to have the high blocks # of the journal inode.
> s_jnl_blocks was just a backup of the i_blocks[] array.  But if we are
> assuming that we will only support 64-bits using extents, we shouldn't
> need s_jnl_blocks_hi[].  How specifically is this array being used in
> the patches?

The s_jnl_blocks_hi[] array is not used in the current patchset.
Alexandre wanted to reserve these fields for a future use, for instance 
to support larger inode sizes.
As we'll not use them in the short term and we'll still need to think 
about that, you can remove this array.

Regards,
   Valérie

-
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