ZFS ashift: Тиха невідповідність, яка скорочує продуктивність удвічі

Проблеми з вирівнюванням — це такі речі, які роблять SRE трохи суеверними. Графіки виглядають так, ніби їх переслідують: сплески латентності, коли нічого не змінювалося, IOPS, які не масштабуються, SSD, що тестуються як HDD. Потім ви знаходите причину: ashift встановлено неправильно, і пул виконує зайву роботу на кожному записі від самого початку.

Це не стаття «почитайте man». Це польовий посібник, який хотілося б мати перед тим, як ви створювали той пул — що насправді контролює ashift, чому він «липкий», як довести, що він вам шкодить, і найменш ризикові способи повернутися до розумної продуктивності в продакшні.

Що таке ashift (і чим він не є)

ashift — це спосіб ZFS сказати: «Коли я виділяю блоки на диску, я вважатиму мінімальний розмір запису пристрою рівним 2^ashift байтів». Якщо ashift=12, ZFS виділяє в 4096-байтні сектори. Якщо ashift=9, він виділяє в 512-байтні сектори. Це одне рішення визначає, чи багато ваших записів будуть чистими одно-IO операціями — або дорогими циклами читати-модифікувати-записати, які перетворюють навантаження з випадкових записів на суп із затримок.

Ashift — це не регулювальний параметр, який можна просто змінити у вільний вівторок. Він встановлюється під час створення vdev і фактично вбудовується в те, як пул розміщує блоки. Іноді можна замінити vdev на новий з іншим ashift під час міграції/ребілду, але ви не можете «перевернути ashift» на місці і щоб існуючі блоки магічно вирівнялися. ZFS потужний; він не машина часу.

Що контролює ashift

• Мінімальний блок виділення на кожному vdev: «розмір сектора», який ZFS припускає для цього пристрою.
• Вирівнювання записів ZFS по кордонах, дружніх до пристрою.
• Ризик посилення записів для дрібних записів: неправильний ashift може змусити виконувати більше IO, ніж ви очікуєте.

Чого ashift не контролює

• Розмір блоку датасету (це recordsize для файлових систем і volblocksize для zvol).
• Стиснення, контрольні суми або математику RAIDZ parity.
• Наскільки швидкий ваш CPU — хоча помилки ashift можуть бути настільки поганими, що виглядають як проблеми CPU, бо все чекає на IO.

Ще одна важлива нюансність: ashift належить кожному vdev, а не «пулу» в абстрактному сенсі. Коли ви кажете «в моєму пулі ashift=12», найчастіше ви маєте на увазі «усі vdev у пулі мають ashift=12». Можливі змішані vdev з різними ashift, і це рідко веселе свято.

Перший жарт (коротко): Хороше в ashift те, що це одноразове рішення. Погане в ashift те, що це одноразове рішення.

Чому неправильний ashift так шкодить

Крутий спад продуктивності походить від того, як пристрої фактично записують дані. Багато дисків і SSD показують 512-байтні логічні сектори для сумісності, але їх внутрішня «фізична» одиниця запису — 4K (або більше). Якщо ZFS вважає, що може записувати шматки по 512B (ashift=9) на пристрій, який насправді хоче 4K-записи, пристрій може виконати цикл читати-модифікувати-записати (RMW):

1. Прочитати весь 4K фізичний блок в кеш пристрою
2. Змінити 512B частину, яка змінилася
3. Записати назад увесь 4K блок

Це три операції там, де ви очікували одну. І оскільки ці операції послідовні всередині пристрою, хвости латентності стають огидними, навіть якщо середнє виглядає «нормально». У реальних системах не рідкість бачити падіння пропускної здатності приблизно вдвічі або гірше при дрібних випадкових записах, плюс драматичне збільшення p99 латентності.

Чому «удвічі продуктивність» — не перебільшення

Коли ashift занадто малий, ZFS видає дрібніші записи. Пристрої, що не можуть нативно записувати такі розміри, платять податок RMW. Якщо ваше навантаження:

• сильно залежить від sync (бази даних, NFS з sync, віртуалізація з write barriers),
• має дрібні блоки і випадкові записи (метадані VM, WAL/redo логи БД, журналювання),
• або RAIDZ зверху неправильного вирівнювання (паритет + RMW — це особливий вид болю),

то цей податок проявляється як черга, потім як латентність, потім як «чому наш сервіс почав таймаутити».

Ashift занадто великий: тихий компроміс

Існує і зворотна помилка: вибрати більший ashift, ніж потрібно, наприклад ashift=13 (8K) на справжньому 4K-пристрої. Це зазвичай не вбиває продуктивність; це «лише» збільшує просторові накладні витрати і може зменшити ефективність для дуже маленьких блоків. Операційно це зазвичай безпечніший напрямок: марна витрата простору дратує, але непередбачувана латентність — це те, що викликає pager.

Другий жарт: Якщо ви неправильно встановите ashift, ZFS не розлютиться — він просто стане повільним. Це як найпасивніша агресивна файлова система.

Факти та історичний контекст, які варто знати

Це не дрібні факти для цікавості. Вони пояснюють, чому ashift досі є пасткою у 2025 році.

1. 512-байтні сектори домінували десятиліттями, бо ранні контролери, файлові системи і прошивки стандартизувалися навколо них. Інерція сумісності реальна.
2. «Advanced Format» (4K) диски стали масовими, щоб зменшити накладні витрати і підвищити ефективність ємності; багато з них все ще емулюють 512-байтні логічні сектори для ОС.
3. Деякі пристрої брешуть — навмисно. Вони повідомляють 512 логічних секторів навіть коли їх внутрішній розмір програм/стирання 4K або більше, оскільки деякі ОС і завантажувачі історично очікували 512.
4. ZFS спроектовано для цілісності даних насамперед; аллокатор і модель транзакцій припускають, що вирівнювання важливе, але вони не завжди можуть довіряти звітам диска.
5. Ashift став «липким» за дизайном. Дозволити зміну розміру сектора під живим пулом ризикувало б порушити припущення про розміщення на диску.
6. SSD внесли нові «фізичні реалії»: NAND-сторінки та блоки стирання не мапляться акуратно на 512 або 4K, але вирівнювання по 4K все ще є гарною базою для уникнення write amplification.
7. RAIDZ робить вирівнювання більш чутливим. Обчислення паритету та ширина смуги взаємодіють з межами секторів; невідповідність може множити біль.
8. Віртуалізація додала ще один шар оманливості: віртуальний диск може звітувати 512 секторів, тоді як бекенд-збереження — 4K-native; ashift має відповідати реальному нижньому шару.
9. На ранніх стадіях прийняття OpenZFS на Linux, багато адміністраторів мігрували з ext4/mdadm звичок і трактували ZFS як «ще один рівень RAID», пропускаючи ashift зовсім.

Три міні-історії з корпоративного світу

Міні-історія №1: Інцидент від неправильної припущення

Все почалося як планове оновлення платформи: нові хости гіпервізора, «enterprise SSD» і новий ZFS-пул для зберігання VM. Команда зробила те, що роблять команди під тиском часу: скопіювала команду zpool create з вики-процедури, запустила її, спостерігала, як пул піднявся, і рушила далі. Ніхто не подивився на ashift, бо «SSD швидкі».

Через два тижні кількість тікетів різко зросла: періодичні уповільнення клієнтського API. Графіки були заплутаними. CPU в нормі. Мережа в нормі. Ноди баз даних виглядали байдуже. Але платформа VM показувала сплески латентності збереження — короткі, але достатньо тривалі, щоб запускати таймаути.

Перший на чергуванні подумав, що це «шумні сусіди». Другий підозрював бракований SSD. Третій зробив неефектну річ: порівняв властивості ZFS нового кластера зі старим. І там все прояснилося: у старого пулу було ashift=12. У нового — ashift=9.

Диски вказували 512 логічних секторів, тож ZFS «допоміг» і вибрав 512-байтне вирівнювання. Під випадковим записом VM ті «enterprise SSD» робили внутрішні RMW-цикли. Інцидент не був одиничним катастрофічним збоєм; це була повільна смерть через хвости латентності. Виправлення не було швидким: вони не могли змінити ashift на місці. Побудували новий пул з ashift=12, перемістили VМ в лайв, а решту — холодною міграцією, і це стало уроком: довіряй, але перевіряй звіти апаратури.

Що змінилося після? У їхньому чек-листі з’явився новий пункт: «Записувати ashift для кожного vdev перед розміщенням даних». Це було нудно. Це також припинило повторення цього класу інцидентів.

Міні-історія №2: Оптимізація, що обернулася проти

Інша організація мала проблему продуктивності і зробила те, що роблять ті, хто ганяється за продуктивністю: оптимізували. Вони читали, що більші сектори можуть бути корисні, тож вирішили стандартизувати ashift=13 (8K) «щоб відповідати внутрішній структурі сучасних SSD». Перебудували пул, пишалися, і запустили його в продакшн для змішаного навантаження: дрібні конфігураційні файли, шари контейнерів і чатливий CI з масою метаданих.

Початкові бенчмарки виглядали добре — бо їхній тест був переважно послідовний. Потім CI система почала «завалюватися». Претензія була не в сирій швидкості; це була ампліфікація: багато дрібних файлів і маленьких записів означали, що ZFS виділяв мінімальні блоки по 8K. Використання простору росло швидше, ніж очікували, снапшоти розросталися, і пул швидше діставався тривожних порогів ємності, ніж старий.

Тепер цікаве: тиск на ємність змінює поведінку. Вільне місце зменшується, metaslabs фрагментуються, виділення стає дорожчим, і система, що «бенчмаркувалася краще», почала виглядати гірше під реальним навантаженням. Їхня оптимізація не спричинила проблеми коректності, але перетворила проект з продуктивності на проект управління ємністю. Ось як ви опиняєтеся на зустрічах з фінансами — а це ніколи не покращує латентність.

Вони не викинули ashift=13 повністю. Вони навчилися застосовувати його цілеспрямовано: для датасетів з великими блоками, певних цілей бекапу та специфічних типів vdev, де компроміс був прийнятний. Для загальних пулів вони повернулися до нудного базового варіанту: ashift=12 для 4K-класових пристроїв.

Міні-історія №3: Нудна, але правильна практика, що врятувала день

Одна команда зберігання мала звичку, яка здавалася параноєю: щоразу при підключенні нових дисків вони запускали невеликий «скрипт перевірки істини» перед створенням пулу. Він збирав lsblk розміри секторів, опитував топологію HBA і зберігав підсумки smartctl у тікеті. Він також примусово використовував ashift=12, якщо не було сильної причини інакше.

Одного дня закупівля замінила модель дисків через ланцюжок постачання. Та сама марка, та сама ємність, ті самі маркетингові заяви. Але заміна поводилася інакше: вона показувала 512 логічних секторів і «допомагала» маскувати 4K-фізичну поведінку. ОС виглядала задоволеною в обох випадках.

Перевірка істини виявила невідповідність у порівнянні з попередніми партіями. Команда не панікувала; вони просто зробили те, що сказано в чек-листі: створили маленький тестовий пул, підтвердили вибір ashift і прогнали бенчмарк випадкових синхронних записів. Цифри були «неправильні» у спосіб, що пахне невирівнюванням.

Вони заставили ashift=12 під час створення пулу, повторили тести, і продуктивність миттєво стала на свої місця. Жодного інциденту. Жодного впливу на клієнтів. Просто тихе зміна з прикріпленим доказом. Це та «нудна» річ, що робить системи надійними.

Практичні завдання: команди + інтерпретація (12+)

Усі завдання нижче передбачають OpenZFS на Linux, якщо не зазначено інше, але більшість команд застосовні подібно на illumos/FreeBSD з невеликими відмінностями шляхів. Використовуйте їх як набір інструментів: перевірте ashift, виявите симптоми невирівнювання і сплануйте виправлення.

Завдання 1: Переглянути значення ashift для vdev (джерело істини)

cr0x@server:~$ sudo zdb -C tank | sed -n '/vdev_tree/{:a;n;/}/q;p;ba}'

Інтерпретація: Шукайте записи ashift під кожним leaf vdev. Якщо ви бачите ashift: 9 на сучасному SSD/HDD класу 4K, ймовірно, у вас проблема. Якщо деякі vdev показують 12, а інші 9, у вас є непослідовність, яка може ускладнити очікування щодо продуктивності і майбутні розширення.

Завдання 2: Швидка перевірка ashift одним рядком (leaf vdev)

cr0x@server:~$ sudo zdb -C tank | awk '/path:|ashift:/{printf "%s ",$0} /ashift:/{print ""}'

Інтерпретація: Це друкує шляхи пристроїв поруч з ashift. Корисно під час інциденту, коли потрібно швидко отримати відповіді, а не красиво їх відобразити.

Завдання 3: Перевірити, що ОС думає про розміри секторів

cr0x@server:~$ lsblk -o NAME,MODEL,SIZE,PHY-SeC,LOG-SeC,ROTA,TYPE
NAME   MODEL               SIZE PHY-SEC LOG-SEC ROTA TYPE
sda    INTEL SSDPE2KX040T 3.7T    4096     512    0 disk
sdb    INTEL SSDPE2KX040T 3.7T    4096     512    0 disk

Інтерпретація: Якщо PHY-SEC 4096, а LOG-SEC 512 (512e), пристрій є класичною пасткою ashift. ZFS може вибрати 9, якщо довіриться логічному розміру сектора. Зазвичай тут ви хочете ashift=12.

Завдання 4: Підтвердити логічні/фізичні блоки через sysfs (Linux)

cr0x@server:~$ for d in /sys/block/sd*/queue; do \
  dev=$(basename "$(dirname "$d")"); \
  printf "%s logical=%s physical=%s\n" \
    "$dev" \
    "$(cat "$d/logical_block_size")" \
    "$(cat "$d/physical_block_size")"; \
done | head
sda logical=512 physical=4096
sdb logical=512 physical=4096

Інтерпретація: Та сама історія, що й lsblk, але скриптується і надійно. Фіксуйте це в логах збірки; це прискорює майбутні розслідування.

Завдання 5: Підтвердити топологію пула і виявити змішані типи vdev

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
config:

        NAME          STATE     READ WRITE CKSUM
        tank          ONLINE       0     0     0
          raidz2-0    ONLINE       0     0     0
            sda       ONLINE       0     0     0
            sdb       ONLINE       0     0     0
            sdc       ONLINE       0     0     0
            sdd       ONLINE       0     0     0
            sde       ONLINE       0     0     0
            sdf       ONLINE       0     0     0

Інтерпретація: Це не показує ashift, але показує форму пулу. RAIDZ + помилки ashift зазвичай проявляються як «чому маленькі записи мають жахливу латентність». Дзеркальні vdev більш поблажливі, але все одно страждають при неправильному ashift на SSD.

Завдання 6: Перевірити властивості датасету, що взаємодіють із симптомами ashift

cr0x@server:~$ zfs get -o name,property,value -s local,default recordsize,compression,atime,sync tank/vmstore
NAME         PROPERTY     VALUE
tank/vmstore recordsize   128K
tank/vmstore compression  zstd
tank/vmstore atime        off
tank/vmstore sync         standard

Інтерпретація: Проблеми ashift найпомітніші при дрібних синхронних записах. Якщо ви тримаєте образи VM у файловому датасеті, recordsize може не бути основною причиною, але воно впливає на форму IO. Для zvol перевіряйте volblocksize замість цього.

Завдання 7: Для сховища на базі zvol перевірити volblocksize (і прийняти біль)

cr0x@server:~$ zfs get -o name,property,value volblocksize,compression,sync tank/zvol0
NAME        PROPERTY     VALUE
tank/zvol0  volblocksize 8K
tank/zvol0  compression  zstd
tank/zvol0  sync         standard

Інтерпретація: Якщо volblocksize менший, ніж ефективний мінімальний розмір запису пристрою, неправильний ashift посилює проблему. Ви хочете чистого вирівнювання на всіх шарах.

Завдання 8: Спостерігати IO і латентність в реальному часі (на рівні ZFS)

cr0x@server:~$ sudo zpool iostat -v tank 1 5
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        2.10T  1.50T    250    900  12.0M  85.0M
  raidz2-0  2.10T  1.50T    250    900  12.0M  85.0M
    sda         -      -     40    150  2.0M  14.0M
    sdb         -      -     38    145  1.9M  13.8M
    ...

Інтерпретація: Якщо операцій запису багато, а пропускна здатність помірна, ймовірно, ви в області дрібних IO. Там неправильний ashift може перетворити прийнятне навантаження на шліфувальник латентності.

Завдання 9: Спостерігати IO і латентність в реальному часі (на рівні пристрою)

cr0x@server:~$ iostat -x 1 5
Device            r/s     w/s   r_await   w_await  aqu-sz  %util
sda              55.0   220.0     0.70    18.50     3.10  98.0
sdb              52.0   215.0     0.65    19.10     3.05  97.5

Інтерпретація: Високий w_await при майже 100% завантаженні SSD при помірній пропускній здатності — класичний запах. Це не доводить, що ashift неправильний, але каже, що біль під ZFS, а не в додатку.

Завдання 10: Виміряти поведінку синхронних записів (навантаження, що виявляє невирівнювання)

cr0x@server:~$ sudo fio --name=sync4k --directory=/tank/test \
  --rw=randwrite --bs=4k --iodepth=16 --numjobs=4 --size=2G \
  --fsync=1 --direct=1 --time_based --runtime=30 --group_reporting
sync4k: (groupid=0, jobs=4): err= 0: pid=1234: Fri Dec  1 12:00:00 2025
  write: IOPS=4200, BW=16.4MiB/s (17.2MB/s), lat (usec): min=180, avg=3100, max=55000

Інтерпретація: Якщо ви очікували значно вищих IOPS від SSD і бачите середню латентність у мілісекундах, у вас проблема стеку зберігання. Неправильний ashift — часта корінна причина, особливо якщо ті ж диски виявляють хороші результати поза ZFS.

Завдання 11: Порівняти з більшими блоками, щоб відокремити «податок за дрібні записи» від загальної повільності

cr0x@server:~$ sudo fio --name=write128k --directory=/tank/test \
  --rw=write --bs=128k --iodepth=32 --numjobs=1 --size=8G \
  --direct=1 --time_based --runtime=30 --group_reporting
write128k: (groupid=0, jobs=1): err= 0: pid=1301: Fri Dec  1 12:01:00 2025
  write: IOPS=2400, BW=300MiB/s (315MB/s), lat (usec): min=250, avg=400, max=8000

Інтерпретація: Якщо великі послідовні записи виглядають пристойно, але 4K синхронні записи жахливі, підозрюйте вирівнювання і write amplification скоріше, ніж «пул просто повільний».

Завдання 12: Перевірити поведінку sync у ZFS і чи ваше навантаження її змушує

cr0x@server:~$ zfs get -o name,property,value sync tank
NAME  PROPERTY  VALUE
tank  sync      standard

Інтерпретація: Багато продакшн-навантажень залежать від sync семантики для коректності. Вимикати sync, щоб «покращити продуктивність», — це купити швидкість за ризик втрати даних. Якщо ashift неправильний, sync=disabled може приховати проблему до наступного інциденту.

Завдання 13: Перевірити, чи є у вас спеціальні vdev і підтвердити їх ashift теж

cr0x@server:~$ zpool status tank | sed -n '/special/,$p'
        special
          mirror-1
            nvme0n1p2
            nvme1n1p2

cr0x@server:~$ sudo zdb -C tank | awk '/special|path:|ashift:/{print}'

Інтерпретація: Спеціальні vdev зберігають метадані (і опціонально невеликі блоки). Якщо їх ashift відрізняється або неправильний для NVMe, ви можете створити гарячу точку втрати продуктивності метаданих, яка виглядає як «ZFS повільний», але насправді це «метадані IO невирівняні і сумні».

Завдання 14: Підтвердити, який ashift ZFS обере, перш ніж створювати (тестовий пул)

cr0x@server:~$ sudo zpool create -o ashift=12 testpool mirror /dev/sdg /dev/sdh
cr0x@server:~$ sudo zdb -C testpool | awk '/path:|ashift:/{print}'
            path: '/dev/sdg'
            ashift: 12
            path: '/dev/sdh'
            ashift: 12
cr0x@server:~$ sudo zpool destroy testpool

Інтерпретація: Це найбезпечніший момент, щоб «виправити ashift»: до появи даних. Створіть крихітний тест-пул, підтвердьте ashift у конфігурації, потім знищіть його. Це дешева страховка.

Завдання 15: Доведіть собі, що ashift фіксується лише шляхом перебудови/міграції

cr0x@server:~$ sudo zpool get ashift tank
NAME  PROPERTY  VALUE  SOURCE
tank  ashift    -      -

Інтерпретація: Багато людей очікують властивість на рівні пулу. Цей вивід — саме те: ashift не проста властивість пулу, яку можна перемкнути. Ви повинні інспектувати конфігурацію vdev.

Швидкий план діагностики

Це версія «ви на чергуванні і база даних таймаутить». Мета — швидко відокремити misalignment ashift від інших десятка шляхів, якими зберігання може зіпсувати день.

Крок 1: Підтвердити, що це латентність зберігання, а не CPU або мережа

• Перевірте симптоми на стороні додатка: таймаути, затримки fsync, сплески VM «IO wait».
• На Linux дивіться на IO wait і ріст черги виконання.

cr0x@server:~$ uptime
 12:03:22 up 10 days,  4:11,  2 users,  load average: 8.20, 7.10, 6.80
cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  7      0 123456  7890 987654    0    0   120  9800  500  900 10  8 40 42  0

Інтерпретація: Високий wa (IO wait) плюс заблоковані процеси (b) — сильний натяк: ядро чекає на зберігання.

Крок 2: Визначити, чи біль пов’язаний з дрібними записами і синхронністю

cr0x@server:~$ sudo zpool iostat -v tank 1 3

Інтерпретація: Багато операцій запису при відносно низькій пропускній здатності вказує на дрібні записи. Саме там невирівнювання проявляється перш за все.

Крок 3: Перевірити латентність пристроїв і завантаження

cr0x@server:~$ iostat -x 1 3

Інтерпретація: Якщо SSD показують високу завантаженість і високе w_await при помірній пропускній здатності, підозрюйте write amplification під ZFS.

Крок 4: Перевірити ashift на vdev (не здогадуйтеся)

cr0x@server:~$ sudo zdb -C tank | awk '/path:|ashift:/{print}'

Інтерпретація: Якщо ви бачите ashift: 9 на 4K-класових пристроях, ви знайшли головного підозрюваного.

Крок 5: Корелюйте зі звітами розміру секторів

cr0x@server:~$ lsblk -o NAME,PHY-SeC,LOG-SeC,MODEL /dev/sda

Інтерпретація: Якщо physical 4096 і logical 512, а ashift 9 — ваш стек невирівняний за замовчуванням.

Крок 6: Вирішіть: пом’якшити зараз чи виправити правильно

• Пом’якшення: зменшити sync-навантаження (обережно), перемістити write-важливі датасети, додати SLOG якщо це підходить, знизити тиск фрагментації.
• Правильне виправлення: перебудова/міграція на пул з правильним ashift.

Інтерпретація: Якщо це продакшн і дані важливі, правильне виправлення майже завжди «побудувати новий пул і мігрувати». Решта — це триаж.

Поширені помилки: симптоми та виправлення

Помилка 1: Довіра до логічного розміру сектора, який повідомляє диск

Симптом: Новий пул на «сучасних» дисках працює дивно при 4K випадкових записах; SSD показують високу завантаженість при низькій пропускній здатності.

Чому це відбувається: Пристрої 512e повідомляють 512 логічних секторів для сумісності; ZFS може вибрати ashift=9, якщо ви не примусите 12.

Виправлення: Для більшості сучасних пристроїв явно використовуйте -o ashift=12 при zpool create і перевіряйте через zdb -C. Якщо пул вже створено і він неправильний, плануйте перебудову/міграцію.

Помилка 2: Припущення, що ashift можна змінити пізніше

Симптом: Хтось намагається zpool set ashift=12 tank і або команда не працює, або нічого не змінюється; продуктивність лишається поганою.

Чому це відбувається: Ashift вбудований у конфігурацію vdev і в поведінку розміщення на диску.

Виправлення: Створіть новий пул з правильним ashift і перемістіть дані. Для деяких топологій можна замінювати пристрої/vdev по черзі (дзеркала більш дружні, ніж RAIDZ), але це все одно фактично ребілд.

Помилка 3: Перекручування через занадто великий ashift скрізь

Симптом: Продуктивність здається нормальною, але використання простору несподівано високе; снапшоти ростуть швидше; пул раніше досягає тривожних порогів.

Чому це відбувається: Більший ashift збільшує мінімальний розмір алокації.

Виправлення: Використовуйте ashift=12 як базовий стандарт; розглядайте вищі значення лише для конкретних пристроїв/навантажень, де ви виміряли вигоди і прийняли накладні витрати.

Помилка 4: «Виправлення» продуктивності вимиканням sync

Симптом: Латентність миттєво покращується, керівництво оголошує перемогу, а потім подія живлення або паніка ядра призводять до неприємностей.

Чому це відбувається: Синхронні записи дорогі; вимкнення sync жертвує коректністю заради швидкості.

Виправлення: Тримайте sync=standard, якщо ви не можете формально прийняти ризик втрати даних. Якщо sync-навантаження важке, розгляньте виділення SLOG, налаштування навантаження або виправлення базового misalignment ashift.

Помилка 5: Змішування vdev з різним ashift або класами пристроїв

Симптом: Продуктивність пулу змінюється непередбачувано; розширення змінюють профілі латентності; деякі датасети стають «випадково» повільніші.

Чому це відбувається: ZFS рівномірно розподіляє алокації по vdev; повільні або невирівняні vdev можуть домінувати у хвостовій латентності.

Виправлення: Тримайте vdev однорідними за продуктивністю і припущеннями ashift коли можливо. Якщо необхідно змішувати, ізолюйте навантаження в окремі пули.

Контрольні списки / покроковий план

Контрольний список A: Створення нового пулу (зробіть правильно з першого разу)

1. Перелік пристроїв і фіксація фізичних/логічних розмірів блоків.
2. Визначте базовий ashift (зазвичай 12 для сучасних HDD/SSD).
3. Створіть тимчасовий тестовий пул, підтвердіть ashift через zdb -C, знищіть його.
4. Створіть реальний пул з явним ashift.
5. Перевірте продуктивність дрібних випадкових записів і синхронної поведінки до наповнення продакшн-даними.

cr0x@server:~$ lsblk -o NAME,MODEL,PHY-SeC,LOG-SeC,ROTA,SIZE
cr0x@server:~$ sudo zpool create -o ashift=12 tank raidz2 /dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf
cr0x@server:~$ sudo zdb -C tank | awk '/path:|ashift:/{print}'
cr0x@server:~$ zpool status tank

Інтерпретація: Важлива не команда; важлива перевірка. Якщо ви не перевірите ashift негайно, перевірите його пізніше лише тоді, коли буде боляче.

Контрольний список B: Міграція з неправильного ashift пулу з мінімальною драмою

1. Побудуйте новий пул з правильним ashift, бажано на новому обладнанні або нових розділених пристроях.
2. Реплікуйте датасети за допомогою ZFS send/receive, щоб зберегти снапшоти та властивості.
3. Перемкніть клієнтів у контрольованому вікні обслуговування (або поетапно, якщо середовище дозволяє).
4. Тримайте старий пул в режимі лише читання для короткого вікна відкату, якщо можна дозволити.

cr0x@server:~$ sudo zpool create -o ashift=12 tank2 mirror /dev/sdg /dev/sdh
cr0x@server:~$ sudo zfs snapshot -r tank@pre-migrate
cr0x@server:~$ sudo zfs send -R tank@pre-migrate | sudo zfs receive -F tank2
cr0x@server:~$ zfs list -r tank2

Інтерпретація: Це «чисте» виправлення: перемістіть дані в правильно вирівняний пул. Операційно це пряма дія, тестована і відкатна, якщо ви тримаєте джерело деякий час.

Контрольний список C: Якщо ви застрягли з неправильним ashift поки що (триаж, не лікування)

1. Визначте найгірші навантаження: датасети або zvol, що роблять багато синхронних дрібних записів.
2. Перемістіть ці навантаження першими (навіть на маленький правильно вирівняний пул), щоб зменшити хвостову латентність.
3. Переконайтеся, що ви не на високому заповненні пула; тиск ємності погіршує все.
4. Виміряйте до/після з тим самим fio завданням, тим самим вікном часу і з захопленим zpool iostat.

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint -r tank
cr0x@server:~$ zpool list -o name,size,alloc,free,capacity,health tank
cr0x@server:~$ sudo fio --name=triage --directory=/tank/test --rw=randwrite --bs=4k --fsync=1 --iodepth=8 --numjobs=2 --size=1G --runtime=20 --time_based --direct=1 --group_reporting

Інтерпретація: Якщо ви не можете перебудувати негайно, ізолюйте найдочутливіші до латентності навантаження і зменшіть їхній контакт з невирівняним пулом. Але ставте це як тимчасовий план утримання.

Поширені питання

1) Який ashift слід використовувати для сучасних дисків?

Для більшості сучасних HDD і SSD ashift=12 — розумний стандарт. Він вирівнює алокації по 4K і уникати найгірших штрафів невирівнювання на пристроях 512e.

2) Коли ashift=9 буде правильним?

Рідко, лише на по-справжньому 512-native пристроях, де у вас є сильні докази, що 512B записи дійсно ефективні наскрізь. На практиці більшість адміністраторів обирають 12, щоб не бути ошуканими звітами сумісності.

3) Чи можна змінити ashift після створення пулу?

Не на місці для існуючих vdev/даних. Ви можете мігрувати, побудувавши новий пул і перемістивши дані, або в деяких конфігураціях замінити пристрої/vdev як частину стратегії ребілду. Але немає «перемикача», який би пере-вирівняв існуючі блоки.

4) Як перевірити ashift на живому пулі?

Використайте zdb -C <pool> і шукайте ashift під кожним leaf vdev. Немає простого zpool get, яке надійно відобразить це як одне значення.

5) Якщо я встановлю ashift=12 на 512-native пристрої, чи це щось поламає?

Це не порушить коректність, але може витрачати простір і трохи зменшити ефективність для крихітних блоків. Зазвичай операційна безпека уникнення невирівнювання переважує витрати простору.

6) Чому неправильний ashift частіше помітний при віртуалізації і в базах даних?

Тому що ці навантаження генерують багато дрібних випадкових записів і часто вимагають sync семантики. Комбінація підсилює штрафи RMW і хвостову латентність.

7) Чи має значення recordsize/volblocksize, якщо ashift правильний?

Так. Ashift запобігає найгіршим патологіям вирівнювання на межі пристрою, але розмір блоків вашого навантаження все ще визначає шаблони IO, ампліфікацію і поведінку кешу. Думайте про ashift як «не наступати на граблі», а про recordsize як «йти ефективно».

8) У мене є спеціальний vdev (метадані) на NVMe. Чи треба піклуватися про ashift там теж?

Безумовно. Спеціальні vdev можуть стати вузьким місцем латентності для навантажень, що сильно працюють з метаданими. Якщо вони невирівняні або невідповідні, вони можуть звузити весь пул у способи, які не виглядять як «повільний диск», а скоріше як «усе дуже ривкаве».

9) Чи ashift — єдина причина, чому ZFS може бути повільним?

Ні. Фрагментація, надмірне заповнення пулу, поганий SLOG, особливості контролера, SMR-диски, проблеми з глибиною черги і невідповідність навантаження можуть усе псувати. Причина, через яку ashift отримує особливу увагу, полягає в тому, що він може тихо паралізувати продуктивність з першого дня і не фіксується простим перемиканням властивості.

10) Який найбезпечніший операційний підхід?

Стандартизувати: інвентаризуйте розміри секторів, за замовчуванням використовуйте ashift=12, перевіряйте негайно після створення пулу і зберігайте докази. Ставте ashift як рішення про архітектуру, а не як параметр налаштування.

Висновок

Ashift — це одна з тих дрібниць, що здається занадто неважливою, поки не стане важливішою за модель вашого CPU, вашу мережу і половину вашої оптимізаційної роботи разом узятих. Тиха природа проблеми — її небезпека: неправильний ashift не падає голосно. Він просто зливає продуктивність на підлогу і перетворює передбачувані навантаження на лотерею латентності.

Продакшн-мислення просте: не довіряйте маркетингу пристроїв, не довіряйте автодетекції за замовчуванням і не відправляйте пул у роботу, не допитавши його через zdb -C. Якщо у вас вже є пул з неправильним ashift, не витрачайте тижні на полірування симптомів. Побудуйте правильно вирівняний пул і мігруйте за планом. Pager скаже вам «дякую», навіть якщо ніколи цього не скаже вголос.