3
1
summary
I am trying to understand how to calculate the alignment of subsequent partitions of an optimal aligned 32MiB
(65535
sector) rather the usual 1MiB
(2048 sector
).
background
I recently purchased a SAMSUNG SSD 850 EVO (M.2 1TB)
,
# cat /sys/block/sdx/queue/optimal_io_size
> 33553920
# cat /sys/block/sdx/queue/minimum_io_size
> 512
# cat /sys/block/sdx/alignment_offset
> 0
# cat /sys/block/sdx/queue/physical_block_size
> 512
# cat /sys/block/sdx/queue/logical_block_size
> 512
# cat /sys/block/sdx/queue/hw_sector_size
> 512
# fdisk -l
> Disk /dev/sdx: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 33553920 bytes
> Disklabel type: gpt
Calculating the first sector is not difficult.
allow GNU parted to automatically calculate the alignment
(parted) mkpart primary 0% 100%
- https://wiki.archlinux.org/index.php/GNU_Parted#Alignment
- cf https://unix.stackexchange.com/questions/38164/create-partition-aligned-using-parted
The result is an alignment that begins at sector 65535
(32MiB
).
manually calculate the alignment
(optimal_io_size + alignment_offset) / physical_block_size
- From How to align partitions for best performance using parted By Ian Chard On 30th January 2013 referencing Red Hat Enterprise Linux 6 - Creating a 7TB Partition Using parted Always Shows "The resulting partition is not properly aligned for best performance"
Using the data for SAMSUNG SSD 850 EVO (M.2 1TB)
and applying the formula results in
(33553920 + 0) / 512 = 65 535
the problem
Usually when creating partition I simply added the offset + length
of the previous partitions as the start for the next partition, for example,
(parted) mkpart primary 1MiB 2MiB
(parted) mkpart primary 2MiB 514MiB
(parted) mkpart primary 514MiB 1538MiB
...
Attempting to something similar for SAMSUNG SSD 850 EVO (M.2 1TB)
(parted) mkpart primary 65535s 67582s # OK ~32MiB 33MiB
(parted) mkpart primary 67583s 100%
or
(parted) mkpart primary 33MiB 100%
results in the following warning:
Warning: The resulting partition is not properly aligned for best performance.
Ignore/Cancel?
remedy
The drive is rather picky, and my best attempt has been by calculating exact sectors. Unfortunately this has resulted in convoluted calculations where I cannot explain why the partitions have been optimally aligned (align-check optimal <partition number>
).
(parted) unit s
(parted) print free
Number Start End Size File system Name Flags
34s 65534s 65501s Free Space
1 65535s 67582s 2048s
67583s 131069s 63487s Free Space
2 131070s 1179645s 1048576s
1179646s 1245164s 65519s Free Space
3 1245165s 9633772s 8388608s
9633773s 9699179s 65407s Free Space
4 9699180s 1953467279s 1943768100s
1953467280s 1953525134s 57855s Free Space
As far as I can tell each sector has to begin at a 65535
interval, which correspond to ~32MiB (or 65535+1 = 32MiB
). I assume that the bytes offset is 0
and not 1
. Given 1MiB = 2048s
.
The first partition size is to be 1MiB
, therefore, the stop is 65535 + 2048 - 1 = 67582
.
(parted) mkpart primary 65535s 67582s
If the previous partition is below 32MiB
the next partition simply begins at previous partition offset + 32MiB
. For partition 2
in the above parted example it begins at ~64MiB
(65535s * 2 = 131070s
). The size is to be 512MiB
(512 * 2048 = 1048576
), therefore, the stop is 131070 + 1048576 - 1 = 1179645
.
(parted) mkpart primary 131070s 1179645s
So far so good, but what would be the optimal start for partition 3
? Which offset is the first available 32MiB interval?
1179645 / 65535 ~= 18,000223
Currently using 18 intervals and spilling over on a 19th; the next partition should therefore begin on the 19th interval?
19 * 65535 = 1245165
The size is to be 4096MiB
(4096 * 2048 = 8388608
), therefore, the stop is 1245165 + 8388608 - 1 = 9633772
.
(parted) mkpart primary 1245165s 9633772
For the next partition therefore
9633772 / 65535 ~= 147,0019
148 * 65535 = 9699180
And so on and so forth.
I have not found any discussion about this before, and it feels like I am over-complicating the partitioning.
Something is wrong, I can't trust that the optimal size is not a power of 2 (65535), while 65536 is a power of 2. I'm almost sure that this is a bug somewhere. I see you're using GPT, but fdisk seems to have problems with DOS partition at least (https://unix.stackexchange.com/a/303358/130000)
– pim – 2017-11-02T14:49:20.797Following up on your [@pim] hint I also found https://superuser.com/questions/352572/why-does-the-partition-start-on-sector-2048-instead-of-63 which references The gen on disc partition alignment. which recommends Rod Smith's gdisk. Using
– user212827 – 2017-11-02T15:32:21.037gdisk verify disk
results inCaution: Partition [1-4] doesn't begin on a 8-sector boundary. This may result in degraded performance on some modern (2009 and later) hard disks.