ZFS: коли додавати спеціальний vdev (і коли це погана ідея)

Що таке спеціальний vdev насправді (і чого він не є)

У ZFS спеціальний vdev — це виділений клас vdev, куди ZFS може зберігати метадані (і опційно малі блоки даних)
на швидших пристроях — зазвичай SSD або NVMe — тоді як основні дані пулу залишаються на повільніших, ємнісних дисках.
Думаємо: каталоги, непрямі блоки, dnode-об’єкти, покажчики блоків, карти вільного простору, частина метаданих алокації і (залежно від налаштувань) малі файли.

Мета — не магічна пропускна здатність. Це латентність і IOPS там, де ZFS їх найпотрібніше:
навантаження, важкі на метадані, багато снапшотів, безліч дрібних файлів, інтенсивне обходження файлової системи та сховище ВМ з дрібними випадковими IO.

Чого це не є

• Це не L2ARC. L2ARC — кеш читання, його можна скинути у будь-який момент без втрати пулу. Спеціальний vdev містить авторитарні блоки.
• Це не SLOG. SLOG — це журнал намірів синхронного запису (ZIL). Він пришвидшує sync-записи, але не зберігає звичайні метадані назавжди.
• Це не «кнопка безкоштовного прискорення». Ви переміщаєте критичні структури на клас пристроїв, які повинні бути надійними та надлишковими.

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

Короткий жарт: спеціальний vdev — це як дати ZFS еспресо — класно, поки не зрозумієш, що в кафе лише однин вільтрум.

Цікаві факти та історичний контекст

• ZFS з’явився в середині 2000-х у Sun Microsystems із безкомпромісним фокусом на цілісності від краю до краю: контрольні суми, copy-on-write, самовідновлення.
  Така архітектура робить коректність метаданих першочерговою — отже продуктивність метаданих має значення.
• Спеціальні vdev з’явилися пізніше (не в найперших релізах ZFS) як відповідь на передбачувану сучасну проблему:
  обертові диски стали величезними, але їхні випадкові IOPS — ні.
• Ідея «тільки метадані на SSD» існувала раніше за спеціальний vdev у ZFS; файлові системи й стек зберігання давно відокремлювали гарячі шляхи метаданих
  від холодних масивів. ZFS просто зробив це адміністративно зручним.
• Опція «малі блоки» змінила ставки. Як тільки ви дозволяєте малі блоки даних на спеціальному vdev,
  ви рухаєте не лише прискорення обходів каталогів — ви переносите реальні користувацькі дані на ці пристрої.
• Dnode-структури стали більш налаштовуваними. Функції на кшталт більших dnode покращили ефективність метаданих (особливо для розширених атрибутів, ACL і малих файлів),
  але також підвищили важливість того, де живуть dnode’и — спеціальний vdev тут може дуже допомогти.
• Операції зі снапшотами — це операції, що навантажують метадані. Клони, перелік снапшотів, перерахування датасетів і планування send/receive ударяють по метаданих і непрямим блокам
  у шаблонах, які люблять низьку латентність.
• NVMe змінило не лише швидкість; воно змінило режими відмов. Швидкі пристрої часто менш поблажливі: прошивки з багами, теплове тротлінгування, неочікувані відключення живлення
  і миттєва смерть без «поступового деградування», яке дають HDD SMART-попередження.
• Підприємницькі масиви роблять те саме тихо, застосовуючи тірінг і кешування метаданих. Спеціальний vdev — це DIY-версія з DIY-наслідками.

Операційна цитата (перефразовано): «Надія — це не стратегія.» — часто приписують інженерам культури надійності; суть ясна:
проєктуйте спеціальний vdev так, ніби він може відмовити.

Коли спеціальний vdev — правильний крок

1) Ваше навантаження обмежене метаданими, а не пропускною здатністю

Якщо ваш пул реалізує чимало МБ/с, але «припиняється» на операціях — перелік каталогів, створення файлів, хвилі chmod/chown, управління снапшотами —
часто ви обмежені випадковими читаннями/записами метаданих. HDD у цьому слабкі. Не «трохи гірші». На порядок гірші.

Спеціальний vdev допомагає, бо ZFS більше не мусить читати метадані з найповільнішого рівня. Він може тримати метадані на низьколатентних пристроях
і зменшити кількість випадкових seek’ів на обертових дисках. Ви все ще маєте HDD для послідовного великого читання й запису — і це їхня сила.

2) У вас багато дрібних файлів (або малих блоків) і ви можете контролювати, що переміщується

За допомогою властивості special_small_blocks ZFS може розміщувати дані блоки, менші за поріг, на спеціальному vdev.
Це може трансформувати продуктивність для:

• образів ВМ з дрібними випадковими IO (особливо з малим volblocksize)
• дерев джерельних кодів, репозиторіїв пакетів, шарів контейнерів
• робочих навантажень типу Maildir
• NFS/SMB-шерів, багатих на метадані й малі файли

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

3) Снапшоти, клони й перелік датасетів повільні

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

4) Вам потрібна швидша латентність більше, ніж швидша пропускна здатність

У продакшені користувачі не скаржаться, що пул читає 1.5 GB/s у бенчмарку. Вони скаржаться, що «відкриття папки займає 10 секунд».
Спеціальний vdev для такого сорому.

5) Ви можете дозволити собі надлишковість і операційну увагу

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

Коли це погана ідея (і як це ламається)

Ви думаєте, що «спробувати і потім видалити» — легко

Видалення спеціальних vdev історично було обмеженим і операційно складним. Навіть там, де видалення пристрою реалізовано, це не завжди
можливо, не завжди швидко і не завжди так, як хочеться під тиском. Плануйте так, ніби це постійно.

Ви не можете його дзеркалити

Один пристрій у спеціальному vdev — це загроза для всього пулу. Якщо він містить метадані, пул залежить від нього. Втратьте його — і можете втратити пул.
Якщо він містить і малі блоки, ви справді граєтеся в живу зброю.

Ви лікуєте не те вузьке місце

Якщо ваша реальна проблема:

• синхронні записи без належного SLOG
• недостатньо RAM / ARC трешинґ
• непідходящий recordsize/volblocksize для навантаження
• перегружений CPU через контрольні суми/компресію
• мережеві проблеми на NFS/SMB

…спеціальний vdev вас не врятує. Він навіть може приховати проблему досить довго, щоб зробити її ще гіршою пізніше.

Ви використовуєте ненадійні SSD/NVMe або ненадійний шлях живлення

Пристрої спеціального vdev отримують значні навантаження дрібними випадковими IO. Вони також стають критичними для цілісності пулу.
Побутові SSD з слабким захистом від втрати живлення і оптимістичною прошивкою — це не варіант.

Ваш пул вже майже заповнений

Заповнення спеціального vdev — не м’який провал. Якщо він заповнюється, алокації метаданих можуть провалюватися цікавими способами в сенсі інцидентів.
Якщо ви вже тримаєте основний пул на 85–90% і сподіваєтеся на найкраще, вам не час для емоцій, щоб додавати спеціальний vdev.

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

Правила проєктування: надлишковість, розмір і розташування

Правило 1: Дзеркаліть спеціальний vdev (мінімум)

Ставтеся до спеціального vdev як до «частини хребта пулу». Дзеркаліть його. Якщо хочете бути ще обережнішими — використайте 3-way mirror,
особливо для критичних пулів із жорсткими метаданими навантаженнями.

RAIDZ для спеціального vdev можливий, але дзеркальні спеціальні vdev найпоширеніший вибір, бо дають потужні випадкові читання
і простішу поведінку при відмовах. Ви хочете IOPS і передбачуваність.

Правило 2: Розмірюйте на майбутнє, а не на демо

Недорозмірювання — класична невдача. Метадані ростуть з кількістю файлів, снапшотами, клонуваннями і фрагментацією — не лише з сирим обсягом даних.
Якщо ви вмикаєте малі блоки, зростання прискорюється й залежить від навантаження.

Практичні поради щодо розмірювання (суб’єктивно, бо ви попросили):

• Тільки метадані: починайте думати в низькопроцентних відсотках від логічного розміру пулу, але перевіряйте реальними числами.
  Якщо у вас «мільйони дрібних файлів і багато снапшотів», плануйте більше.
• Метадані + малі блоки: розглядайте це як реальний шар, а не кеш. Якщо ви ставите special_small_blocks > 0,
  припускайте, що дані користувача будуть туди потрапляти. Розмірюйте відповідно.
• Тримайте запас. Операційно уникайте тримати спеціальний vdev постійно вище ~70–80%. Це не закон фізики; це закон людей.

Правило 3: Вибирайте пристрої, як для відмов, а не для бенчмарків

Що вам треба:

• підприємницькі SSD/NVMe з захистом від втрати живлення
• послідовна латентність під навантаженням записом
• надійна прошивка з історією
• достатня витривалість для тривалих випадкових записів

Чого не треба:

• невідомі споживчі NVMe, що тротлінгують при навантаженнях
• дешеві SSD з драматичними паузами через GC
• пристрої, які надійно брешуть через SMART, поки не перестають

Правило 4: Бути обачним з special_small_blocks

special_small_blocks — властивість датасету. Це добра новина: ви можете її локалізувати.
Вмикайте її для датасетів, що виграють: томи ВМ, сховища контейнерів, шарки з великою кількістю метаданих.
Вимикайте для великих медіа-архівів, де вона просто марнує дорожчу флеш на холодних даних.

Також розумійте постійність: існуючі блоки зазвичай не переміщаються просто тому, що ви змінили властивість.
Нові записи підпорядковуються новій політиці. Це важливо для міграцій і для «чому нічого не виправилося?» скарг.

Правило 5: Моніторьте здоров’я й заповненість спеціального vdev як критичне продакшн-завдання

Сповіщайте про:

• помилки пристрою, перевиділені сектори/помилки носія, помилки контрольних сум
• незвичні стрибки латентності
• швидке зростання алокацій на спеціальному vdev
• зниження швидкості метаданих у всьому пулі (таке трапляється)

Практичні завдання: команди, що означає вивід, і яке рішення ви приймаєте

Сенс рішення про спеціальний vdev — це докази. Нижче практичні завдання, які ви можете виконати сьогодні. Кожне з них має:
команду, реалістичний фрагмент виводу, що це означає, і яке рішення приймаєте.

Завдання 1: Визначити, чи вже існує спеціальний 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
        special
          mirror-1                  ONLINE       0     0     0
            nvme0n1                 ONLINE       0     0     0
            nvme1n1                 ONLINE       0     0     0

errors: No known data errors

Значення: Пул вже має клас vdev special, дзеркалений. Добре. Ваше наступне питання — «що саме там зберігається?»

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

Завдання 2: Перевірити насичення I/O пулу проти симптомів латентності

cr0x@server:~$ zpool iostat -v tank 1 5
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        42.3T  29.1T    210    180   28.1M  35.7M
  raidz2-0                  42.3T  29.1T    210    180   28.1M  35.7M
    sda                         -      -     32     27   3.9M   4.4M
    sdb                         -      -     34     28   4.0M   4.5M
    sdc                         -      -     36     31   4.1M   4.6M
    sdd                         -      -     33     29   4.0M   4.5M
--------------------------  -----  -----  -----  -----  -----  -----

Значення: Пропускна здатність помірна. Операції помірні. Якщо користувачі все ще бачать «повільні ls», ймовірно це латентність/метадані, а не насичення пропускної здатності.

Рішення: Продовжуйте дослідження тиску на метадані. Спеціальний vdev може допомогти.
Якщо пропускна здатність або операції завантажені під зав’язку — можливо, потрібні додаткові vdev, інший лейаут або виправлення sync-write поведінки.

Завдання 3: Подивитись властивості датасету, що впливають на поведінку special

cr0x@server:~$ zfs get -r special_small_blocks,recordsize,atime,compression tank/data
NAME        PROPERTY              VALUE                  SOURCE
tank/data   special_small_blocks  0                      default
tank/data   recordsize            128K                   default
tank/data   atime                 off                    local
tank/data   compression           zstd                   local

Значення: Малі блоки не перенаправляються на спеціальний vdev для цього датасету. Туди піде лише метадані (якщо спеціальний vdev існує).

Рішення: Якщо хочете прискорити дрібне випадкове IO для цього датасету (наприклад, сховище ВМ),
розгляньте обережне увімкнення special_small_blocks лише для тих датасетів, що отримають вигоду.

Завдання 4: Перевірити розмір ARC і тиск (метадані часто живуть тут спочатку)

cr0x@server:~$ arc_summary | head -n 18
ARC Summary:
    Memory Throttle Count:                    0
    ARC Size:                            62.1 GiB
    Target Size:                         64.0 GiB
    Min Size (Hard Limit):               16.0 GiB
    Max Size (Hard Limit):               64.0 GiB

ARC Misc:
    Deleted:                                1.2 GiB
    Mutex Misses:                           0
    Evict Skips:                            0

ARC Efficiency:
    Cache Hit Ratio:                       86.3%

Значення: ARC здоровий і має хороший показник. Якщо операції з метаданими все ще повільні, можливо, ви втрачаєте «гарячі» метадані в ARC через розмір робочого набору,
або вузьке місце — латентність диска під час промахів кешу.

Рішення: Якщо ARC замалий відносно навантаження — додайте RAM перед додаванням спеціального vdev.
Якщо ARC здоровий, але промахи болючі на HDD — спеціальний vdev стає привабливішим.

Завдання 5: Проінспектувати поведінку кешу метаданих vs даних (приклад Linux)

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep 'hits|misses|mfu_hits|mru_hits|metadata|demand_data|demand_metadata' | head -n 12
hits                            4    123456789
misses                          4     19654321
demand_data_hits                4     62123456
demand_metadata_hits            4     51234567
demand_data_misses              4      9234567
demand_metadata_misses          4     10419754
mru_hits                        4     31234567
mfu_hits                        4     92222222

Значення: Промахи метаданих значні. Саме тут спеціальний vdev може скоротити хвостову латентність: коли метадані не кешуються.

Рішення: Якщо demand metadata misses великі і корелюють з видимими користувачеві затримками, спеціальний vdev, ймовірно, допоможе — після перевірки, що пул не має інших проблем.

Завдання 6: Підтвердити алокацію на спеціальному vdev (чи заповнюється він?)

cr0x@server:~$ zfs list -o name,used,available,refer,mounted -r tank | head
NAME          USED  AVAIL  REFER  MOUNTED
tank         42.3T  29.1T   192K  yes
tank/data    31.8T  29.1T  31.8T  yes
tank/vm       8.9T  29.1T   8.9T  yes
tank/backup   1.6T  29.1T   1.6T  yes

Значення: Це безпосередньо не показує використання спеціального vdev. Для цього потрібні перегляди розподілу на рівні пулу і іноді статистика пристроїв.

Рішення: Продовжуйте з zdb і перевірками на рівні пулу. Якщо ви не можете кількісно виміряти ріст special, ви летите всліпу.

Завдання 7: Використати zpool list -v щоб побачити простір special

cr0x@server:~$ zpool list -v tank
NAME         SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank        72.8T  42.3T  30.5T        -         -    18%    58%  1.00x  ONLINE  -
  raidz2-0  72.8T  42.3T  30.5T        -         -    18%    58%
  special   1.82T   612G  1.22T        -         -     9%    33%
    mirror-1 1.82T  612G  1.22T        -         -     9%    33%

Значення: Клас special має ~33% використання. Це нормально. Якщо це підповзає до 80–90%, ви прямуєте до уникненого інциденту.

Рішення: Якщо спеціальний простір швидко росте — плануйте розширення раніше (додайте ще дзеркалений спеціальний vdev, залежно від вашого проєкту).
Не чекайте, поки стане «цікаво».

Завдання 8: Виміряти операції, важкі на метадані, прямо

cr0x@server:~$ time ls -U tank/data/bigdir >/dev/null

real    0m8.412s
user    0m0.031s
sys     0m0.402s

Значення: ls зайняв 8 секунд лише щоб перелічити файли (відкидаючи вивід). Це класична латентність метаданих.

Рішення: Зкорелюйте це з латентністю дисків і ARC-статистикою. Якщо підтверджено, спеціальний vdev — кандидат.
Якщо перелік каталогів швидкий, але додатки повільні — вузьке місце в іншому.

Завдання 9: Перевірити латентність пристроїв на рівні ОС (приклад Linux)

cr0x@server:~$ iostat -x 1 3
Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              32.0    28.0   4096    4608   24.5   3.2    92.0
sdb              33.0    27.0   4120    4512   23.8   3.1    91.5
sdc              34.0    29.0   4180    4620   25.1   3.3    93.2
sdd              31.0    30.0   4012    4700   26.4   3.4    94.1
nvme0n1         120.0    80.0  15360    9216    0.6   0.1    12.0
nvme1n1         118.0    78.0  15040    9152    0.7   0.1    11.5

Значення: HDD показують високе await і дуже високе завантаження. NVMе — низьколатентні та мало завантажені.
Якщо метадані на HDD — тут ваш біль. Якщо метадані вже на special — це вказує, що його можуть не використовувати як задумано.

Рішення: Якщо латентність HDD корелює з операціями метаданих — перемістіть метадані на special.
Якщо special існує, але HDD все ще страждають — перевірте, чи метадані дійсно туди потрапляють і чи ARC не треше.

Завдання 10: Підтвердити ashift та вирівнювання спеціальних пристроїв

cr0x@server:~$ zdb -C tank | egrep 'vdev_tree|type:|path:|ashift' | head -n 30
        vdev_tree:
            type: 'root'
            type: 'raidz'
            ashift: 12
            type: 'disk'
            path: '/dev/disk/by-id/ata-WDC_WD140...-part1'
            type: 'disk'
            path: '/dev/disk/by-id/ata-WDC_WD140...-part1'
            type: 'disk'
            path: '/dev/disk/by-id/ata-WDC_WD140...-part1'
            type: 'disk'
            path: '/dev/disk/by-id/ata-WDC_WD140...-part1'
            type: 'mirror'
            ashift: 12
            type: 'disk'
            path: '/dev/disk/by-id/nvme-SAMSUNG_MZ...'
            type: 'disk'
            path: '/dev/disk/by-id/nvme-SAMSUNG_MZ...'

Значення: ashift: 12 (4K сектора) типовий. Невідповідний або занадто малий ashift може погіршити продуктивність і витривалість.

Рішення: Якщо ashift неправильний на спеціальних пристроях (рідко, але можливо при міграціях), можливо доведеться перебудувати цей vdev належним чином.
Не ігноруйте вирівнювання на пристроях, які будуть зайняті випадковими IO весь день.

Завдання 11: Додати дзеркальний спеціальний vdev (реальна операція)

cr0x@server:~$ sudo zpool add tank special mirror /dev/disk/by-id/nvme-INTEL_SSDPE2KX040T8-part1 /dev/disk/by-id/nvme-INTEL_SSDPE2KX040T8B-part1

cr0x@server:~$ zpool status 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
        special
          mirror-1                                        ONLINE       0     0     0
            nvme-INTEL_SSDPE2KX040T8-part1                ONLINE       0     0     0
            nvme-INTEL_SSDPE2KX040T8B-part1               ONLINE       0     0     0

errors: No known data errors

Значення: Клас special існує і дзеркалений. Метадані почнуть використовувати його.
Існуючі метадані не обов’язково перемістяться; покращення найпомітніші для нових алокацій і для операцій, де читання потрапляють на метадані, вже збережені там.

Рішення: Далі вирішіть, чи увімкнути special_small_blocks для вибраних датасетів.
Також негайно налаштуйте моніторинг використання special і стану пристроїв.

Завдання 12: Увімкнути special_small_blocks для датасету ВМ (локально й обдумано)

cr0x@server:~$ sudo zfs set special_small_blocks=16K tank/vm

cr0x@server:~$ zfs get special_small_blocks tank/vm
NAME     PROPERTY              VALUE  SOURCE
tank/vm  special_small_blocks  16K    local

Значення: Нові блоки даних ≤ 16K у tank/vm будуть потрапляти на спеціальний vdev.
Це часто краще відповідає випадковим IO ВМ, ніж відправляти всі блоки на HDD.

Рішення: Якщо використання special почне швидко рости — зменшіть поріг або звузьте його до меншої кількості датасетів.
Якщо латентність ВМ покращилась без наповнення special — ви знайшли добрий компроміс.

Завдання 13: Підтвердити покращення за допомогою тесту метаданих до/після

cr0x@server:~$ time find tank/data/bigdir -maxdepth 2 -type f -print >/dev/null

real    0m14.227s
user    0m0.081s
sys     0m0.913s

Значення: Це тест обходу, важкий на метадані. Запустіть його до і після додавання special або зміни властивостей.
Мета — напрямкова доказовість, а не досконалість.

Рішення: Якщо не покращилось — ймовірно, ви не мали вузького місця в метаданих, або ARC вже це ховав, або датасет не використовує special як треба.
Поверніться до діагностики.

Завдання 14: Перевірити лічильники помилок special і результати scrub

cr0x@server:~$ zpool status -x
all pools are healthy

cr0x@server:~$ zpool status tank | sed -n '1,25p'
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:14:33 with 0 errors on Sun Feb  4 02:00:26 2026
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
        special
          mirror-1                  ONLINE       0     0     0
            nvme0n1                 ONLINE       0     0     0
            nvme1n1                 ONLINE       0     0     0

errors: No known data errors

Значення: Чистий scrub і нуль помилок — це те, чого ви прагнете, особливо для спеціальних пристроїв.
Навіть кілька помилок контрольних сум на special повинні викликати серйозне занепокоєння: ви псуєте нервову систему пулу.

Рішення: Якщо бачите помилки на special — замінюйте пристрої агресивно і розслідуйте кабелі/бекплейн/прошивку.
Не «стежте за цим деякий час». Саме так ви виявитеся відновлюючи з бекапу, пояснюючи це дорослим.

Завдання 15: Підтвердити поведінку sync-записів (щоб уникнути неправильного діагнозу)

cr0x@server:~$ zfs get sync tank/vm
NAME     PROPERTY  VALUE  SOURCE
tank/vm  sync      standard  default

Значення: Sync-записи не вимкнено примусово. Якщо ваше навантаження — NFS/ВМ зі sync-записами, відсутній або слабкий SLOG може домінувати у затримках.

Рішення: Якщо ви переслідуєте латентність і ваше навантаження робить багато sync-записів — оцініть SLOG окремо.
Не використовуйте спеціальний vdev як замінник правильно спроектованого шляху синхронного запису.

Завдання 16: Перевірити фрагментацію і як вона впливає на зміну метаданих

cr0x@server:~$ zpool list -o name,size,alloc,free,frag,cap tank
NAME  SIZE  ALLOC  FREE  FRAG  CAP
tank  72.8T  42.3T  30.5T   18%   58%

Значення: Помірна фрагментація. Висока фрагментація може збільшити накладні витрати на метадані і зробити роботу HDD більш «seek’овою».

Рішення: Якщо frag дуже високий і продуктивність падає — спеціальний vdev може допомогти, але може й лікувати симптоми.
Розгляньте перепис/реплікацію датасетів для перегрупування, і перегляньте політики збереження снапшотів.

Швидка діагностика — план дій: знайдіть вузьке місце перед тим, як купувати NVMe

Це послідовність «перестаньте сперечатися і зберіть факти». Запустіть у вказаному порядку. Мета — класифікувати уповільнення за хвилини, а не дні.

Спочатку: це латентність метаданих чи щось інше?

1. Запустіть простий тест метаданих (time ls у величезному каталозі або find обмеженої глибини). Якщо повільно — є підозра.
2. Перевірте латентність пристроїв ОС (iostat -x). Якщо HDD await високий при помірній пропускній здатності — це кричить «більша частина випадкових IO».
3. Перевірте ARC hit ratio і промахи метаданих. Якщо промахи метаданих значні й корелюють зі симптомами — ви в зоні special-vdev.

Друге: підтвердьте, що ZFS не карає вас за sync-записи

1. Перевірте властивість датасету sync.
2. Ідентифікуйте навантаження: NFS з sync, бази даних, сховище ВМ тощо.
3. Шукайте високу латентність під час записів, навіть коли читання нормальні. Це часто SLOG або поведінка flush-ів пристрою.

Третє: перевірте ємність/фрагментацію та операційні міни

1. Ємність пулу: якщо ви вище ~80% — виправляйте це спочатку. ZFS під тиском простору може поводитись погано.
2. Фрагментація: висока frag + багато снапшотів можуть зробити метадані дорожчими.
3. Якщо у вас вже є special — перевірте його заповненість і помилки. Хворий special може виглядати як «дивна поведінка пулу».

Точка рішення

• Додати special vdev, якщо: операції метаданих повільні, латентність HDD висока під час цих операцій і промахи ARC метаданих значущі.
• Не додавати special vdev, якщо: реальна проблема — шлях sync-записів, нестача ARC, CPU або мережа.

Три корпоративні історії з практики

Інцидент: хибне припущення («special — це як кеш, правда?»)

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

Припущення було простим і хибним: що special поводиться як L2ARC — приємно, але безпечно втратити. Зміна зайшла в maintenance window.
Вона дійсно покращила швидкість одразу. Ця позитивна петля небезпечна; вона переконує всіх, що дизайн був правильний.

За кілька тижнів SSD почав кидати помилки носія. Він не вмер відразу; він іноді корумпував читання і логував таймаути.
Пул почав показувати помилки контрольних сум. Потім сервіси почали падати в непомітний спосіб: випадкові помилки доступу до файлів, дивні ENOENT,
і «неможлива» поведінка під час операцій зі снапшотами.

Відновлення було брудним, але повчальним: довелося терміново замінювати пристрій, діяти як при загрозі пулу,
і метушитися з валідацією реплік. Постмортем не був про звинувачення. Він був про семантику: special — це не кеш.
Вони переробили дизайн з дзеркальною парою підприємницьких SSD і додали моніторинг лічильників помилок.

Урок: швидкі покращення, що з’являються відразу, можуть бути початком повільної катастрофи, якщо припущення хибні.

Оптимізація, що зіграла зворотний ефект: «Поставимо special_small_blocks велике і завоюємо назавжди»

Інша організація хостила віртуальні десктопи та безліч сервісів на ZFS. Вони додали дзеркальний special vdev, потім вирішили стати амбітними.
Хтось поставив special_small_blocks на високе значення на батьківському датасеті, бо «дрібне IO повільне, а флеш — швидка».
Звучало логічно на зустрічі. Зустрічі роблять таке.

Місяць всі були щасливі. Штормові завантаження під час старту ОС були менш болючі. Логін пришвидшився. Графіки виглядали краще, і питання припинилися.
Потім спрацювала тривога ємності — не на основному пулі, а на спеціальному vdev.
Він повільно заповнювався, бо дедалі більше реальних даних користувачів відповідали критерію «малий блок».

Спеціальний vdev перетворився зі «шару метаданих» на «гарячий шар даних» без явного визнання. Коли він наблизився до високого використання,
нові алокації стали обмежені, продуктивність дивно падала: раптові затримки, довгі хвости латентностей і кілька страшних провалів алокацій під високим навантаженням.
Команда спочатку звинувачувала ZFS, потім гіпервізор, нарешті мережу (звісно).

Виправлення не було гламурним. Вони зменшили special_small_blocks для більшості датасетів, залишили його для ВМ, що дійсно вигравали,
і розширили клас special ще однією дзеркальною парою. Також додали політику: будь-яка зміна special_small_blocks вимагає проєкції ємності і плану відкату.

Урок: перемістити дані на special легко. Повернути їх назад — це плата, за яку ви платите.

Бездушно правильна практика, що врятувала день: «ми дзеркалили, моніторили і репетірували»

Компанія у сфері фінансів тримала файл-сервіс з інтенсивною зміною метаданих: мільйони файлів, активне використання ACL і строгий режим снапшотів/реплікації.
Інженер наполягав на дзеркальному special vdev з підприємницькими NVMe, плюс SMART-моніторинг, регулярні scrub’и і сповіщення про заповнення special.
Ніхто не влаштовував вечірку за цей план. Ось чому він був правильний.

Через місяць один NVMe у дзеркалі special почав показувати зростання помилок носія.
Оповіщення спрацювали рано, ще до видимих користувачем симптомів. Вони швидко запланували заміну.
Під час заміни пул залишався онлайн; надлишковість зробила свою роботу; геройських зусиль не знадобилося.

Післяопераційний огляд був нудним. Насправді він полягав у «сповіщення спрацювали» і «процедури відповідали реальності».
Це найвища похвала практиці опсів.

Урок: special vdev безпечний, якщо ви ставитеся до нього як до критичної інфраструктури, а не як до аксесуара для продуктивності.

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

1) Симптом: Пул ONLINE, але додатки бачать випадкові ENOENT / помилки I/O

Корінь: Спеціальний vdev деградований або повертає помилки; читання метаданих провалюються або корумпуються.

Виправлення: Перевірте zpool status -v. Негайно замініть несправні спеціальні пристрої. Запустіть scrub. Перевірте контролер/бекплейн/прошивку.

2) Симптом: Додали special vdev і нічого не пришвидшилось

Корінь: Навантаження не обмежене метаданими (або ARC вже їх ховає), або датасет не генерує нових метаданих у «гарячому» шляху.

Виправлення: Повторіть швидкий діагностичний план. Перевірте ARC промахи метаданих, await HDD і де витрачається час (sync-записи, мережа, CPU).

3) Симптом: Спеціальний vdev заповнюється набагато швидше, ніж очікувалось

Корінь: special_small_blocks ввімкнено занадто широко або встановлено занадто високо, переміщуючи дані користувачів на special.

Виправлення: Зменшіть/відключіть special_small_blocks для загальних датасетів. Залиште його тільки там, де виправдано. Розширте special до досягнення критичного рівня.

4) Симптом: Після увімкнення special_small_blocks витривалість NVMe виглядає лякаючою

Корінь: Записи малих блоків інтенсивні; спеціальні пристрої несуть реальне навантаження записами, а не лише оновлення метаданих.

Виправлення: Зменшіть поріг. Розгляньте переміщення записово-важких датасетів назад на HDD-vdev або збільшіть дзеркальний special ємнісно та використайте пристрої з кращою витривалістю.

5) Симптом: Тижні відмінної продуктивності, потім раптові хвостові стрибки латентності

Корінь: Спеціальні пристрої відчувають паузи прошивки GC, тепловий тротлінг або близькість до високого використання, що викликає контенцію алокацій.

Виправлення: Перевірте температуру NVMe/латентність на рівні ОС, тренд використання special і розгляньте іншу категорію SSD. Тримайте використання special у безпечнішому діапазоні.

6) Симптом: «zfs list -t snapshot» надзвичайно повільний

Корінь: Обхід метаданих, важкий на снапшоти, на HDD; промахи ARC для метаданих; можливо, дуже багато снапшотів.

Виправлення: Тут special vdev допомагає. Також раціоналізуйте політики зберігання снапшотів. Перевірте промахи метаданих і розгляньте додавання RAM.

7) Симптом: Операції з метаданими покращились, але записна латентність ВМ все ще погана

Корінь: Дорогу займає шлях sync-записів (NFS sync, fsync-шторм у гостьовій ОС) і немає належного SLOG або поведінка flush пристрою повільна.

Виправлення: Проєктуйте SLOG відповідно (це окрема тема), перевірте налаштування sync і виміряйте латентність записів конкретно. Не звинувачуйте метадані у проблемі sync.

8) Симптом: Дзеркало special показує помилки контрольних сум, але диски «виглядають нормально»

Корінь: Часто кабелі, слоти PCIe/бекплейн, нестабільність живлення або баги контролера; не завжди NAND.

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

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

Покроково: вирішіть, чи додавати спеціальний vdev

1. Доведіть, що це метадані.
   Запустіть тест важкий на метадані (ls/find) і зкорелюйте з латентністю HDD (iostat -x) та промахами ARC метаданих.
2. Виключіть очевидні неметадані вузькі місця.
   Перевірте RAM/давлення ARC, поведінку sync-записів, завантаження CPU і мережу.
3. Виберіть обсяг.
   Тільки метадані? Чи метадані + малі блоки на вибраних датасетах? За замовчуванням — тільки метадані, доки немає причини інакше.
4. Проєкт надлишковості.
   Дзеркало (мінімум). Віддавайте перевагу підприємницьким SSD/NVMe. Плануйте моніторинг.
5. Розмірюйте з запасом.
   Оцініть зростання з урахуванням снапшотів і кількості файлів. Не тримайте special майже повним.
6. Плануйте операційно.
   Вікно технічного обслуговування, очікування відкату (обмежені), scrub після дії, пороги тривог і оновлення рукопису on-call.

Чекліст впровадження (робіть це в цьому порядку)

1. Підтвердіть ідентичність пристроїв через /dev/disk/by-id/, а не гадаючи /dev/nvme0n1.
2. Підтвердіть стан пулу: zpool status -x.
3. Додайте дзеркальний special vdev: zpool add pool special mirror ....
4. Перевірте присутність і стан ONLINE: zpool status, zpool list -v.
5. Опційно встановіть special_small_blocks лише на конкретні датасети (почніть з 8K–16K і вимірюйте).
6. Запустіть scrub незабаром після зміни (і регулярно): zpool scrub, потім перевірте результати.
7. Налаштуйте моніторинг: використання special, SMART/помилки носія NVMe, латентні аномалії.
8. Повторіть той же тест на метадані і зафіксуйте до/після.

Операційний чекліст (те, що рятує від пейджингу)

• Сповіщення, якщо використання special переходить поріг (попередження ~70%, критично ~80–85%).
• Сповіщення про будь-які READ/WRITE/CKSUM помилки на членах special vdev.
• Відстежуйте витривалість NVMe і помилки носія з часом.
• Майте запасні пристрої або шлях закупівлі, що не включає «термінове придбання на маркетплейсі».
• Відрепетируйте заміну пристрою на непроизводчому пулі, якщо команда це не робила.

ЧаПи

1) Чи прискорить спеціальний vdev усе?

Ні. Він прискорює те, що обмежено латентністю метаданих (і опційно дрібними блоками). Послідовні читання великих файлів зазвичай не зміняться суттєво.
Якщо ваша проблема — sync-записи, тиск ARC, CPU або мережа, спеціальний vdev цього не вирішить.

2) Чи безпечно запускати спеціальний vdev як один пристрій?

У продакшені — ні. Якщо він містить метадані, його втрата може призвести до втрати пулу. Дзеркальте його мінімум.
Одиночний спеціальний vdev підходить для лабораторій, демо чи середовищ, де ви погоджуєтесь на катастрофічний ризик.

3) Чи те саме special і L2ARC?

Зовсім ні з операційної точки зору. L2ARC — кеш і може бути видалений без втрат даних (втратите лише кеш). Special vdev зберігає авторитарні блоки. Ставтеся до нього як до критичного сховища.

4) Що ставити в special_small_blocks?

Починайте консервативно й для конкретних датасетів. 8K або 16K — часті початкові значення для випадків із ВМ та випадкового IO.
Не ставте високо по всіх датасетах, якщо не розмірювали special як реальний шар і не готові прийняти, що користувацькі дані житимуть там.

5) Чи можу я перемістити існуючі метадані на special після додавання?

ZFS зазвичай розміщує нові алокації за поточними правилами; він не переписує світ автоматично.
Деякі покращення прийдуть негайно, бо нові метадані й певна активність змінять шляхи, але повна «міграція» зазвичай вимагає перезапису даних (наприклад, реплікація в новий датасет).

6) Як зрозуміти, чи я обмежений метаданими?

Шукайте повільні переліки каталогів/обходи, повільний перелік снапшотів, високий HDD await при помірній пропускній здатності і значні промахи ARC метаданих.
Якщо ці ознаки сходяться — ви, ймовірно, обмежені метаданими.

7) Чи змінює додавання special vdev стратегію бекапів/реплікації?

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

8) Що робити спочатку: додати special чи додати більше RAM?

Якщо явно не вистачає ARC, додайте RAM спочатку. RAM — найшвидший рівень метаданих, який можна купити.
Special vdev допомагає, коли промахи ARC неминучі і латентність HDD все одно вбиває вас.

9) Чи допоможе special vdev для NFS/SMB-шарів?

Часто так, особливо для шарів з безліччю дрібних файлів, глибокими деревами, перевірками ACL і великою змінністю метаданих.
Але якщо біль — у мережі, клієнтській поведінці або sync-записах, це треба вирішувати окремо.

10) Який найбільший червоний прапор після додавання special?

Будь-які помилки на пристроях special і швидке зростання використання special, якого ви не прогнозували. Обидва вимагають негайної уваги.

Наступні кроки, які ви можете зробити цього тижня

1. Запустіть швидку діагностику і збережіть виводи: zpool iostat, iostat -x, ARC-статистика і час обходу метаданих.
   Якщо ви не можете надати доказів, ви приймаєте покупкове рішення, а не інженерне.
2. Якщо обмеження — метадані, спроєктуйте дзеркальний special vdev з надійними SSD/NVMe з захистом від втрати живлення і розмірюйте з запасом.
3. Додайте special vdev і моніторьте негайно. Якщо ви не попереджаєте про використання special та помилки — ви на шляху до довгої ночі.
4. Увімкніть special_small_blocks лише там, де це виправдано (датасети ВМ, сховища контейнерів), починайте консервативно і слідкуйте за ростом special.
5. Напишіть рукопис для відмови спеціального пристрою: як ідентифікувати, як замінити, як верифікувати через scrub і status, і кого пейджити.

Спеціальний vdev — один з найефективніших «реальних» інструментів прискорення в ZFS — бо він цілиться в ту латентність, яку відчувають люди.
Він також один з найпростіших способів перетворити стійкий пул у крихкий, якщо ставитися до нього як до кешу. Не робіть так.