When I create a new partition with +sectors, fdisk creates one
that is one sector too large:


Command (m for help): n
Partition number (1-128, default 1):
First sector (2048-7814037134, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-7814037134, default 7814035455): +2097152

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

Command (m for help): p
Disk /dev/sdb: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: ST4000NM0245-1Z2
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: DDA88AFF-1E6A-7448-AB5A-85470938DBC7

Device       Start        End    Sectors  Size Type
/dev/sdb1     2048    2099200    2097153    1G Linux filesystem


I’ve only tested that with GPT at the moment.

Dixi quod…

Same for MBR:


Command (m for help): n
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-1000215215, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-1000215215, default 1000215215): +2048

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

Command (m for help): p
Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: SAMSUNG MZVLB512HBJQ-00000
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x3cca69b4

Device         Boot Start   End Sectors Size Id Type
/dev/nvme0n1p1       2048  4096    2049   1M 83 Linux


bye,
//mirabilos

Looping in upstream.

Also from Thorsten:

I've briefly reproduced this with util-linux 2.41-rc1 on a loopdev.

From what I understand Thorsten is saying, he would expect, for a
partition that starts at sector 2048, when its created with "+2048"
size, to have a number of 2048 sectors, not 2049 as shown above.

I haven't looked at the code if this is intentional or what the
reason could be.

Best,
Chris

This is how fdisk has functioned since its inception. I noticed this
in the v2.13 code and was able to replicate it with v2.14 (year 2008).

The convention of +<sectors> is strictly evaluated as <first> + <size>,
without subtracting 1. This is different from +<size>{M,G,T,..} where the final
size is reduced by 1 and aligned to the disk I/O limits.

I have doubts about changing this after 20 years due to backward
compatibility. Additionally, it should be noted that people use 'echo
"something" | fdisk' in scripts ...

    Karel

is always <first> + <size> - 1, compare C arrays.

Ouch. Then I agree changing this is not prudent at this point,
but please *do* clarify this in the question text. Let me
propose new text… hmm, let me see the old…

… let’s go multiline for this:

| Last sector (2048-7814037134, default 7814035455),
| +/-sectors from first sector, or +/-size{K,M,G,T,P}:

I expected the -1 (fencepost) but not the alignment, but
that makes sense.

Indeed, I do so myself, though in scripts I have so far
always calculated the last sector manually, it was only
that day interactively when I wanted to enter a manual
size in sectors: specifically, a split-mode dm-integrity
<https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=useful-scripts/useful-scripts.git;a=blob;f=integritysetup/README.txt;h=76a7a67cb35d34c08eeeb916ce26f1832febf922;hb=HEAD#l113>
partition (where I manually aligned the result from the
isize-p script in the aforementioned documentation to a
multiple of 2048).

────────────────────────────────────────────────────────────────────────

So, would you please consider changing the wording, at
least, upstream? (And, perhaps, throw in another sentence
or two into the manpage, stating that the +sectors syntax
isn’t meant to express size, unlike the others.)

Thanks,
//mirabilos