Я хочу установить новый SSD и использовать все устройство в качестве PV для LVM - другими словами: я не планирую размещать на этом устройстве даже один раздел. Так что выравнивание разделов по стираемым блокам не требуется.
Достаточно ли установить --dataalignment к размеру блока стирания, когда pvcreateing и --physicalextentsize кратно размеру стираемого блока, когда vgcreateing?
Итак, предполагая, что мой SSD имеет размер блока стирания 1024 КБ, можно ли
pvcreate --dataalignment 1024k /dev/ssdvgcreate --physicalextentsize $(( x * 1024 ))k ...Что еще нужно принять во внимание?
Предполагая, что я поместил файловые системы ext4 на LV в этом VG, было бы неплохо выровнять ext4-экстенты по размеру LVM-PE, верно? Значит, ext4-extents должны быть того же размера, что и LVM-PE-size, или быть кратными ему?
Спасибо за любые разъяснения!
Да, я также проверил всю структуру MBR / PBR / GPT / MD / LVM на диске и пришел к такому же выводу.
В вашем случае (LVM на необработанном диске), если LVM-PE (физический размер) выровнен на 1 МБ с pvcreate, вы можете быть уверены, что все дальнейшее распределение данных будет выровнено, пока вы сохраняете размер выделения (1 МБ * N) .
Поскольку и vgcreate -s, и lvcreate -L по умолчанию обрабатывают size-without-unit как значение в МБ, вам, вероятно, не нужно особо заботиться о выравнивании после того, как вы правильно выполнили pvcreate. Только убедитесь, что размер не указан в% / PE (для lvcreate -l) и B (байт) / S (512B - сектор всегда равен 512B в LVM) / K (КБ) (для vgcreate -s и lvcreate -L).
=== добавлено для пояснения ===
В качестве последующего примера, в то время как SSD может иметь размер стираемого блока 1024 КБ в целом, размер блока стирания каждого внутреннего флеш-чипа / размер rw страницы, вероятно, составляет примерно 32–128 КБ / 512–8 КБ.
Хотя это зависит от каждого контроллера SSD, штраф ввода-вывода из-за дополнительного цикла чтения-изменения-записи, вероятно, не произойдет, если вы будете выравнивать запись для стирания размера блока каждого внутреннего чипа, который составляет 32–128 КБ, как указано выше пример. Просто вам нужно, чтобы единичный запрос на запись был достаточно большим (= размер блока стирания SSD-накопителя как целого устройства), поэтому вы можете ожидать лучшей производительности за счет эффективного управления всеми внутренними чипами / каналами.
Насколько я понимаю, выравнивание 1024 КБ является лишь мерой безопасности, поскольку функция микросхемы контроллера зависит от производителя, а спецификации микросхемы флэш-памяти быстро меняются. Более важно, чтобы запрос на запись на уровне ОС выполнялся в большом пакете (в данном случае 1024 КБ).
Теперь, сказав, что выполнение mkfs (8) на блоке LVM, выровненном по 1 МБ, почти наверняка нарушит выравнивание 1 МБ для данных / метаданных уровня файловой системы. Большинство файловых систем заботятся только о выравнивании по 4 КБ, поэтому, вероятно, это не идеально для SSD (но, IIRC, последние fs, такие как btrfs, пытаются сохранить выравнивание 64 КБ + при выделении внутреннего непрерывного блока). Но у многих fs есть функция для объединения записей (например, конфигурация с размером полосы), чтобы получить производительность от RAID, поэтому ее можно использовать для выполнения запроса записи на SSD почти оптимальным.
Я действительно хочу подкрепить свое утверждение фактическими данными, но это было действительно сложно доказать, поскольку современный контроллер SSD настолько умный и не будет демонстрировать значительного снижения производительности, если размер выравнивания и размер записи «достаточно велики». Просто убедитесь, что он не плохо выровнен (избегайте выравнивания <4 КБ любой ценой) и не слишком мал (1024 КБ достаточно).
Кроме того, если вас действительно волнует штраф за ввод-вывод, дважды проверьте, отключив кеш устройства и проведя сравнительный анализ с помощью синхронизированного теста чтения-записи-перезаписи.
Насколько я понимаю, настройки по умолчанию уже достаточно хороши. Я не думаю, что вам нужно беспокоиться о параметре --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 МБ.