Summary:
resize2fs fails on large (>16TB) volumes.
Version: Latest from GIT, no local changes, as of today, 2010/08/03. (ccc7cf0?)
Kernel: 2.6.32-24-server x86_64
Steps to reproduce:
1) Create 20TB LV
2) Create ext4 filesystem (with options 64-bit, lazy_itable_init=1):
./mke2fs -t ext4 /dev/cluster/storage2
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
2684354560 inodes, 5368709120 blocks
268435456 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=7516192768
163840 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544, 1934917632,
2560000000, 3855122432
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 25 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
3) Attempt any resize operation, ex: sudo ./resize2fs /dev/cluster/storage2 (after growing LV container)
Result:
resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/cluster/storage2 to 4831838208 (4k) blocks.
./resize2fs: Filesystem too large to use legacy bitmaps while trying to resize /dev/cluster/storage2
Please run 'e2fsck -fy /dev/cluster/storage2' to fix the filesystem
after the aborted resize operation.
Reproducible: Always.
Notes:
-Also reproducible when growing volume, e.g. growing 18TB volume into 20TB.
-Works fine with volumes under and up to 16TB
I have teh same problem with an 24TB filesystem. Is there anything new about this bug or is it expected behavoir?
thx