linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jose R. Santos" <jrs@us.ibm.com>
To: Theodore Tso <tytso@mit.edu>
Cc: Andreas Dilger <adilger@clusterfs.com>,
	linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [RFC] BIG_BG vs extended META_BG in ext4
Date: Sun, 1 Jul 2007 09:48:33 -0500	[thread overview]
Message-ID: <20070701094833.47035331@gara> (raw)
In-Reply-To: <20070701123054.GC28917@thunk.org>

On Sun, 1 Jul 2007 08:30:54 -0400
Theodore Tso <tytso@mit.edu> wrote:
> It was the intention that META_BG include allowing the bitmap and
> inode tables to range anywhere outside of the block group, but that
> never got coded.  It would be confusing though if we relaxed it
> withotu adding a feature bit, and I agree that we might as well use
> overload the BIG_BG group to indicate this feature.
> 
> The fact that BIG_BG requires contiguous blocks for the bitmaps when
> they exceed blocksize*8 blocks still concerns me a minor amount, and

Is your concern due to being unable to find contiguous block in the
case that a bad disk area is in one of the bitmap blocks?  One thing we
can do is try to search for another set of contiguous blocks and if we
fail to find one, we can flag the block group and move to an indirect
block approach to allocating the bitmaps.  At this point, we do lose
some of the performance benefits of BIG_BG, but we would still be able
to use the block group.

> given the hopeful inclusion of kernel patches that allow blocksize >

One thing that concerns me about blocksize larger than page size is
that it requires to much planing from the person creating the
filesystem.  While larger blocksizes does address some of the issues of
the block group size limits, it does so in a less flexible manner.
With something like BIG_BG, we can provide larger extents for large
files while still keeping disk space consumption under control with
small files.
 
> pagesize.  Furthermore, I still wonder whether we will want to make
> blockgroups that much bigger (since reducing the allocation groups is
> not necessarily a smart thing; we will need to do some benchmarks with
> filesystem aging to see how this affects antifragmentation efforts),
> but the complexity engenered by adding BIG_BG isn't that bad (again,
> my only concern is with the contiguous bitmap blocks requirements).

Point take...  I'll do some aged filesystem test to see how if are some
real benefits to be gain in reducing fragmentation.  

> 
> 						- Ted

-JRS

  reply	other threads:[~2007-07-01 14:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-29 22:09 [RFC] BIG_BG vs extended META_BG in ext4 Jose R. Santos
2007-06-30  5:51 ` Andreas Dilger
2007-06-30 14:24   ` Mingming Cao
2007-07-01  4:39   ` Jose R. Santos
2007-07-01 12:30     ` Theodore Tso
2007-07-01 14:48       ` Jose R. Santos [this message]
2007-07-02 15:49         ` Theodore Tso
2007-07-02 14:12           ` Mingming Cao
2007-07-05  6:56             ` Valerie Henson
     [not found] ` <D5D3223C-4EB0-413B-A81A-05F6DDC0FEEB@bull.net>
2007-07-01  4:40   ` Jose R. Santos
2007-07-01 16:31     ` Andreas Dilger
2007-07-02 14:39       ` Jose R. Santos
2007-07-03 17:55         ` Andreas Dilger

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=20070701094833.47035331@gara \
    --to=jrs@us.ibm.com \
    --cc=adilger@clusterfs.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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;
as well as URLs for NNTP newsgroup(s).