All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jose R. Santos" <jrs@us.ibm.com>
To: Theodore Tso <tytso@mit.edu>
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 17:27:51 -0500	[thread overview]
Message-ID: <20080422172751.22d5aef9@gara> (raw)
In-Reply-To: <20080422185728.GC20668@mit.edu>

On Tue, 22 Apr 2008 14:57:28 -0400
Theodore Tso <tytso@mit.edu> wrote:

> 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

Well higher spindle speed affect cylinder seek times which affect
overall seek time, which is why I think it should be tested as well.
 
> 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

I do not have any data on multiple block size and I have not done
testing with the 64K equivalent of 4096 groups for a 4k filesystem. The
testing scenarios in a 4k filesystem should also be different than
those for a 64k filesystem, so the testing I did in 4k does not
necessarily apply to a bigger block size.

The default of 16 is a safe number for 4k block size.  I would think
that the larger the block size, the smaller the flex_bg packing size
should be since larger block size address some of the issues that
flex_bg tries to address.

-JRS

  reply	other threads:[~2008-04-22 22:27 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
2008-04-22 22:27             ` Jose R. Santos [this message]
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=20080422172751.22d5aef9@gara \
    --to=jrs@us.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    --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.