резюме
Я пытаюсь понять, как рассчитать выравнивание последующих секций оптимально выровненного 32MiB
(65535
сектор), а не обычного 1MiB
(2048 sector
).
фон
Я недавно приобрел 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
Расчет по первому сектору не сложный.
разрешить GNU parted автоматически рассчитать выравнивание
(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
Результатом является выравнивание, которое начинается в секторе 65535
(32MiB
).
вручную рассчитать выравнивание
(optimal_io_size + alignment_offset) / physical_block_size
- От « Как выровнять разделы для лучшей производительности с помощью parted» Ян Чард 30 января 2013 года, ссылаясь на Red Hat Enterprise Linux 6 - Создание раздела 7 ТБ с использованием parted, всегда показывает "Получающийся раздел не выровнен должным образом для лучшей производительности"
Использование данных для SAMSUNG SSD 850 EVO (M.2 1TB)
и применение формулы приводит к
(33553920 + 0) / 512 = 65 535
эта проблема
Обычно при создании раздела я просто добавлял offset + length
предыдущих разделов в качестве начала следующего раздела, например,
(parted) mkpart primary 1MiB 2MiB
(parted) mkpart primary 2MiB 514MiB
(parted) mkpart primary 514MiB 1538MiB
...
Попытка чего-то подобного для 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%
приводит к следующему предупреждению:
Warning: The resulting partition is not properly aligned for best performance.
Ignore/Cancel?
средство
Диск довольно придирчив, и моя лучшая попытка была в расчете точных секторов. К сожалению, это привело к запутанным вычислениям, где я не могу объяснить, почему разделы были оптимально выровнены (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
Насколько я могу судить, каждый сектор должен начинаться с интервала 65535
, что соответствует ~ 32 МБ (или 65535+1 = 32MiB
). Я предполагаю, что смещение байтов равно 0
а не 1
. Дано 1MiB = 2048s
.
Размер первого раздела должен составлять 1 1MiB
, поэтому остановка составляет 65535 + 2048 - 1 = 67582
.
(parted) mkpart primary 65535s 67582s
Если размер предыдущего раздела ниже 32MiB
следующий раздел просто начинается со previous partition offset + 32MiB
. Для раздела 2
в приведенном выше примере он начинается с ~64MiB
(65535s * 2 = 131070s
). Размер должен быть 512 512MiB
(512 * 2048 = 1048576
), следовательно, остановка составляет 131070 + 1048576 - 1 = 1179645
.
(parted) mkpart primary 131070s 1179645s
Пока все хорошо, но что будет оптимальным началом для раздела 3
? Какое смещение является первым доступным интервалом 32 МБ?
1179645 / 65535 ~= 18,000223
В настоящее время используется 18 интервалов и перетекание на 19; поэтому следующий раздел должен начинаться с 19-го интервала?
19 * 65535 = 1245165
Размер должен быть 4096MiB
(4096 * 2048 = 8388608
), следовательно, остановка составляет 1245165 + 8388608 - 1 = 9633772
.
(parted) mkpart primary 1245165s 9633772
Поэтому для следующего раздела
9633772 / 65535 ~= 147,0019
148 * 65535 = 9699180
И так далее.
Я не нашел никакого обсуждения по этому поводу раньше, и мне кажется, что я слишком усложняю разделение.