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: Andreas Dilger <adilger@clusterfs.com>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: Initial results of FLEX_BG feature.
Date: Wed, 11 Jul 2007 18:14:25 -0400	[thread overview]
Message-ID: <20070711221425.GH19456@thunk.org> (raw)
In-Reply-To: <20070711003004.531c9307@naruto>

On Wed, Jul 11, 2007 at 12:30:04AM -0500, Jose R. Santos wrote:
> Right now what I've done is allocate the bitmaps and inode tables at the
> beginning of each group of 64 BG.  Still need to work on fsck since just
> removing the restriction on were the bitmaps and inode table are
> located still gives me errors of uninitialized inodes with dtime set.
> Seems like fsck still expect inode information to be located at
> specific locations within the disk.

Can you send me the patch which you were playing with?  I might be
able to help you with this.  It should be pretty straightforward to
remove the constraint on the inode table location.  

It really should only be a check in e2fsck/super.c:check_super_block(),
as far as I know.

If you're seeing errors of unitialized inodes with dtime set, that
sounds like maybe something else is going on.  All of e2fsprogs should
be referencing the inode table via fs->group_desc[group_num].bg_inode_table.  
See lib/ext2fs/inode.c, functions ext2fs_open_inode_scan(), 
get_next_blockgroup(), and ext2fs_read_inode_full().

							- Ted

  parent reply	other threads:[~2007-07-11 22:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-10 16:23 Initial results of FLEX_BG feature Jose R. Santos
2007-07-11  4:12 ` Andreas Dilger
2007-07-11  5:30   ` Jose R. Santos
2007-07-11  5:39     ` Eric Sandeen
2007-07-11 12:41     ` Andreas Dilger
2007-07-11 22:09     ` Theodore Tso
2007-07-11 22:14     ` Theodore Tso [this message]
2007-07-12 15:02       ` Jose R. Santos
2007-07-12 15:09       ` Jose R. Santos
2007-07-16  6:34         ` Andreas Dilger
2007-07-16 12:27           ` 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=20070711221425.GH19456@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger@clusterfs.com \
    --cc=jrs@us.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    /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.