All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@sun.com>
To: Will Drewry <redpig@dataspill.org>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH][RFC] resize2fs and uninit_bg questions
Date: Wed, 16 Sep 2009 13:08:31 -0600	[thread overview]
Message-ID: <20090916190831.GH2537@webber.adilger.int> (raw)
In-Reply-To: <20090916162457.GA84213@freezingfog.local>

On Sep 16, 2009  11:24 -0500, Will Drewry wrote:
> I have a two questions with an accompanying patch for clarification.
> 
> resize2fs is uninit_bg aware, but when it is expanding an ext4
> filesystem, it will always zero the inode tables.  Is it safe to mimick
> mke2fs's write_inode_table(.., lazy_flag=1) and leave the new block
> groups' inode tables marked INODE_UNINIT, BLOCK_UNINIT and _not_ zero
> out the inode table if uninit_bg is supported?
> 
> If it is okay, then it means offline resizing upwards can be just as
> fast as mke2fs.  I've attached a patch which is probably incomplete.
> I'd love feedback as to the feasibility of the change and/or patch
> quality.
> 
> As a follow-on, would it be sane to add support like this for
> online resizing.  From a cursory investigation, it looks like
> setup_new_block_groups() could be modified to not zero itables
> if uninit_bg is supported, and INODE_ZEROED could be replaced
> with ΒG_*_UNINIT.  However, I'm not sure if that is a naive
> view.  I'm happy to send along a patch illustrating this change
> if that'd be helpful or welcome.

The question is why you would want to risk disk corruption vs.
the (likely not performance critical) online resize?

> Any and all feedback is appreciated -- even if it just for me
> to look at the archives/link/etc.
> 
> diff --git a/resize/resize2fs.c b/resize/resize2fs.c
> index 1a5d910..9fcc3b9 100644
> --- a/resize/resize2fs.c
> +++ b/resize/resize2fs.c
> @@ -497,8 +497,7 @@ retry:
>  
>  		fs->group_desc[i].bg_flags = 0;
>  		if (csum_flag)
> -			fs->group_desc[i].bg_flags |= EXT2_BG_INODE_UNINIT |
> -				EXT2_BG_INODE_ZEROED;
> +			fs->group_desc[i].bg_flags |= EXT2_BG_INODE_UNINIT;

This shouldn't be unconditional, since most users will want the
safety of having zeroed inode tables.

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

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2009-09-16 19:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-16 16:24 [PATCH][RFC] resize2fs and uninit_bg questions Will Drewry
2009-09-16 19:08 ` Andreas Dilger [this message]
2009-09-16 20:42   ` Will Drewry
2009-09-16 21:22     ` Andreas Dilger
2009-09-16 23:11       ` Will Drewry
2009-09-17 19:28         ` Ric Wheeler
2009-09-18  6:09           ` Martin K. Petersen
2009-09-18 11:43             ` Ric Wheeler
2009-09-18 13:56               ` Andreas Dilger
2009-09-19 12:19         ` Will Drewry
2009-09-23  9:34           ` Andreas Dilger
2009-09-23 19:28             ` Will Drewry
2009-09-25  6:21               ` 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=20090916190831.GH2537@webber.adilger.int \
    --to=adilger@sun.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=redpig@dataspill.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.