Red Hat Bugzilla – Bug 584057
[RHEL-5] parted mkpartfs command does not handle partition >2TB
Last modified: 2012-02-21 00:43:24 EST
Description of problem: Due to truncation of calculated block addresses the ext2 mkpartfs code does not correctly handle partitions greater than 2TB. Version-Release number of selected component (if applicable): parted-1.8.1-27.el5 How reproducible: Always. Steps to Reproduce: 1. Use parted to create ext2 filesystem on partition >2TB 2. fsck the partition. 3. Alternate with details. 1.Just create a filesystem whose size is 2TB or more by the mkpartfs subcommand as follows. # parted /dev/sdb ... (parted)mklabel gpt (parted)mkpartfs primary ext2 0 -0 (parted)q 2.Get the dumpe2fs data of the above created filesystem. # dumpe2fs /dev/sdb1 3.Confirm Group 16384 in the dumpe2fs data. Actual results: errors. Expected results: success. Additional info:
Created attachment 407866 [details] patch for block overflow
Hi Martin, Thanks for the report. If at all possible, please avoid using parted's FS-manipulation code, since it is nowhere near as robust as what you'll find in FS-specific packages like e2fsprogs. Upstream has deprecated all FS-manipulation operations (you'll get a warning), and plans to remove the code altogether RSN. The only exceptions are FAT and HFS resizing, for which there seems to be no other source of free code.
Hi Martin, As Jim explained the mkfs functionality of parted is not the best way to create filesystems. Still we cannot just take this away in RHEL-5.x, as your patch looks pretty safe to me I'm going to devel ack this and fix this for the next RHEL-5.x release. Regards, Hans
Thanks for dealing with that, Hans. That sounds like the right thing for 5.x. Martin, beware that depending on FS type, stating sector, length, and probably the phase of the moon, parted's FS creation/move/check commands may malfunction in dangerously subtle (and sometimes not-so-subtle) ways. What do you think about making RHEL-5.x parted issue a warning for the file system operations that are now deprecated upstream? Perhaps that's too invasive. Is there some other way to encourage people to adapt?
FYI, I'm fixing this upstream, too, and adding the following "expensive" test: dd bs=1 seek=2049G of=big < /dev/null parted -s big -- mklabel gpt mkpartfs primary ext2 2048s -0 u s p It looks like the result will occupy at least 32GB.
Martin, I tried to reproduce the failure like this: dd bs=1 seek=2049G of=big < /dev/null parted -s big -- mklabel gpt mkpartfs primary ext2 2048s -0 u s p sudo losetup -f -r -o $((1024*1024)) --show big sudo fsck.ext2 -n /dev/loop0 sudo losetup -d /dev/loop0 Parted's FS creation inflates "big" to occupy 33GB, and for me on i686 F13, the fsck succeeded. Of course, if you're already using /dev/loop0, you'll get a different one...
I've prepared an update for this for 5.6 in my pkg checkout now all we need is the necessary flags to commit this.
Martin, did fsck fail for you? So far (using the procedure in comment 11), for me it does not.
Martin, to be clear, I built parted from upstream source, following instructions at http://git.debian.org/?p=parted/parted.git;a=blob;f=README-hacking then used the just-built parted in the procedure of comment 11. With that, I was unable to reproduce the failure on i686 Fedora 13. Does that procedure, with any version of parted, evoke a failure for you?
The procedure in comment 11 is slightly misleading, since it uses "primary" as the partition name in a GPT table. Also, it assumes that losetup ... --show prints loop0. Here's a better procedure: dd bs=1 seek=2049G of=big < /dev/null parted/parted -s big -- mklabel gpt mkpartfs p1 ext2 2048s -0 u s p loop=$(sudo losetup -f -r -o $((1024*1024)) --show big) sudo fsck.ext2 -n $loop sudo losetup -d $loop env rm big For reference, here's most of the output I get on i686. Note, whereas the above was with F13, this is with F12: --------------------------------------- $ parted/parted -s big -- mklabel gpt mkpartfs p1 ext2 2048s -0 u s p WARNING: you are attempting to use parted to operate on (mkpartfs)... ... Model: (file) Disk /home/meyering/w/co/parted/parted/big: 4297064448s Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 2048s 4297064414s 4297062367s ext2 primary $ sudo losetup -f -r -o $((1024*1024)) --show big [sudo] password for meyering: /dev/loop0 $ sudo fsck.ext2 -n /dev/loop0 e2fsck 1.41.9 (22-Aug-2009) /dev/loop0: clean, 11/268566528 files, 8428101/537132795 blocks $ sudo losetup -d /dev/loop0 $ env rm big
fsck's -f option was the missing piece, as martin suggested on IRC. This reproduces the problem: dd bs=1 seek=2049G of=big < /dev/null parted/parted -s big -- mklabel gpt mkpartfs p1 ext2 2048s -0 u s p loop=$(sudo losetup -f -o $((1024*1024)) --show big) sudo fsck.ext2 -f $loop sudo losetup -d $loop env rm big So I'll apply the patch shortly. Thanks again, Martin. Not sure if I'll add such an expensive (in disk space and time) test.
Moving to 5.7 proposed list since parted did not make the approved component list for 5.6.
Moving to 5.8, the patch is already in upstream and we have a clear reproducer. This should not be taken as an endorsement of the parted fs code -- just don't use it.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: The mkpartfs command did not correctly handle partitions greater than 2 terabytes (TB) due to truncation of calculated block addresses. As a consequence, mkpartfs terminated with an error message. With this update, mkpartfs can now handle partitions greater than 2TB correctly.
Reproduced on 5.7 KVM guest / parted-1.8.1-28.el5 1) dd bs=1 seek=2049G of=big.img < /dev/null 2) Attach bitg.img as second disk to the guest and start it 3) # parted /dev/vdb ... (parted)mklabel gpt (parted)mkpartfs primary ext2 0 -0 (parted)q 4) # fsck.ext2 -f /dev/vdb1 e2fsck 1.39 (29-May-2006) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: +(536870912--536870913) +(536871044--536871555) +(536903680--536903681) +(536903812--536904323) +(536936448--536936449) +(536936580--536937091) +(536969216--536969217) +(536969348--536969859) +(537001984--537001985) +(537002116--537002627) +(537034752--537034753) +(537034884--537035395) +(537067520--537067521) +(537067652--537068163) +(537100288--537100289) +(537100420--537100931) Fix<y>? yes /dev/vdb1: ***** FILE SYSTEM WAS MODIFIED ***** /dev/vdb1: 11/268566528 files (0.0% non-contiguous), 8428101/537133047 blocks Re-tested on RHEL 5.8 KVM guest / parted-1.8.1-29.el5 4) # fsck.ext2 -f /dev/vdb1 e2fsck 1.39 (29-May-2006) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/vdb1: 11/268566528 files (0.0% non-contiguous), 8428101/537133047 blocks No errors reported. Moving to VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0192.html