From: "Jose R. Santos" <jrs@us.ibm.com>
To: Andreas Dilger <adilger@sun.com>
Cc: linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [RFC] [PATCH] Flex_BG ialloc awareness V2.
Date: Thu, 13 Dec 2007 09:51:12 -0600 [thread overview]
Message-ID: <20071213095112.100b3d9e@gara> (raw)
In-Reply-To: <20071211231528.GS3214@webber.adilger.int>
On Tue, 11 Dec 2007 16:15:28 -0700
Andreas Dilger <adilger@sun.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
next prev parent reply other threads:[~2007-12-13 15:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-06 22:10 [RFC] [PATCH] Flex_BG ialloc awareness V2 Jose R. Santos
2007-12-07 10:14 ` Andreas Dilger
2007-12-07 15:52 ` Jose R. Santos
2007-12-11 11:00 ` Andreas Dilger
2007-12-11 16:08 ` Jose R. Santos
2007-12-11 23:15 ` Andreas Dilger
2007-12-13 15:51 ` Jose R. Santos [this message]
2007-12-13 22:58 ` Andreas Dilger
2007-12-14 2:36 ` Jose R. Santos
2007-12-14 17:01 ` Andreas Dilger
2007-12-14 18:07 ` Jose R. Santos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071213095112.100b3d9e@gara \
--to=jrs@us.ibm.com \
--cc=adilger@sun.com \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox