Why fdisk adds half kibibyte sometimes?

Question

I'm trying to partition a 1440 KiB floppy disk image using fdisk (util-linux, v2.31.1).

However, the tool is seemingly adding a 512-byte sector, no matter what units I use, and I can't tell why.

---

This is what I did:

Created a new DOS disklabel [...]

Command (m for help): n
[...]
First sector (1-2879, default 1): 2048
Last sector, +sectors or +size{K,M,G,T,P} (63-2879, default 2879): +1K

Created a new partition 1 of type 'Linux' and of size 1.5 KiB.

Whoa! 1.5 KiB!?

I tried using the sector count, getting the same result:

Last sector, +sectors [...]: +2

Created a new partition 1 of type 'Linux' and of size 1.5 KiB.

Now, if I use a file big enough, fdisk behaves differently with the first notation:

First sector (2048-131071, default 2048): 2048
Last sector, [...]: +1K

Created a new partition 1 of type 'Linux' and of size 1 KiB.

Not so with the second one:

Last sector, +sectors [...]: +2

Created a new partition 1 of type 'Linux' and of size 1.5 KiB.

Is this the expected behaviour? I guess it is, but why?

Answer 1

However, the tool is seemingly adding a 512-byte sector, no matter what units I use,
...
Now, if I use a file big enough, fdisk behaves differently with the first notation:
...
Is this the expected behaviour?

Apparently yes, and seems to be a bug of the "plus one" variety.
When you specify "+N" or "+" (instead of an absolute sector number) for the last sector, the utility seems to utilize this quantity as the number of sectors in (or the size of) the new partition, and adds this number to the starting sector number.

In other words, the proper calculation should be

<last sector> = <start sector> + <sector count> - 1  

But apparently the utility neglects to subtract one sector from this total to adjust the count to a displacement.

When the size of the new partition is small (i.e. just two sectors), then this "plus one" bug is quite obvious.
The actual source code needs to be inspected to determine why there is a correlation/dependency on the available size of the device.

The workaround to this apparent bug is to explicitly specify the last sector using a sector number.
For example if the starting sector is 2048, and the partition size is to be 1K bytes, then specify the last sector as 2049.

---

Since this "extra" sector is at the end of the new partition, this issue would be unrelated to partition alignment.
Partition alignment (and guard cylinder/track/sectors) would be applied to modify the start of a new partition.
That is, sectors would be reserved "in front of" the new partition, and not be part of any partition.
Those sectors would be unallocated, essentially wasted, and cannot be used (by any filesystem).
Alignment does not affect the size of the new partition.
The issue you describe relates to partition size, and not its alignment.

---

I'm trying to partition a 1440 KiB floppy disk image

Floppy disks are not supposed to be partitioned. There is just a boot sector.
The MBR and partition table is for hard disks (and SSDs).

---

ADDENDUM

Apparently there is some code in util-linux-2.31.1/libfdisk/src/dos.c that tries to adjust the end of the partition so that the next partition will be aligned!

static int add_partition(struct fdisk_context *cxt, size_t n,
             struct fdisk_partition *pa)
{
    ...

    if (isrel && stop - start < (cxt->grain / fdisk_get_sector_size(cxt))) {
        /* Don't try to be smart on very small partitions and don't align so small sizes */
        isrel = 0;
        if (stop > start)
            stop -= 1;
        DBG(LABEL, ul_debug("DOS: don't align end of tiny partition [start=%ju, stop=%ju, grain=%lu]",
            (uintmax_t)start,  (uintmax_t)stop, cxt->grain));
    }

    if (stop < limit && isrel && alignment_required(cxt)) {
        /* the last sector has not been exactly requested (but
         * defined by +size{K,M,G} convention), so be smart and
         * align the end of the partition. The next partition
         * will start at phy.block boundary.
         */
        stop = fdisk_align_lba_in_range(cxt, stop, start, limit);
        if (stop > start)
            stop -= 1;
        if (stop > limit)
            stop = limit;
        DBG(LABEL, ul_debug("DOS: aligned stop: %ju", (uintmax_t) stop));
    }

Some debug output (i.e. a version of the utility with debugging enabled) would help clarify what is going on.