Bug 584057

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