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.
> 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.