Hi All,
What is the current expected status of resize2fs support with 64-bit
filesystems? Specifically, expanding from <16TB to >16TB. I'm using
the latest code from pu, and seeing some odd things. I'm not sure
what the 64bit feature flag does exactly, but is the transition not
handled properly?
I started with a 15TB LV and filesystem, and then added a new 2TB
drive to the LV. I tried resize2fs (compiled for x86_64) with the
filesystem online. It said it expanded successfully, but it was very
quick, and the filesystem was still the same size.
resize2fs 1.41.9 (22-Aug-2009)
Filesystem at /dev/vg/lv is mounted on /lv; on-line resizing required
old desc_blocks = 955, new_desc_blocks = 1161
Performing an on-line resize of /dev/vg/lv to 4869357568 (4k) blocks.
The filesystem on /dev/vg/lv is now 4869357568 blocks long.
Then I unmounted and re-ran resize2fs. It claimed it was going to
resize to 4869357568 (4k) blocks, but after it was done, my filesystem
was only 2.2TB. Resize2fs output is below:
resize2fs 1.41.9 (22-Aug-2009)
Resizing the filesystem on /dev/vg/lv to 4869357568 (4k) blocks.
Begin pass 2 (max = 32768)
Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 122222)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/vg/lv is now 574390272 blocks long.
After that, I re-mounted and tried doing another online resize, which
resulted in a floating point exception:
resize2fs 1.41.9 (22-Aug-2009)
Filesystem at /dev/vg/lv is mounted on /lv; on-line resizing required
old desc_blocks = 137, new_desc_blocks = 1161
Performing an on-line resize of /dev/vg/lv to 4869357568 (4k) blocks.
Floating point exception
After that, I ran e2fsck -f, which reported that the filesystem was clean.
So... what is expected to work at this point, and what is expected to
be broken with the resize process? Any idea why my fs was shrunk down
to 2.2TB when it was supposed to grow to 18TB?
Thanks!
-Justin
On 2009-10-29, at 15:54, Justin Maggard wrote:
> What is the current expected status of resize2fs support with 64-bit
> filesystems? Specifically, expanding from <16TB to >16TB. I'm using
> the latest code from pu, and seeing some odd things. I'm not sure
> what the 64bit feature flag does exactly, but is the transition not
> handled properly?
This isn't supposed to work at all, and in fact should be disabled.
Firstly, the group descriptors are not big enough to hold the 64-bit
block addresses unless the filesystem was originally formatted > 16TB.
Secondly, the resize code has not been made 64-bit clean.
> So... what is expected to work at this point, and what is expected to
> be broken with the resize process? Any idea why my fs was shrunk down
> to 2.2TB when it was supposed to grow to 18TB?
The filesystem size was truncated to a 32-bit value.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.