Red Hat Bugzilla – Bug 241285
Cannot resize an 8TB ext3 filesystem to 16TB with resize2fs.
Last modified: 2010-10-22 11:19:12 EDT
Description of problem: I have a file system on an LVM volume that is 8TB. I add 8TB more of storage, do the vgextend and lvextend but the resize2fs fails. Version-Release number of selected component (if applicable): How reproducible: This happens everytime if the LVM volume is not striped. I have gone over the 8TB mark if the volume is striped. I don't know why that is yet. Steps to Reproduce: # vgcreate vg0 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1 Volume group "vg0" successfully created # lvcreate -L 8T -n bigdisk vg0 Logical volume "bigdisk" created # mkfs.ext3 -F /dev/vg0/bigdisk mke2fs 1.39 (29-May-2006) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 1073741824 inodes, 2147483648 blocks 107374182 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=4294967296 65536 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 Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 20 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. # vgextend vg0 /dev/sdh1 /dev/sdi1 Volume group "vg0" successfully extended # lvextend -L +8T /dev/vg0/bigdisk Extending logical volume bigdisk to 16.00 TB Logical volume bigdisk successfully resized # resize2fs -f /dev/vg0/bigdisk resize2fs 1.39 (29-May-2006) resize2fs: File too large while trying to determine filesystem size Actual results: Resize2fs can't determine the partition size from the LVM volume. Expected results: The system should successfully resize the file system. Additional info:
# lvextend -L +8T /dev/vg0/bigdisk Extending logical volume bigdisk to 16.00 TB Logical volume bigdisk successfully resized # resize2fs -f /dev/vg0/bigdisk resize2fs 1.39 (29-May-2006) resize2fs: File too large while trying to determine filesystem size How big is /dev/vg0/bigdisk, actually? (/proc/partitions?) This may be an issue that we actually need 16TB - one block; perhaps the tools should just round down silently in this case. Is there anything in dmesg when you try this? I'll mock it up on Monday and give it a shot, see where the EFBIG is coming from. Thanks, -Eric
So, technically this is NOTABUG. The maximum filesystem size allowed is (2^32 - 1) filesystem blocks, or actually just *shy* of 16T. Unfortunately, for LVM, it's a lot easier to lvextend -L +8T than to lvextend -L +8796093018112 ... BTW, no need for further testing on your part, I recall running into this too. It boils down to max offset vs. size; a 2-byte filesystem has a maximum offset of 1 block; the max offset fits in 1 bit, but the size (2) does not. And, ext3 carries around size in 32-bit containers, so max size is (2^32-1)*blocksize. I'll see if Ted would be willing to take an e2fsprogs patch to silently round down in this case, or maybe better, if the underlying volume at mkfs or growfs time is larger than can be fully utilized, it could issue a warning and simply create the maximum *possible* filesystem size. -Eric
Posted patch upstream, should be included in the next release of e2fsprogs http://article.gmane.org/gmane.comp.file-systems.ext4/4472
I'll move this over to me to shepherd it into RHEL5.4. Thanks for the patch Josef!
Now building in e2fsprogs-1.39-22.el5.
Note for QA: This change also removed the need for "-F" to create an ext3 filesystem > 8T, might be worth a test as well. Thanks, -Eric
*** Bug 495478 has been marked as a duplicate of this bug. ***
~~ Attention - RHEL 5.4 Beta Released! ~~ RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner! If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity. Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value. Questions can be posted to this bug or your customer or partner representative.
Adding a few partners for their possible testing on this.
Sorry, I completed this late at night and forgot the BZ!! Yes, this worked fine --- VERIFIED. George
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1291.html