linux-ext4 - Re: [RFC] [PATCH] Flex_BG ialloc awareness V2.

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071213095112.100b3d9e@gara>
Date:	Thu, 13 Dec 2007 09:51:12 -0600
From:	"Jose R. Santos" <jrs@...ibm.com>
To:	Andreas Dilger <adilger@....com>
Cc:	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [RFC] [PATCH] Flex_BG ialloc awareness V2.

On Tue, 11 Dec 2007 16:15:28 -0700
Andreas Dilger <adilger@....com> wrote:

> On Dec 11, 2007  10:08 -0600, Jose R. Santos wrote:
> > > I'd think being able to avoid the divide for every inode allocation is more
> > > important than 8 bits in the superblock.
> > 
> > We already avoid the divide since what we store in the sbi IS the bits
> > which are calculated at mount time for each fs.  Base on the other
> > fields in the super block struct, I decided to put explicit size of the
> > flexbg in the super block.  The kernel code can decide how best to use
> > that number which in this case its used to calculate the number of bits
> > in order to avoid doing divides.
> > 
> > So this is really a styling issue in how to record data in the super
> > block.  The only technical issue with this is whether it's important to
> > save those extra 8 bits in the super block struct.
> 
> Well, if it is stored in the superblock as a non-power-of-two value, then
> there always exists the possibility that it is set incorrectly (maybe by
> a version of mke2fs that doesn't verify this) and the code will not do the
> right thing.  Storing it in bits (as is done with e.g. s_log_block_size and
> s_log_frag_size) ensures there is no possibility of a value that isn't a
> power-of-two.

While I don't necessary buy the mke2fs example (the only patch that
set this already checks for power-of-two), you are right about the
possibility of being set incorrectly.  I will change it to store the
bits in the next release which I'll do after I fix the resize2fs issues
since this will require changes to the e2fsprogs as well.

Now, storing the bits only guaranties that the flexbg size is always a
power-of-two and does not guarantee that the super block flexbg size
represents the actual meta-data grouping on disk.  For this we need to
verify that the bitmap offsets match what the super block reports.  It
may be an unlikely scenario, but it may be worth it to check this as
well at mount time.

> Cheers, Andreas
> --
> Andreas Dilger
> Sr. Staff Engineer, Lustre Group
> Sun Microsystems of Canada, Inc.
> 

-JRS
-
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