Bug 529706

> 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

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.

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.

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.

Closing this as wontfix based on comment #3.

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.

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.