Bug 241285 - Cannot resize an 8TB ext3 filesystem to 16TB with resize2fs.
Cannot resize an 8TB ext3 filesystem to 16TB with resize2fs.
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: e2fsprogs (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: 5.4
Assigned To: Eric Sandeen
:
: 495478 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-24 16:29 EDT by Barry Donahue
Modified: 2010-10-22 11:19 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 05:46:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Barry Donahue 2007-05-24 16:29: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:
Comment 1 Eric Sandeen 2007-09-23 10:51:14 EDT
# 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
Comment 2 Eric Sandeen 2007-09-23 23:19:57 EDT
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
Comment 3 Josef Bacik 2008-01-23 16:13:50 EST
Posted patch upstream, should be included in the next release of e2fsprogs

http://article.gmane.org/gmane.comp.file-systems.ext4/4472
Comment 6 Eric Sandeen 2009-03-18 16:07:45 EDT
I'll move this over to me to shepherd it into RHEL5.4.  Thanks for the patch Josef!
Comment 7 Eric Sandeen 2009-03-18 18:02:08 EDT
Now building in e2fsprogs-1.39-22.el5.
Comment 8 Eric Sandeen 2009-04-18 10:16:20 EDT
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
Comment 9 Eric Sandeen 2009-04-18 10:17:02 EDT
*** Bug 495478 has been marked as a duplicate of this bug. ***
Comment 13 Chris Ward 2009-07-03 13:57:28 EDT
~~ 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.
Comment 18 Andrius Benokraitis 2009-07-14 10:07:29 EDT
Adding a few partners for their possible testing on this.
Comment 20 George Beshers 2009-07-29 16:15:33 EDT

Sorry,

I completed this late at night and forgot the BZ!!
Yes, this worked fine --- VERIFIED.

George
Comment 23 errata-xmlrpc 2009-09-02 05:46:53 EDT
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

Note You need to log in before you can comment on or make changes to this bug.