linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Valerie Henson <val@nmt.edu>
To: Mingming Cao <cmm@us.ibm.com>
Cc: Theodore Tso <tytso@mit.edu>, "Jose R. Santos" <jrs@us.ibm.com>,
	Andreas Dilger <adilger@clusterfs.com>,
	linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [RFC] BIG_BG vs extended META_BG in ext4
Date: Thu, 5 Jul 2007 00:56:56 -0600	[thread overview]
Message-ID: <20070705065656.GC3854@rainbow> (raw)
In-Reply-To: <1183385577.3864.7.camel@localhost.localdomain>

On Mon, Jul 02, 2007 at 10:12:57AM -0400, Mingming Cao wrote:
> 
> How about incorporating some of the chunkfs ideas into this BIG_BG or
> extended metablockgroups? The original block group size (128MB) is
> probably too small that would results in many continous inodes. By
> enlarging the size of groups via BIG_BG or extended metablockgroups, we
> could add dirty/clean bit to allow partical/parallel fsck, and something
> like that. Any thoughts on thhis?

We looked into this in the 2006 OLS paper
(http://infohost.nmt.edu/~val/review/ext2fsck.pdf) and concluded that
it's pretty hard to do anything useful on a per-block group basis.
The only metadata that could be checked and repaired on a per-bg basis
are the block group summaries of free/used inodes and free/used
blocks.  So if we had a situation in which the metadata in the block
group was consistent in all ways (link counts, directory entries,
etc.) except that we hadn't updated the bg summary info, then it would
be useful - but I don't think that happens very often.  Anything more
useful than that will require on-disk format changes; at which point
why restrict ourselves to a bit in the block group descriptor?

-VAL

  reply	other threads:[~2007-07-05  6:56 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
2007-07-02 15:49         ` Theodore Tso
2007-07-02 14:12           ` Mingming Cao
2007-07-05  6:56             ` Valerie Henson [this message]
     [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=20070705065656.GC3854@rainbow \
    --to=val@nmt.edu \
    --cc=adilger@clusterfs.com \
    --cc=cmm@us.ibm.com \
    --cc=jrs@us.ibm.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).