SSD, Erase Block Size & LVM: PV на вихідному пристрої, Вирівнювання

Я хочу встановити новий SSD і використовувати весь пристрій як PV для LVM - іншими словами: я не планую розміщувати навіть один розділ на цьому пристрої. Тому вирівнювання розділів на блоки стирання не потрібно.

Питання (и)

Чи достатньо встановити --dataalignmentрозмір блоку стирання під час pvcreateing та --physicalextentsizeкратний розмір блоку стирання під час vgcreateing?

Таким чином, якщо припустити, що мій 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 (фізична ступінь) 1MB-узгоджена з pvcreate, ви можете бути впевнені, що всі подальші розподіли даних будуть вирівняні, якщо ви збережете розмір виділення до (1MB * N) .

Оскільки і "vgcreate -s", і "lvcreate -L" обробляють розмір без одиниці як значення MB за замовчуванням, вам, ймовірно, не потрібно дуже дбати про вирівнювання, як тільки ви зробили pvcreate належним чином. Просто переконайтеся, що не вказувати розмір у% / PE (для lvcreate -l) та B (byte) / S (512B - сектор LVM завжди 512B) / K (KB) (для vgcreate -s та lvcreate -L).

=== додано для уточнення ===

Як і наступний процес, хоча SSD може мати розмір блоку стирання 1024 КБ як цілий пристрій, розмір блоку стирання внутрішнього флеш-мікросхеми / розмір rw сторінки, ймовірно, становить приблизно 32KB-128KB / 512B-8KB.

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

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

Тепер, сказавши, що виконання mkfs (8) на LVM-блоці, орієнтованому на 1 МБ, майже напевно порушить вирівнювання на 1 МБ для даних / метаданих на рівні файлової системи. Більшість файлових систем прагне лише вирівняти 4KB, тому, мабуть, не ідеально підходить для SSD (але, IIRC, останні fs, такі як btrfs, намагається зберегти 64KB + вирівнювання при розподілі внутрішнього суміжного блоку). Але у багатьох fs є функція поєднання записів (наприклад: конфігурація розміру смуги), щоб отримати продуктивність від RAID, так що їх можна використовувати для того, щоб зробити запит запису на SSD майже оптимальним.

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

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

На моє розуміння, за замовчуванням вже досить добре. Я не думаю, що вам не потрібно турбуватися про параметр --dataaglingment, оскільки 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 МБ.