From: Theodore Tso <tytso@mit.edu>
To: "Jose R. Santos" <jrs@us.ibm.com>
Cc: linux-ext4@vger.kernel.org, Valerie Clement <valerie.clement@bull.net>
Subject: Re: [E2FSPROGS, RFC] mke2fs: New bitmap and inode table allocation for FLEX_BG
Date: Tue, 22 Apr 2008 14:57:28 -0400 [thread overview]
Message-ID: <20080422185728.GC20668@mit.edu> (raw)
In-Reply-To: <20080422103212.1c974bd9@gara>
On Tue, Apr 22, 2008 at 10:32:12AM -0500, Jose R. Santos wrote:
> I see that now, guess I should not read code with out having
> breakfast. I think 8 is a very safe and conservative number, maybe to
> conservative. The 64 group packing was the number I found to be a
> overall improvement with the limited number of drives that I had to
> test with. Haven't done any testing on old drives or laptop drive with
> slow spindle speed but I would think 16 or 32 would be safe here unless
> the drive is really old and small.
Let's stay with 16 then for now. Spindle speed doesn't actually
matter here; what matters is seek speed, and the density of the disk
drive. The other thing which worries me though is that the size of
each flex_bg block group cluster is dependent on the size of the block
group, which in turn is related to the square of the filesystem
blocksize. i.e., assuming a fs blockgroup size of 16, then:
Blocksize Blocks/blockgroup Blockgroup Size Flex_BG cluster size
1k 8192 8 Meg 128 Meg
2k 16384 32 Meg 512 Meg
4k 32768 128 Meg 2 Gig
8k 65536 512 Meg 8 Gig
16k 131072 2 Gig 32 Gig
32k 262144 8 Gig 128 Gig
64k 524288 32 Gig 512 Gig
So using a fixed default of 16, the flexible blockgroup size can range
anything from 128 megs to half a terabyte!
How much a difference in your numbers are you seeing, anyway? Is it
big enough that we really need to worry about it?
- Ted
next prev parent reply other threads:[~2008-04-22 18:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-22 12:46 [RFC] Modified flex_bg patches Theodore Ts'o
2008-04-22 12:46 ` [E2FSPROGS, RFC] Basic flexible block group support Theodore Ts'o
2008-04-22 12:46 ` [E2FSPROGS, RFC] mke2fs: New bitmap and inode table allocation for FLEX_BG Theodore Ts'o
2008-04-22 14:18 ` Jose R. Santos
2008-04-22 14:51 ` Theodore Tso
2008-04-22 15:32 ` Jose R. Santos
2008-04-22 18:57 ` Theodore Tso [this message]
2008-04-22 22:27 ` Jose R. Santos
2008-04-23 1:21 ` Theodore Tso
2008-04-23 5:48 ` Jose R. Santos
2008-04-23 12:23 ` Theodore Tso
2008-04-23 16:24 ` Jose R. Santos
2008-04-23 20:57 ` Andreas Dilger
2008-04-23 21:20 ` Jose R. Santos
2008-04-23 20:39 ` Andreas Dilger
2008-04-23 21:05 ` Jose R. Santos
2008-04-25 20:10 ` Andreas Dilger
2008-04-28 12:01 ` Theodore Tso
2008-04-23 21:01 ` Andreas Dilger
2008-04-22 13:47 ` [E2FSPROGS, RFC] Basic flexible block group support 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=20080422185728.GC20668@mit.edu \
--to=tytso@mit.edu \
--cc=jrs@us.ibm.com \
--cc=linux-ext4@vger.kernel.org \
--cc=valerie.clement@bull.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.