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]
Message-ID: <150c16850910291454j18db2729m572dc0fe22658f1e@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ