linux-ext4 - EXT4 >16TB resize2fs support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 Oct 2009 14:54:11 -0700
From:	Justin Maggard <jmaggard10@...il.com>
To:	ext4 development <linux-ext4@...r.kernel.org>
Subject: EXT4 >16TB resize2fs support

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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html