storage device alignment -- calculate the alignment of subsequent partitions of an optimal aligned 32MiB

Question

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.

Answer 1

Using GPT fdisk Tutorial gdisk it automatically calculated the alignment of subsequent partitions when prefixed with +, for example,

Last sector (8390656-15634398, default = 15634398) or {+-}size{KMGTP}: +2G

creates 2GiB (gibibyte) from the last provided sector.

The partitions are aligned at 2048s. GNU parted confirms that the partitions are align-check minimal but not align-check optimal.

The blockdev --getalignoff /dev/sdx returns 0.

Answer 2

Some say that it is important to align SSDs along the ERASE BLOCK and NAND PAGE SIZES.

evo 840 apparently has uncommon erase block and nand parameters: 1536kb and 8k I'm not certain of the 850 (samsung is reluctant to release this info (trade secret))...

I've come up with a universal alignment value that covers all known ssd's and their erase block and nand page sizes. I recommend using an offset of 6291456 bytes (sector 12288 (6144kb=6mb) or any multiple (12mb, 18mb, 24mb, etc.). This offset should work with any known ssd (or hdd for that matter). Depending on the NAND PAGE SIZE you are dealing with I would recommend matching your ALLOCATION UNIT SIZE to the NAND PAGE SIZE when possible during format to avoid READ MODIFY WRITE issues, however 4k should also be an acceptable value for almost any ssd, if necessary. Even if your drive is over-provisioned internally I'd still leave 10% of the disk unformatted to help avoid WRITE AMPLIFICATION problems (I leave 17% OP). I also recommend, when you've determined your parameters for certain, NOT using the "QUICK FORMAT" option, do the normal format, it won't take a long time for an SSD. Let me know if this helps you or not and feel free to add any ideas that you may have....

PS I find parted to be combersome to use and prefer gdisk. In gdisk you can set the "set the sector alignment value" using "l" under the xpert menu. When you do that all partitions created will automatically be calculated to start at the nearest multiple of that value, resulting in all partitions being properly aligned, provided that the given value is correct.

Answer 3

This optimal I/O size is wrong, the bug is referenced many times like on ubuntu, on redhat. Th more informative may be this blog page.

In any case this 65535 is only the maximal value on two bytes, it does not even align on 4 or 8 X 512bytes sectors. The kernel, parted, lvm are wrongly following it; don't try to comply with it.