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

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

Вопросов)

Достаточно ли установить --dataalignmentразмер блока стирания при pvcreateзагрузке и --physicalextentsizeкратный размеру блока стирания при vgcreateзагрузке?

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

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

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

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

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

Да, я также проверил все расположение дисков 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 КБ как целое устройство, размер стираемого блока каждой внутренней флэш-микросхемы / размер страницы RW, вероятно, составляет около 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 МБ.