Читання лише метаданих у ZFS: як special vdev змінює правила гри

Що насправді означає «читання тільки метаданих» у ZFS

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

В термінах ZFS це переважно блоки на кшталт:

• Indirect blocks (вказівники блоків, що описують, де розташовані дані).
• dnodes (метадані об’єкта: тип, розмір, вказівники блоків, bonus buffer).
• ZAP objects (stores ім’ям/значенням, широко використовуються для каталогів і властивостей).
• Space maps / metaslabs (облік виділення простору; може з’являтися при патологічних шаблонах розміщення).
• DDT якщо dedup увімкнено (детальніше: не вмикайте, якщо ви цього дійсно не маєте на меті).

Навантаження, що важко «метадані», може мати жахливі показники «MB/s», одночасно насичуючи бюджети IOPS і затримок. Пул здається простим для тих,
хто моніторить тільки пропускну здатність. Тим часом ваш додаток бачить «повільне сховище», тому що кожен пошук метаданих — це випадкове читання,
а випадкові читання на HDD — це, по суті, переговори з фізикою.

Брудний секрет: багато «операцій читання» фактично є навантаженнями типу lookup. Ферма збірки, яка робить мільйони маленьких file stat.
Поштовий сервер, що обходить каталоги. Платформа контейнерів, що перераховує шари. Програмне забезпечення резервного копіювання, яке виконує попереднє сканування
всього перед читанням хоча б одного байта. Це робота з метаданими, що іноді читає дані.

Одне висловлювання варте того, щоб приклеїти його до монітора:
Все ламається; важливо будувати системи, які ламаються передбачувано і швидко відновлюються.
— John Allspaw

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

Special vdev: що це і чим це не є

Special vdev — це allocation class в OpenZFS. Це місце, куди ZFS може розміщувати певні категорії блоків,
зазвичай метадані і (за бажанням) блоки «малих» файлів, на швидшому класі vdev, ніж основний пул.

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

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

Що за замовчуванням потрапляє у special

За наявності special vdev ZFS за замовчуванням розміщуватиме там метадані (залежно від деталей реалізації і доступного місця).
Це включає dnodes, indirect blocks, структури каталогів (ZAP) та інші об’єкти метаданих.

Що може потрапити в special, якщо ви цього попросите

Властивість dataset special_small_blocks дозволяє відправляти також блоки даних малих файлів у special.
Це той перемикач, який перетворює «акселератор метаданих» на «акселеротор дрібних I/O».

Саме тут люди схвильовано натискають на газ, а потім отримують звільнення. Ми розглянемо, як зробити це без другої частини.

Жарт №1: Special vdev як еспресо — змінює життя в правильній дозі, і жахливо, якщо ви «оптимізуєте» до 3 ранку.

Як special vdev змінює шлях читання

Без special vdev читання метаданих поводяться як будь-які інші читання: ZFS обходить вказівники, отримує блоки з тих самих vdev, що тримають дані,
і сильно покладається на ARC, щоб уникнути повторних звернень до дисків. ARC допомагає, але холодний кеш, надто велика робоча множина або агресивне сканування
можуть виштовхнути метадані і примусити реальне I/O.

З special vdev блоки, що описують файлову систему, розміщуються на vdev класі, зазвичай SSD або NVMe. Результат:

• Випадкове I/O метаданих переходить із HDD-пошуків на читання SSD.
• Колапс затримок: не лише нижче середнє, а й менше жахливих хвостових затримок.
• Вища ефективна конкурентність: операції, які раніше серіалізувались через переміщення головки, стають паралельними.
• ARC стає ефективнішим: швидке отримання метаданих зменшує час простоїв і покращує розігрів кешу.

Важливий нюанс: special vdev не усуває магічно I/O метаданих. Він робить його настільки дешевим, що метадані перестають домінувати.
Ваш вузький місце тоді може переміститися куди-інде: CPU (компресія), мережа, блокування в додатку або основні data vdev.
Це гарна проблема. Принаймні чесна.

Metadata-only reads у реальному житті

Декілька шаблонів, що призводять до «переважно читань метаданих»:

• Великі обходи каталогів: повторювані readdir(), stat(), перевірки прав.
• Дані з великою кількістю снапшотів: списки снапшотів, клонів і send з важкою вартістю обходу.
• Перевірка резервних копій: операції «порівняти список файлів», що торкаються всього.
• Розпаковка контейнерних образів: багато дрібних файлів, багато оновлень і пошуків метаданих.
• Системи збірки: крихітні файли, безліч перевірок існування, метадані в активному стані.

Факти та історія, що важливі в продакшні

Кілька контекстних пунктів, які допоможуть вам мислити про special vdev та поведінку метаданих, не перетворюючи розгляд інцидентів на аспірантуру:

1. ZFS спроектовано для цілісності кінця в кінець: метадані не опціональні; їхня втрата означає, що ви не можете безпечно інтерпретувати блоки даних.
2. ARC з’явився раніше, ніж «special vdev» як мейнстрім-фіча: ранній тюнінг ZFS покладався на оперативну пам’ять і розміщення, а не на класи алокації.
3. L2ARC з’явився раніше за special vdev: L2ARC — це кеш і його можна втратити; special vdev — це сховище і не можна.
4. Ідея «метадані на SSD» існувала задовго до ZFS: файлові системи та масиви давно використовували дзеркальні NVRAM/SSD для мап і журналів.
5. Класи алокації OpenZFS розвивалися з часом: ранні можливості були консервативними; сучасні розгортання широко використовують special vdev для змішаних навантажень.
6. Таблиці dedup (DDT) — це метадані на стероїдах: при увімкненому dedup DDT може домінувати в випадкових читаннях і використанні пам’яті.
7. Indirect blocks можуть становити велику частку I/O: особливо з великими файлами і випадковими читаннями ви можете бути звужені на переході по вказівниках.
8. Special vdev змінив проблему «дрібних файлів»: переміщення блоків маленьких файлів на SSD часто є різницею між «нормально» і «чому ls займає секунди?»

Заголовок: special vdev — не іграшка. Це визнання ZFS того, що затримка метаданих часто справжній ворог, і що додати HDD — сумний вид кардіо.

Коли special vdev дає великий виграш (і коли це марно)

Сценарії великого виграшу

• Мільйони дрібних файлів, де обходи каталогів і stat’и домінують.
• Віртуалізація або хости контейнерів з великою кількістю дрібних конфігураційних файлів і частих запитів.
• Цілі резервного копіювання, де фази сканування/верифікації є вузьким місцем.
• Дані з великою кількістю снапшотів, де вартість обходу метаданих помітна в send/list операціях.
• Пули з увімкненим dedup (знову: тільки якщо ви дійсно цього хочете), де читання DDT домінує; special може допомогти, але RAM важливіша.

Малопридатні або маргінальні сценарії

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

Де люди помиляються в прогнозах

Класична помилка: «наш пул повільний, бо HDD повільні, тому SSD все виправить». Іноді так. Частіше ні.
Якщо ваша біль — це затримка випадкових читань метаданих, special vdev — хірургічний інструмент.
Якщо ж ваша проблема — «ми завантажені CPU компресією» або «додаток виконує одну операцію за раз», тоді special vdev в основному робить графіки красивішими.

Проєктування розумних layout для special vdev

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

Правила надлишковості, що не гнуться

• Використовуйте mirrors для special vdev у більшості середовищ. Існують RAIDZ special vdev, але дзеркала тримають латентність низькою і домени відмови чистими.
• Підбирайте або перевищуйте надійність пулу. Якщо ваші data vdev — RAIDZ2, special vdev не має бути одиноким SSD «бо це enterprise».
• Плануйте знос. Метадані можуть генерувати інтенсивні записи при великому churn. Обирайте SSD з реальною витривалістю, а не «те, що було на розпродажі».

Розмір: те, що всі вгадують неправильно

Занадто малий special — і ви досягнете 80–90% використання, алокації стануть обмеженими і продуктивність почне поводитись дивно.
Занадто великий — і ви переплатите, але отримаєте операційну спокійність: місце для росту, запас для ребалансування, менше стрімких обривів.

Практичні поради щодо розмірів:

• Тільки метадані в special: виділіть його доволі щедро, щоб він залишався комфортно нижче ~70% використання у steady state.
• Метадані + малі блоки: передбачайте, що це стане «гарячим» шаром. Плануйте його як справжній датасет, бо по суті так воно і є.
• Середовища з великою кількістю снапшотів: метадані зростають разом з історією. Бюджетуйте це. «Ми видалимо снапшоти пізніше» — не стратегія; це казочка перед сном.

special_small_blocks: гострий ніж

Встановлення special_small_blocks у ненульове значення означає, що будь-які блоки розміром ≤ цього значення виділятимуться в special.
Якщо ви встановите його в 128K на датасеті з recordsize=128K, вітаю: ви щойно сказали ZFS класти по суті всі дані в special. Люди роблять це випадково. Потім вони дізнаються нових відчуттів.

Консервативний підхід:

• Почніть з 0 (тільки метадані), виміряйте, потім розгляньте 16K або 32K для навантажень з дрібними файлами.
• Використовуйте його на рівні датасету, а не як глобальну «оптимізацію» пулу. Ваші VM-образи не потребують цього; ваше джерело коду може потребувати.
• Документуйте. Майбутній ви — чужинець, який звинуватить теперішнього вас.

Жарт №2: Встановити special_small_blocks=128K на зайнятий датасет — це як поставити весь ваш офіс на гостьовий Wi‑Fi, бо «він тестував швидше».

Практичні завдання: команди, значення виводу та рішення

Це щоденні перевірки, що відділяють «я читав про special vdev» від «я можу ними оперувати о 2:00 без імпровізацій».
Кожне завдання включає команду, приклад виводу, що це означає і яке рішення приймаєте.

Завдання 1: Підтвердити layout пулу та наявність special class

cr0x@server:~$ sudo 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
        special
          mirror-1                  ONLINE       0     0     0
            nvme0n1p1               ONLINE       0     0     0
            nvme1n1p1               ONLINE       0     0     0

errors: No known data errors

Значення: Розділ special існує і дзеркалиться. Добре. Якщо ви не бачите special, у вас його немає.

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

Завдання 2: Перевірити статистику класів алокації (чи байти справді потрапляють туди?)

cr0x@server:~$ sudo zpool list -v tank
NAME         SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank        109T  72.4T  36.6T        -         -    18%    66%  1.00x  ONLINE  -
  raidz2-0  109T  70.9T  38.1T        -         -    18%    65%      -  ONLINE
  special   3.64T  1.52T  2.12T        -         -     9%    41%      -  ONLINE

Значення: Special має алокацію. Якщо вона ближче до нуля, тоді щось не так (немає special під час створення пулу, або блоки предатовані).

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

Завдання 3: Перевірити налаштування dataset, що керують розміщенням блоків

cr0x@server:~$ sudo zfs get -o name,property,value -s local,received special_small_blocks,recordsize,atime,compression tank/projects
NAME           PROPERTY              VALUE
tank/projects  special_small_blocks  32K
tank/projects  recordsize            128K
tank/projects  atime                 off
tank/projects  compression           zstd

Значення: Цей датасет буде відправляти блоки ≤32K в special. З recordsize=128K туди потраплятимуть лише реально дрібні файли/блоки.

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

Завдання 4: З’ясувати, чи ваше «повільне читання» — метадані (огляд ARC)

cr0x@server:~$ sudo arcstat 1 5
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:01:01   560    90     16    40   44    22   24    28   31   64G   96G
12:01:02   610   110     18    55   50    24   22    31   28   64G   96G
12:01:03   590   105     17    52   50    25   24    28   27   64G   96G
12:01:04   605   120     20    62   52    28   23    30   25   64G   96G
12:01:05   575   115     20    60   52    27   23    28   24   64G   96G

Значення: Високі пропуски метаданих (dmis/mmis) вказують, що метадані не тримаються в ARC і читаються з диска/special.

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

Завдання 5: Виміряти затримки на рівні vdev під час «метаданної бурі»

cr0x@server:~$ sudo zpool iostat -v tank 1 3
                 capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        72.4T  36.6T    820    190  18.2M  4.5M
  raidz2-0  70.9T  38.1T    260    160   6.1M  4.0M
    sda         -      -     45     26   1.1M   700K
    sdb         -      -     43     25   1.0M   680K
    sdc         -      -     44     27   1.1M   710K
    sdd         -      -     42     26   1.0M   690K
    sde         -      -     44     28   1.1M   720K
    sdf         -      -     42     28   1.0M   720K
  special   1.52T  2.12T    560     30  12.1M   520K
    mirror-1     -      -    560     30  12.1M   520K
      nvme0n1p1  -      -    280     15   6.0M   260K
      nvme1n1p1  -      -    280     15   6.1M   260K

Значення: Читання інтенсивно влучають у special. Це очікувано, якщо там лежать метадані/малі блоки.

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

Завдання 6: Перевірити здоров’я special vdev і лічильники помилок

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 07:21:10 with 0 errors on Sun Dec 22 03:10:11 2025
config:

        NAME          STATE     READ WRITE CKSUM
        tank          ONLINE       0     0     0
        ...
        special
          mirror-1    ONLINE       0     0     0
            nvme0n1p1 ONLINE       0     0     0
            nvme1n1p1 ONLINE       0     0     0

errors: No known data errors

Значення: Чисто. Якщо ви бачите помилки на special — ставте це як терміновий інцидент, а не «проблема продуктивності».

Рішення: Замініть несправні special-пристрої негайно. Degraded special mirror — це зворотний відлік до відмови пулу.

Завдання 7: З’ясувати, чи метадані все одно переповнюють основні vdev (черги)

cr0x@server:~$ iostat -x 1 2
Linux 6.6.0 (server) 	12/26/2025 	_x86_64_	(32 CPU)

Device            r/s   w/s  rkB/s  wkB/s  await  svctm  %util
sda              35.0  22.0  1100.0  680.0  28.5   3.2   98.0
sdb              34.0  23.0  1050.0  690.0  27.8   3.1   97.5
nvme0n1          290.0  18.0  6200.0  260.0   1.1   0.3   22.0
nvme1n1          295.0  17.0  6300.0  260.0   1.0   0.3   21.0

Значення: HDD близькі до 100% завантаження з високим await, тоді як NVMe має запас. Або метадані все ще потрапляють на HDD, або навантаження — дане-важке.

Рішення: Якщо special існує, перевірте special_small_blocks і підтвердіть розміщення метаданих. Інакше плануйте special або зменшення churn метаданих.

Завдання 8: Перевірити ashift і вирівнювання секторів на special-пристроях

cr0x@server:~$ sudo zdb -C tank | sed -n '1,80p'
MOS Configuration:
        version: 5000
        name: 'tank'
        vdev_children: 2
        vdev_tree:
            type: 'root'
            id: 0
            guid: 1234567890
            children[0]:
                type: 'raidz'
                ashift: 12
                ...
            children[1]:
                type: 'mirror'
                ashift: 12
                is_special: 1
                ...

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

Рішення: Якщо ashift неправильний, ви не «налаштуєте» це. Плануйте міграцію або перебудову для виправлення.

Завдання 9: Перевірити, наскільки повний special vdev (і діяти до проблем)

cr0x@server:~$ sudo zpool list -o name,size,alloc,free,cap,frag tank
NAME  SIZE   ALLOC  FREE   CAP  FRAG
tank  109T   72.4T  36.6T  66%  18%

Значення: Це на рівні пулу. Воно не показує повноту special окремо; використовуйте zpool list -v як у Завданні 2.

Рішення: Якщо клас special підкрадається вище ~70–80% використання, плануйте розширення заздалегідь. Не чекайте «воно заповнилось», бо тоді опції стають поганими.

Завдання 10: Дивитися, які датасети важкі з точки зору метаданих (кількість снапшотів як підказка)

cr0x@server:~$ sudo zfs list -t snapshot -o name -S creation tank/projects | head
NAME
tank/projects@auto-2025-12-26-0000
tank/projects@auto-2025-12-25-0000
tank/projects@auto-2025-12-24-0000
tank/projects@auto-2025-12-23-0000
tank/projects@auto-2025-12-22-0000
tank/projects@auto-2025-12-21-0000
tank/projects@auto-2025-12-20-0000
tank/projects@auto-2025-12-19-0000
tank/projects@auto-2025-12-18-0000

Значення: Обсяг снапшотів множить метадані. Більше снапшотів часто означає більше витрат на обходи метаданих.

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

Завдання 11: Перевірити вплив scrub/resilver на special vdev

cr0x@server:~$ sudo zpool status tank | sed -n '1,25p'
  pool: tank
 state: ONLINE
  scan: scrub in progress since Thu Dec 26 01:20:44 2025
        9.21T scanned at 1.05G/s, 1.90T issued at 222M/s, 72.4T total
        0B repaired, 2.62% done, 3 days 17:12:00 to go

Значення: Scrub дуже інтенсивно обходить метадані. Якщо ваш special — дім метаданих, scrub-поведінка і латентність можуть змінитися (часто на краще).

Рішення: Якщо scrub ламатиме продуктивність, плануйте його неспік, обмежуйте (залежить від платформи) і переконайтесь, що special не слабкий.

Завдання 12: Підтвердити, що ваш «швидкий шар» не використовується як write-amplifier

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | egrep -i 'percentage|data units|media|error'
Percentage Used:                    7%
Data Units Written:                 18,442,119
Data Units Read:                    21,104,553
Media and Data Integrity Errors:    0
Error Information Log Entries:      0

Значення: Зношування вимірюється. Metadate churn плюс малі блоки даних можуть їсти витривалість споживчих SSD.

Рішення: Якщо «Percentage Used» швидко росте, змініть клас SSD, зменшіть churn метаданих або припиніть штовхати малі блоки в special.

Завдання 13: Валідовувати, що саме лежить у special (високо-рівнева інференція через алокацію)

cr0x@server:~$ sudo zfs get -r -o name,property,value special_small_blocks tank | head -n 12
NAME                 PROPERTY              VALUE
tank                 special_small_blocks  0
tank/projects        special_small_blocks  32K
tank/vm              special_small_blocks  0
tank/backups         special_small_blocks  0
tank/containers      special_small_blocks  16K

Значення: Лише деякі датасети штовхають малі блоки в special. Це здорово: таргетоване використання замість пиляння пулу.

Рішення: Тримайте це таргетованим. Якщо все налаштовано на 128K «для продуктивності», ви скоро отримаєте дуже дорогий special vdev.

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

cr0x@server:~$ sudo strace -f -tt -p $(pgrep -n rsync) -e trace=newfstatat,getdents64,openat -c
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 58.41    0.723601          12     59041       112 newfstatat
 31.22    0.386926          14     26874           getdents64
 10.37    0.128504          10     12245        45 openat
------ ----------- ----------- --------- --------- ----------------
100.00    1.238?                   98160       157 total

Значення: Додаток витрачає більшість викликів на stat і перебір каталогів. Це — метадані. Ваш вузький місце ймовірно в I/O метаданих і затримці.

Рішення: Пріоритезуйте special vdev і тюнінг метаданих над «більше дисків» або «збільшити recordsize». Навантаження не просить пропускної здатності.

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

Коли хтось каже «сховище повільне», у вас немає часу на інтерпретативний танець. Потрібен швидкий шлях триажу, що звужує вузьке місце до: ARC, special vdev, основні vdev,
CPU або додаток, що робить щось невдале.

Перше: визначити, чи домінують метадані

• Перевірте шаблони системних викликів (вибірка strace) і опис навантаження: багато stat(), readdir(), списків снапшотів, сканування.
• Перевірте пропуски ARC (Завдання 4). Рівні пропусків метаданих — це маркер.
• Перевірте пропускну здатність проти затримки: низький MB/s з високими операціями зазвичай — метадані або дрібні випадкові читання.

Друге: визначити, який клас vdev обслуговує читання

• Використайте zpool iostat -v (Завдання 5) під час уповільнення.
• Якщо читання б’ють по special, підтвердіть затримку SSD і здоров’я.
• Якщо читання б’ють по HDD, або метадані не на special (або старі блоки не були переписані), або навантаження — data-важке.

Третє: вирішити, чи ви вузькі місцем через тиск ємності, черги чи конфігурацію

• Перевірте алокацію і ємність special (Завдання 2). Переповнений special — це обрив продуктивності.
• Перевірте черги пристроїв (iostat -x, Завдання 7). Високий await на SSD вказує на насичення або конкуренцію.
• Підтвердіть налаштування датасету (special_small_blocks, recordsize, compression) (Завдання 3).
• Перевірте, чи не виконується scrub/resilver (Завдання 11).

Вивід цього плану має бути одним реченням, яке можна написати в Slack без опалу:
«Ми зв’язані пропусками метаданих і читання йдуть на HDD; special не несе метадані для цього датасету»
або
«Special завантажений на 85% використання; треба його розширити і припинити штовхати 32K блоки туди для тієї задачі резервного копіювання».

Типові помилки (симптом → корінь проблеми → виправлення)

1) «Ми додали special і нічого не пришвидшилося.»

Симптоми: Обхід каталогів все ще повільний; HDD все ще показують навантаження випадкових читань; special показує мало читань.

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

Виправлення: Для датасетів, де це важливо, перезапишіть дані (наприклад, send/receive в новий датасет, або копіювання та swap), щоб метадані/малі блоки переалокувались у special.

2) «Special повний і тепер все здається привидним.»

Симптоми: Сплески затримок, дивні алокації, непередбачувана продуктивність; сповіщення про ємність.

Корінь проблеми: Special vdev замалий, часто в поєднанні з агресивними налаштуваннями special_small_blocks.

Виправлення: Додайте дзеркала у special (розширте клас алокації) або мігруйте дані в більший пул. Зменшіть special_small_blocks на датасетах, які в цьому не потребують.

3) «Ми використали один ‘enterprise SSD’ для special. Він впав. Тепер вчимо процедури відновлення.»

Симптоми: Пул помилково або не імпортується; відсутній special-пристрій; паніка.

Корінь проблеми: Відсутність надлишковості для класу vdev, що зберігає необхідні блоки.

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

4) «Ми встановили special_small_blocks занадто високо і випадково побудували дорогий all-SSD пул.»

Симптоми: Швидке зростання алокації special; знос SSD; HDD дивно лежать без діла; напруженість на бюджетних зустрічах.

Корінь проблеми: Поріг встановлено близько до recordsize (або навантаження пише багато дрібних блоків), тож більшість даних потрапляє в special.

Виправлення: Зменшіть поріг по датасету і, якщо потрібно перемістити існуючі дані з special, проведіть міграцію/перезапис. Моніторьте повноту special і знос SSD.

5) «Продуктивність покращилась, а потім впала під час scrub.»

Симптоми: Сплески затримок та IO wait під час scrub; таймаути додатку; special показує інтенсивні читання.

Корінь проблеми: Scrub дуже інтенсивно обходить метадані; special став гарячим шляхом і може бути недопропорційним, або розклад scrub накладається на peak.

Виправлення: Плануйте scrubs на непіковий час, регулюйте поведінку scrub де підтримується і забезпечуйте достатню IOPS та витривалість для special mirror.

6) «Ми думали, special замінює SLOG.»

Симптоми: NFS/VM синхронні записи все ще погані; навантаження з fsync незмінне.

Корінь проблеми: Special vdev націлений на метадані/малі блоки. SLOG (separate log) прискорює синхронні записи, розміщуючи ZIL.

Виправлення: Додайте відповідний SLOG-пристрій (дзеркальним для серйозних навантажень) і перевірте поведінку sync. Тримайте ролі окремими.

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

Інцидент через неправильне припущення: «Це кеш, так?»

Середня компанія використовувала ZFS пул для домашніх директорій і артефактів CI. Вони почули, що «special vdev робить метадані швидкими» і
купили один висококласний NVMe диск. Його додали як special. Продуктивність одразу покращилась: виводи каталогів перестали таймаутитись,
CI-скани стали швидшими, всі плескали в долоні.

Місяці потому NVMe почав кидати media errors. Система працювала, бо пристрій не помер одразу; він просто почав поводитись дивно.
Час від часу з’являлись checksum помилки, потім їх стало більше. Хтось відносив це до «корупції кеша» і запланував заміну «на наступне вікно технічного обслуговування».

Вікно заміни настало після того, як пристрій випав повністю. Пул не імпортувався коректно. «Акселератор метаданих» хостив потрібні метадані.
Їхні data vdev були в порядку; вони просто не могли безпечно обходити структури файлової системи без відсутніх блоків.

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

Оптимізація, що вилетіла боком: налаштування special_small_blocks «турбо»

Інша організація мала змішане навантаження: репозиторії, реєстри контейнерів і VM-образи. Вони розгорнули дзеркальний special vdev і отримали значне
покращення на задачах, важких по метаданих. Потім хтось вирішив «закінчити роботу» і встановив special_small_blocks=128K на кількох датасетах,
бо «більшість I/O все одно маленькі».

Спочатку все виглядало чудово. Графіки латентності покращились. HDD стали мало задіяні. Команда оголосила перемогу і перейшла далі.
Проблема виявилась повільною: алокація special росла швидше, ніж очікувалось, а індикатори зносу SSD піднімались у невідповідний спосіб.

Відкат був тонким: датасети мали recordsize=128K і навантаження, що часто перезаписувало файли.
Вони фактично створили SSD-шар, що хостив не лише метадані, а значну частину даних. Special став новим обмеженням ємності, потім — продуктивності,
бо він робив і метадані, і велику кількість I/O даних.

Виправлення було болючим, але чистим: вони знизили special_small_blocks до 16K для вигідних датасетів, скидали до 0 для решти,
і мігрували уражені датасети через send/receive, щоб блоки були реадресовані правильно. Це коштувало часу, але замінило повзуче лихо стабільною системою.

Нудна, але правильна практика, що врятувала день: бюджети ємності та зносу

Фінансова компанія використовувала ZFS для аналітичних логів і архівів відповідності. Вони були консервативні: дзеркальний special vdev, помірне
special_small_blocks лише на кількох «дрібнофайлових» датасетах, щотижневі scrubs і суворе правило моніторингу: алерт на 60% і 70%
використання special, плюс пороги зносу SSD.

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

Завдяки тому, що вони моніторили special окремо, вони виявили це рано. Додали ще одну пару дзеркальних special під час звичайного вікна змін і відрегулювали
збереження на одному графіку снапшотів. Ніякого дауна, ніякої драми, ніякого «чому пул офлайн».

Найвражаюче, що ніхто не писав героїчних Slack-повідомлень про це. Ось у чому суть. Операції мають бути нудними. Так купують нудність: бюджети, пороги і відмова
трактувати критичне сховище як експеримент.

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

Покроково: вирішення, чи потрібен вам special vdev

1. Охарактеризуйте навантаження: чи домінує воно обходами файлів, stat’ами, снапшотами, дрібними файлами або dedup lookup?
2. Виміряйте поведінку ARC: чи мають значення пропуски метаданих під час уповільнення?
3. Виміряйте черги пристроїв: чи HDD завантажені випадковими читаннями при низькій пропускній здатності?
4. Переконайтесь, що ви не женетесь за неправильним вузьким місцем: CPU-компресія, sync-записи або однопотокова поведінка додатку.
5. Визначте сферу: прискорення метаданих по всьому пулу проти таргетованого прискорення малих блоків по датасету.

Покроково: безпечна реалізація special vdev

1. Виберіть пристрої: дзеркальні SSD/NVMe з витривалістю, що відповідає churn метаданих.
2. Плануйте надлишковість: мінімум mirror; розгляньте політику гарячих запасних у вашому операційному контексті.
3. Додайте special vdev: перевіряйте через zpool status і zpool list -v.
4. Тримайте special_small_blocks на 0 спочатку: спочатку отримайте «тільки метадані» виграш.
5. Знову виміряйте: підтвердіть, що читання змістилися і затримка покращилась.
6. Увімкнюйте special_small_blocks вибірково: почніть з малого (16K/32K), тільки для датасетів з болем через дрібні файли.
7. Документуйте: властивості датасетів і обґрунтування в журналі змін.

Покроково: уникнення обривів ємності

1. Моніторьте алокацію special використовуючи zpool list -v.
2. Алертуйте рано: 70% — це «планувати розширення», не «панікувати».
3. Слідкуйте за зносом SSD: SMART метрики зносу і журнали помилок.
4. Будьте чесними щодо снапшотів: їхній ріст — це ріст метаданих; встановіть збереження, яке можете дозволити.
5. Майте план міграції: якщо потрібно змінити розміщення, плануйте send/receive або контрольований перезапис.

FAQ

1) Чи special vdev те саме, що L2ARC?

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

2) Чи переміщує додавання special vdev існуючі метадані автоматично?

Зазвичай — ні. Він впливає на нові алокації. Існуючі блоки залишаються, якщо ви не перезапишете/не помістите дані, щоб ZFS алокував їх заново.

3) Чи можу я використати один SSD для special vdev, якщо він «enterprise grade»?

Можете. Так само ви можете працювати в продакшні без бекапів. В обох випадках ви обираєте драму. Дзеркалюйте special vdev.

4) Яке безпечне початкове значення для special_small_blocks?

Почніть з 0 (тільки метадані). Якщо у вас є доведене навантаження з дрібними файлами, спробуйте 16K або 32K на тому датасеті і дивіться за алокацією special і зносом SSD.

5) Чим SLOG відрізняється від special vdev?

SLOG прискорює синхронні записи, хостячи ZIL intent log. Special vdev прискорює читання/запис метаданих і за бажанням малі блоки.
Вони вирішують різні проблеми і часто використовуються разом у серйозних середовищах.

6) Чи робить special vdev scrubs швидшими?

Часто покращує поведінку scrub, бо scrub інтенсивно читає метадані. Але якщо ваш special слабкий або насичений, scrub може конкурувати з продуктивними читаннями на тих самих SSD.

7) Чи допоможе special vdev з dedup?

Може допомогти, бо DDT lookup — це щось на зразок метаданих і чутливе до затримки. Але dedup все ще домінує потребою в пам’яті та поведінкою пошуку.
Special vdev не замінює достатню RAM і правильну архітектуру dedup.

8) Що буде, якщо special vdev заповниться?

Найкращий випадок: деградація продуктивності і дивні алокації в міру того, як ZFS намагається впоратися. Найгірший: помилки алокації і операційний хаос.
Ставте ємність special як ресурс першого класу з ранніми алертами і планом розширення.

9) Чи потрібен special vdev в all-NVMe пулі?

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

10) Як зрозуміти, чи моє уповільнення — «метадані» чи «дані»?

Шукайте низьку пропускну здатність з великою кількістю операцій, високі пропуски метаданих в ARC і профілі системних викликів, де домінують stat() і читання каталогів.
Потім підтвердьте, який клас vdev обслуговує читання через zpool iostat -v.

Висновок: практичні наступні кроки

Special vdev — одна з небагатьох можливостей ZFS, що може виглядати як шахрайство: раптом файлова система перестає сперечатися з фізикою під час
метаданних бур. Але це шахрайство лише якщо ви не заплатите ціну наперед: надлишковість, правильний розмір і дисципліна з special_small_blocks.

Наступні кроки, що надійно покращать реальні системи:

• Доведіть, що це метадані за допомогою даних ARC і vdev-level iostat у вікні інциденту.
• Якщо розгортаєте special — дзеркаліть його і моніторте як те, що може вивести пул з ладу — бо може.
• Почніть з тільки метаданих, потім вибірково вмикайте розміщення малих блоків там, де навантаження це виправдовує.
• Бюджетуйте ріст: снапшоти, кількість файлів та churn з часом збільшать метадані.
• Тримайте це нудним: алерти на розумних порогах, регламентовані scrubs, відстеження зносу і документовані зміни.

Якщо ви зробите це правильно, ви проводитимете менше часу, пояснюючи, чому «ls» повільний, і більше часу на ту роботу, яка підвищує вам кар’єру:
передбачувані системи, передбачувані інциденти, передбачуване відновлення.