All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@sun.com>
To: Theodore Tso <tytso@mit.edu>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	"Fr�d�ric Boh�" <frederic.bohe@bull.net>,
	linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] ext4: add checksum calculation when clearing UNINIT flag
Date: Mon, 10 Nov 2008 18:23:49 -0700	[thread overview]
Message-ID: <20081111012349.GS32755@webber.adilger.int> (raw)
In-Reply-To: <20081107143806.GD9543@mit.edu>

On Nov 07, 2008  09:38 -0500, Theodore Ts'o wrote:
> On Fri, Nov 07, 2008 at 07:57:18PM +0530, Aneesh Kumar K.V wrote:
> > Because when we clear the uninitt_bg flag the kernel expect the block 
> > bitmap to be correctly indicate blocks containing block
> > bitmap and inode bitmap as used. If mke2fs didn't do that we would
> > need to do the same when we remove the uninit_bg flag.
> 
> We have separate flags inidicating whether the block allocation bitmap
> and inode allocation bitmaps are initialized or not,
> EXT4_BG_BLOCK_UNINIT, and EXT4_BG_INODE_UNINIT, respectively.  So what
> I am proposing is to not initialize the block bitmap in
> ext4_new_inode(), and not to clear the EXT4_BG_BLOCK_UNINIT flag, either.

That would be dangerous, because the block group _would_ be in use due
to the fact that one of the inode table blocks is in use.  That isn't
to say we couldn't adopt sematics as you suggest (e.g. that INODE_UNINIT
not being set implies that the inode table blocks are in use regardless
of whether or not BLOCK_UNINIT is set, but it needs careful consideration.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.


      reply	other threads:[~2008-11-11  1:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-07 10:22 [PATCH] ext4: add checksum calculation when clearing UNINIT flag Frédéric Bohé
2008-11-07 13:52 ` Theodore Tso
2008-11-07 14:27   ` Aneesh Kumar K.V
2008-11-07 14:38     ` Theodore Tso
2008-11-11  1:23       ` Andreas Dilger [this message]

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=20081111012349.GS32755@webber.adilger.int \
    --to=adilger@sun.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=frederic.bohe@bull.net \
    --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 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.