1

резюме

Я пытаюсь понять, как рассчитать выравнивание последующих секций оптимально выровненного 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%

Результатом является выравнивание, которое начинается в секторе 65535 (32MiB).

вручную рассчитать выравнивание

(optimal_io_size + alignment_offset) / physical_block_size

Использование данных для 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

И так далее.

Я не нашел никакого обсуждения по этому поводу раньше, и мне кажется, что я слишком усложняю разделение.

2 ответа2

1

Некоторые говорят, что важно выровнять SSD по размерам ERASE BLOCK и NAND PAGE.

У evo 840, по-видимому, есть необычные параметры блока стирания и nand: 1536kb и 8k. Я не уверен в 850 (Samsung не хочет раскрывать эту информацию (коммерческая тайна))...

Я придумал универсальное значение выравнивания, которое охватывает все известные ssd, их блоки стирания и размеры страниц nand. Я рекомендую использовать смещение 6291456 байт (сектор 12288 (6144kb = 6 МБ) или любое кратное (12 МБ, 18 МБ, 24 МБ и т.д.). Это смещение должно работать с любым известным ssd (или hdd в этом отношении). В зависимости от размера NAND PAGE, с которым вы имеете дело, я бы порекомендовал сопоставить ваш размер ALLOCATION UNIT с размером NAND PAGE по возможности во время форматирования, чтобы избежать проблем с READ MODIFY WRITE, однако 4k также должно быть приемлемым значением для почти любого ssd, если это необходимо. Даже если ваш диск внутренне перегружен, я все равно оставлю 10% диска неформатированным, чтобы избежать проблем ЗАПИСИ УСИЛЕНИЯ (я оставляю 17% ОП). Я также рекомендую, когда вы определите свои параметры наверняка, НЕ используя опцию "БЫСТРЫЙ ФОРМАТ", используйте обычный формат, это не займет много времени для SSD. Дайте мне знать, если это поможет вам или нет, и не стесняйтесь добавлять любые идеи, которые вы можете иметь ....

PS Я считаю, что parted удобен в использовании и предпочитаю gdisk. В gdisk вы можете установить "установить значение выравнивания сектора", используя "l" в меню xpert. Когда вы сделаете это, все созданные разделы будут автоматически рассчитаны для начала с ближайшего значения, кратного этому значению, что приведет к правильному выравниванию всех разделов при условии, что заданное значение является правильным.

0

Используя GPT fdisk Tutorial gdisk он автоматически вычислял выравнивание последующих разделов, используя префикс + , например,

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

создает 2GiB (гибибайт) из последнего предоставленного сектора.

Перегородки выровнены на 2048s . GNU parted подтверждает, что разделы проходят align-check minimal выравнивания, но не align-check optimal .

blockdev --getalignoff /dev/sdx возвращает 0 .

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .