From: "Darrick J. Wong" Subject: Re: [PATCH 19/34] resize2fs: convert fs to and from 64bit mode Date: Sun, 14 Sep 2014 10:50:52 -0700 Message-ID: <20140914175052.GF10150@birch.djwong.org> References: <20140913221112.13646.3873.stgit@birch.djwong.org> <20140913221318.13646.90438.stgit@birch.djwong.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "tytso@mit.edu" , "linux-ext4@vger.kernel.org" To: TR Reardon Return-path: Received: from aserp1040.oracle.com ([141.146.126.69]:36712 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752498AbaINRu7 (ORCPT ); Sun, 14 Sep 2014 13:50:59 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-ext4-owner@vger.kernel.org List-ID: On Sun, Sep 14, 2014 at 01:34:14PM -0400, TR Reardon wrote: > > Subject: [PATCH 19/34] resize2fs: convert fs to and from 64bit mode > > From: darrick.wong@oracle.com > > To: tytso@mit.edu; darrick.wong@oracle.com > > CC: linux-ext4@vger.kernel.org > > Date: Sat, 13 Sep 2014 15:13:18 -0700 > > > > resize2fs does its magic by loading a filesystem, duplicating the > > in-memory image of that fs, moving relevant blocks out of the way of > > whatever new metadata get created, and finally writing everything back > > out to disk. Enabling 64bit mode enlarges the group descriptors, > > which makes resize2fs a reasonable vehicle for taking care of the rest > > of the bookkeeping requirements, so add to resize2fs the ability to > > convert a filesystem to 64bit mode and back. > > > > Signed-off-by: Darrick J. Wong > > --- > > resize/main.c | 40 ++++++ > > resize/resize2fs.8.in | 18 +++ > > resize/resize2fs.c | 326 ++++++++++++++++++++++++++++++++++++++++++++++++- > > resize/resize2fs.h | 3 > > 4 files changed, 379 insertions(+), 8 deletions(-) > > > > > > diff --git a/resize/main.c b/resize/main.c > > index c107028..9fea3d8 100644 > > --- a/resize/main.c > > +++ b/resize/main.c > > @@ -42,7 +42,7 @@ static char *device_name, *io_options; > > static void usage (char *prog) > > { > > fprintf (stderr, _("Usage: %s [-d debug_flags] [-f] [-F] [-M] [-P] " > > - "[-p] device [new_size]\n\n"), prog); > > + "[-p] device [-b|-s|new_size]\n\n"), prog); > > > > exit (1); > > } > > @@ -200,7 +200,7 @@ int main (int argc, char ** argv) > > if (argc && *argv) > > program_name = *argv; > > > > - while ((c = getopt (argc, argv, "d:fFhMPpS:")) != EOF) { > > + while ((c = getopt(argc, argv, "d:fFhMPpS:bs")) != EOF) { > > switch (c) { > > case 'h': > > usage(program_name); > > @@ -226,6 +226,12 @@ int main (int argc, char ** argv) > > case 'S': > > use_stride = atoi(optarg); > > break; > > + case 'b': > > + flags |= RESIZE_ENABLE_64BIT; > > + break; > > + case 's': > > + flags |= RESIZE_DISABLE_64BIT; > > + break; > > default: > > usage(program_name); > > } > > @@ -389,6 +395,10 @@ int main (int argc, char ** argv) > > if (sys_page_size> fs->blocksize) > > new_size &= ~((sys_page_size / fs->blocksize)-1); > > } > > + /* If changing 64bit, don't change the filesystem size. */ > > + if (flags & (RESIZE_DISABLE_64BIT | RESIZE_ENABLE_64BIT)) { > > + new_size = ext2fs_blocks_count(fs->super); > > + } > > if (!EXT2_HAS_INCOMPAT_FEATURE(fs->super, > > EXT4_FEATURE_INCOMPAT_64BIT)) { > > /* Take 16T down to 2^32-1 blocks */ > > @@ -440,7 +450,31 @@ int main (int argc, char ** argv) > > fs->blocksize / 1024, new_size); > > exit(1); > > } > > - if (new_size == ext2fs_blocks_count(fs->super)) { > > + if ((flags & RESIZE_DISABLE_64BIT) && (flags & RESIZE_ENABLE_64BIT)) { > > + fprintf(stderr, _("Cannot set and unset 64bit feature.\n")); > > + exit(1); > > + } else if (flags & (RESIZE_DISABLE_64BIT | RESIZE_ENABLE_64BIT)) { > > + new_size = ext2fs_blocks_count(fs->super); > > > Redundant to assignment just above? -- Yeah, I think so. I think the original purpose was to reset new_size after the size checks, but at the moment the only way that happens is if we've a 32bit FS with exactly 2^32 blocks, which shouldn't be possible. --D > 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