From: Will Drewry <redpig@dataspill.org>
To: linux-ext4@vger.kernel.org
Subject: [PATCH][RFC] resize2fs and uninit_bg questions
Date: Wed, 16 Sep 2009 11:24:57 -0500 [thread overview]
Message-ID: <20090916162457.GA84213@freezingfog.local> (raw)
Hi linux-ext4,
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.
Any and all feedback is appreciated -- even if it just for me
to look at the archives/link/etc.
Thanks!
Signed-off-by: Will Drewry <redpig@dataspill.org>
---
resize/resize2fs.c | 28 ++++++++++++++++++++++------
1 files changed, 22 insertions(+), 6 deletions(-)
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;
if (i == fs->group_desc_count-1) {
numblocks = (fs->super->s_blocks_count -
fs->super->s_first_data_block) %
@@ -568,7 +567,7 @@ errout:
static errcode_t adjust_superblock(ext2_resize_t rfs, blk_t new_size)
{
ext2_filsys fs;
- int adj = 0;
+ int adj = 0, csum_flag = 0, num = 0;
errcode_t retval;
blk_t group_block;
unsigned long i;
@@ -624,6 +623,9 @@ static errcode_t adjust_superblock(ext2_resize_t rfs, blk_t new_size)
&rfs->itable_buf);
if (retval)
goto errout;
+ /* Track if we can get by with a lazy init */
+ csum_flag = EXT2_HAS_RO_COMPAT_FEATURE(fs->super,
+ EXT4_FEATURE_RO_COMPAT_GDT_CSUM);
memset(rfs->itable_buf, 0, fs->blocksize * fs->inode_blocks_per_group);
group_block = fs->super->s_first_data_block +
@@ -642,10 +644,24 @@ static errcode_t adjust_superblock(ext2_resize_t rfs, blk_t new_size)
/*
* Write out the new inode table
*/
+ if (csum_flag) {
+ /* These are _new_ inode tables. No inodes should be in use.
+ * (As per ext2fs_set_gdt_csum) */
+ fs->group_desc[i].bg_itable_unused = fs->super->s_inodes_per_group;
+ num = ((((fs->super->s_inodes_per_group -
+ fs->group_desc[i].bg_itable_unused) *
+ EXT2_INODE_SIZE(fs->super)) +
+ EXT2_BLOCK_SIZE(fs->super) - 1) /
+ EXT2_BLOCK_SIZE(fs->super));
+ } else {
+ num = fs->inode_blocks_per_group;
+ /* The kernel doesn't need to zero the itable blocks. We will below */
+ fs->group_desc[i].bg_flags |= EXT2_BG_INODE_ZEROED;
+ }
retval = io_channel_write_blk(fs->io,
- fs->group_desc[i].bg_inode_table,
- fs->inode_blocks_per_group,
- rfs->itable_buf);
+ fs->group_desc[i].bg_inode_table, /* blk */
+ num, /* count */
+ rfs->itable_buf); /* contents */
if (retval) goto errout;
io_channel_flush(fs->io);
--
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
next reply other threads:[~2009-09-16 16:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-16 16:24 Will Drewry [this message]
2009-09-16 19:08 ` [PATCH][RFC] resize2fs and uninit_bg questions Andreas Dilger
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=20090916162457.GA84213@freezingfog.local \
--to=redpig@dataspill.org \
--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 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).