SSD, размер стираемого блока и LVM: PV на необработанном устройстве, выравнивание

Я хочу установить новый SSD и использовать все устройство в качестве PV для LVM - другими словами: я не планирую размещать на этом устройстве даже один раздел. Поэтому выравнивание разделов на блоках стирания не требуется.

Вопросы)

Достаточно ли установить --dataalignment к размеру стираемого блока, когда pvcreateи --physicalextentsize к кратному размеру блока стирания, когда vgcreateING?

Итак, при условии, что мой SSD имеет размер стираемого блока 1024 КБ, можно ли

  • pvcreate --dataalignment 1024k /dev/ssd
  • vgcreate --physicalextentsize $(( x * 1024 ))k ...

Что-нибудь еще, чтобы принять во внимание?

Предполагая, что я поместил ext4-файловые системы на LV в этой VG, было бы неплохо выровнять ext4-экстенты по размеру LVM-PE, верно? То есть ext4-экстенты должны быть того же размера или кратны LVM-PE-размеру?

Спасибо за любые разъяснения!

Источник

2 ответа

Да, я также проверил все расположение дисков MBR/PBR/GPT/MD/LVM на диске и пришел к такому же выводу.

В вашем случае (LVM на необработанном диске), если LVM-PE(физический экстент) выровнен на 1 МБ с pvcreate, вы можете быть уверены, что все последующее распределение данных будет выровнено, пока вы сохраняете размер выделения на (1 МБ * N),

Поскольку и "vgcreate -s", и "lvcreate -L" по умолчанию обрабатывают размер без единицы как значение МБ, вам, вероятно, не нужно сильно заботиться о выравнивании после того, как вы правильно выполнили pvcreate. Только убедитесь, что вы не указали размер в%/PE (для lvcreate -l) и B(байт)/S(512B - сектор всегда равен 512B в LVM)/K(КБ) (для vgcreate -s и lvcreate -L).

=== добавлено для уточнения ===

Точно так же, в то время как SSD может иметь размер стираемого блока 1024 КБ как целое устройство, размер стираемого блока каждой внутренней флэш-микросхемы / размер страницы страницы, вероятно, составляет около 32 КБ-128 КБ / 512 ББ-8 КБ.

Хотя это зависит от контроллера каждого твердотельного накопителя, штраф за ввод-вывод из-за дополнительного цикла чтения-изменения-записи, вероятно, не произойдет, если вы сохраняете свою запись выровненной по размеру стираемого блока каждого внутреннего чипа, который составляет от 32 КБ до 128 КБ выше. пример. Просто вы хотите, чтобы один запрос на запись был достаточно большим (= размер стираемого блока SSD как устройства в целом), чтобы вы могли ожидать более высокой производительности, эффективно используя все внутренние микросхемы / каналы.

Насколько я понимаю, выравнивание в 1024 КБ - это всего лишь мера безопасности, поскольку функция микросхемы контроллера зависит от поставщика, а спецификация флэш-микросхемы быстро меняется. Более важно, чтобы запрос на запись на уровне ОС выполнялся в большом пакете (в данном случае 1024 КБ).

Теперь, сказав, что выполнение mkfs (8) для выровненного 1MB блока LVM почти наверняка нарушит выравнивание 1MB для данных / метаданных на уровне файловой системы. Большинство файловых систем заботится только о выравнивании 4 КБ, поэтому, вероятно, оно не идеально подходит для твердотельных накопителей (но, IIRC, последние fs, такие как btrfs, пытаются сохранить выравнивание 64 КБ + при выделении внутреннего смежного блока). Но у многих файловых систем есть возможность связывать записи (например, конфигурация с полосой), чтобы получить производительность от RAID, поэтому ее можно использовать для того, чтобы сделать запрос записи на SSD почти оптимальным.

Я действительно хочу подкрепить свое утверждение фактическими данными, но это было действительно трудно доказать, поскольку современный контроллер SSD настолько интеллектуален и не будет сильно снижать производительность, как только размер выравнивания и размер записи "достаточно велики". Просто убедитесь, что он не плохо выровнен (избегайте <4KB-aligment любой ценой) и не слишком мал (1024KB достаточно большой).

Кроме того, если вы действительно заботитесь о потере ввода-вывода, дважды проверьте отключение кеша устройства и сравнительный тест с синхронизированным тестом чтения-записи-перезаписи.

Источник

Насколько я понимаю, значения по умолчанию уже достаточно хороши. Я не думаю, что вам нужно беспокоиться о параметре --dataalignment, так как LVM автоматически попытается выровнять все на основе экспортируемых значений sysfs, см. Параметр "data_alignment_detection" в lvm.conf:

# By default, the start of a PV's data area will be a multiple of
# the 'minimum_io_size' or 'optimal_io_size' exposed in sysfs.
# - minimum_io_size - the smallest request the device can perform
#   w/o incurring a read-modify-write penalty (e.g. MD's chunk size)
# - optimal_io_size - the device's preferred unit of receiving I/O
#   (e.g. MD's stripe width)
# minimum_io_size is used if optimal_io_size is undefined (0).
# If md_chunk_alignment is enabled, that detects the optimal_io_size.
# This setting takes precedence over md_chunk_alignment.
# 1 enables; 0 disables.
data_alignment_detection = 1

Кроме того, нет необходимости указывать физический размер файла для vgcreate, поскольку по умолчанию уже 4 МБ.

Источник
Другие вопросы по тегам