Bug 529706 - discrepancy between libparted's reporting of free space and reality
discrepancy between libparted's reporting of free space and reality
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: parted (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Hans de Goede
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-19 11:15 EDT by David Lehman
Modified: 2009-10-22 10:44 EDT (History)
2 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description David Lehman 2009-10-19 11:15:38 EDT
Description of problem:
free space listings from libparted for a fresh dos-labeled disk show the first free sector to be sector 63. However, if you ask it to create/add a partition at start sector 1 it succeeds.

There is a similar issue with the first logical partition in the extended partition: first free sector is reported to be 63 sectors into the extended partition, but a partition can be added at a 1 sector offset.

The parted utility allows the 1s offset for the first primary, but refuses to create the first logical with a 1s offset into the extended partition (libparted allows this).

Version-Release number of selected component (if applicable):
parted-1.9.0-14.fc12

How reproducible:
Always

Steps to Reproduce:
1. Create a fake device using dd (or use a real disk)
2. Create a dos disklabel on it
3. Use libparted to collect free space info
4. Use libparted to create partitions in areas reported
   to be unavailable.
  
Actual results:
libparted falsely reports some regions as not-free

Expected results:
libparted reports accurately on the disk's layout

Additional info:
There is also the matter of the discrepancy between the parted utility and libparted when it comes to the creation of a logical partition at a 1s offset into the extended partition.
Comment 1 Jim Meyering 2009-10-22 05:42:06 EDT
> If I tell parted to create a partition at 0M (empty table) it creates
> partition at an offset of 1s, which I understand to the be size of the
> msdos label. Fair enough. If I explicitly create a partition using
> pyparted (libparted) with start sector 1 it allows me to add the
> partition to the disk. However, if I use libparted to find free regions
> on the disk beforehand, it reports an initial free sector of 63. Where
> is this 63s offset coming from?

[I'm mostly waving my hands.  the folks on #fs @redhat irc probably know more ]
It might be related to something
called BIGDOS format that treats the first 63 sectors specially.
It's to the point that some enterprise-oriented disks
do this for you automatically, and applications have to
detect the unusual alignment.  This is something I'm
working on accommodating (in part) in parted, but it requires
kernel bits that are new in 2.6.32.

> Similarly, when creating the first logical partition in an empty
> extended, parted enforces a 63s offset. libparted agrees that the first
> free region begins 63 sectors into the extended, but then allows me to
> create/add a logical partition at offset 1s if I want to.

Hi Dave,

For the record, I demonstrated via this:

    dev=dev-file
    dd if=/dev/null of=$dev bs=1 seek=4500MB
    parted -s $dev mklabel msdos
    parted -s $dev mkpart ext 1s 300s
    parted -s $dev mkpart log 1s 100s
    Error: You requested a partition from 512B to 51.2kB.
    The closest location we can manage is 16.4kB to 65.0kB.
    [Exit 1]

That diagnostic is a lie ;-)
It can indeed to better, but you have to be explicit:

    $ parted -s $dev mkpart logical 2s 100s
    $ parted -s $dev unit s print
    Model:  (file)
    Disk /home/j/w/co/parted/6/parted/dev-file: 8789062s
    Sector size (logical/physical): 512B/512B
    Partition Table: msdos

    Number  Start  End   Size  Type      File system  Flags
     1      1s     300s  300s  extended               lba
     5      2s     100s  99s   logical
Comment 2 David Lehman 2009-10-22 09:48:47 EDT
Ok, but there's still at least one bug here to fix. Even if parted is going to be wrong because of one partition format, it should at least agree with itself. Don't tell me the first free sector is 63 if it isn't. And if I shouldn't create a partition that starts before sector 63, don't let me. Pick one and stick with it.
Comment 3 Jim Meyering 2009-10-22 09:57:11 EDT
Hi Dave,

Sure it's a minor and relatively harmless bug, but the cost (at least as I see it) of fixing it would be far too high (in risk) to make it worth addressing.  The "constraint satisfaction" code in question is relatively fragile in that it is almost impossible to make small, targeted changes to address a problem like this without inducing unwanted changes (potentially serious) elsewhere.  And since we don't yet have anywhere near the test coverage required to be confident we're not breaking something important...

I suggest we table this for a long time.
Comment 4 David Lehman 2009-10-22 10:17:02 EDT
The problem is that the only way to use parted is to try to add something and see if it works. Try to add partitions one at a time. Or accept that parted may make significant changes to your requests without any way to predict this in advance. I am trying to set up a layout for multiple partitions before adding them, but I cannot do it because of inconsistencies like this. Parted magically aligning partitions to cylinder boundaries and similar unwanted "improvements" like this are driving me crazy.

If you don't think the reward is worth the risk, fine -- it's your call.
Comment 5 Hans de Goede 2009-10-22 10:19:10 EDT
Closing this as wontfix based on comment #3.
Comment 6 Jim Meyering 2009-10-22 10:34:51 EDT
Hi Dave,

One way to avoid most of parted's annoying tendancy to select partition boundaries different than we specify is to specify them as multiples of sectors.
E.g.,

  parted -s /dev/whatever mkpart primary linux-swap 60s 100s

note the "s" suffixes.
With that, parted is less likely to "adjust" those numbers.

When I create partition tables, I try to align to even larger multiples, like 128KiB or even 1MiB.  Doing that, I've found that parted usually complains only when there's a very good reason.
Comment 7 David Lehman 2009-10-22 10:44:28 EDT
Everything I do is in sectors already. I use libparted via pyparted -- not the parted utility.

My complaint is that parted does not provide a way to query/predict when it will insist on realigning something. If you're using /sbin/parted and screwing around making some partitions interactively that is fine behavior; but if you are trying to set up a layout non-interactively based on a set of requirements, parted provides no way to tell you "if I create an extended partition starting here, where then can I start the first logical partition?".

It's funny, because I have repeatedly heard that /sbin/parted is really just an example, or a proof of concept, for libparted. You seem to be saying that /sbin/parted is the only good way to go.

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