All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.