Спеціальні малі блоки ZFS: як прискорити навантаження з дрібними файлами

Що насправді означає “спеціальні малі блоки”

У ZFS «спеціальні малі блоки» — це скорочена назва політики: зберігати блоки менші за обраний поріг на
спеціальному vdev — зазвичай SSD або NVMe — залишаючи великі дані файлів на основних vdev (часто HDD).
Це не кеш. Це не «на добраніч». Ці блоки живуть там.

Спеціальний vdev уже має завдання навіть без порогу: він може тримати метадані. Метадані включають такі речі, як
непрямі блоки, dnodes, записи директорій і інші структури, які роблять можливими операції файлової системи.
Коли ви встановлюєте special_small_blocks на датасеті, ви розширюєте це завдання: малі блоки
файлових даних також потрапляють на спеціальний vdev.

Магія не в тому, що SSD «швидший». Магія в тому, що навантаження з дрібними файлами домінуються випадковим I/O, а
випадковий I/O на HDD — це тест на механічну терпимість, у якому ви програєте. Якщо ви можете відправити ці читання на носії з низькою затримкою, весь характер навантаження змінюється: менше переміщень головки, менше простоїв IOPS і коротша черга в неправильному місці.

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

Жарт №1: уявіть, що спеціальні малі блоки дають вашим метаданим спортивний автомобіль. Просто пам’ятайте: якщо ви розіб’єте спорткар, ви не просто пропустите зустріч — ви забудете, де офіс.

Цікаві факти та контекст (чому це існує)

Ось кілька конкретних історичних і контекстних деталей, що важливі при проєктних рішеннях:

1. ZFS починалася з припущення про дорогий RAM і повільні диски. ARC був спроєктований так, щоб бути хитрим щодо кешування, оскільки «просто додати RAM» не завжди було рішенням у ранніх розгортаннях.
2. «Клас виділення для метаданих» з’явився пізніше. Ранні версії ZFS не мали чистого способу закріпити метадані на іншому типі vdev; спеціальні vdev додали явний клас для цього.
3. Продуктивність малих файлів завжди визначала репутацію файлової системи. Користувачі пробачають повільне потокове передавання частіше, ніж повільні резервні копії — але повільний ls і повільні збірки викликають негайне обурення.
4. 4K розміри секторів змінили правила гри. «Крихітні файли» все ще перетворюються на кілька метаданихних блоків, і 4K-алайновані читання означають, що ви платите мінімальний розмір I/O навіть для невеликого вмісту.
5. Copy-on-write робить схеми випадкових записів більш звичними. ZFS мусить записувати нові блоки і оновлювати покажчики; вона уникає оновлень на місці, що чудово для послідовності і сніпшотів, але може збільшити метаданіний шум.
6. NVMe не просто додав швидкість; він змінив поведінку черг. Розрив по затримці між NVMe і HDD означає, що переміщення невеликої частки I/O (метадані + малі блоки) може драматично змінити кінцеві часи відповіді.
7. «Special» — це не «cache». L2ARC — це кеш і його можна відтворити; виділення на special vdev є авторитетним. Цей один факт визначає більшість операційних рішень щодо ризику.
8. dnodes — тихий лиходій. Dnodes — це метадані на об’єкт, і вони можуть стати гарячою точкою для дерев з мільйонами файлів; розміщення dnodes на special vdev може дати величезний виграш.
9. Облік простору важливіший, ніж ви думаєте. Якщо special vdev заповниться, ZFS не «перетече» метадані назад на HDD дружнім способом; ви можете опинитися з помилками виділення і неприємними оперативними рішеннями.

Як це працює всередині (достатньо, щоб приймати виважені рішення)

The special vdev allocation class

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

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

special_small_blocks: the policy knob

special_small_blocks — це властивість на рівні датасету. Якщо встановити розмір (наприклад, 16K), то блоки даних файлів до цього розміру виділяються на спеціальному vdev.

Три операційні істини:

• Це не ретроактивно. Існуючі блоки залишаються там, де вони є, поки їх не буде перезаписано.
• Воно взаємодіє з recordsize. Якщо ваш recordsize — 128K і ваша навантаження записує багато дрібних файлів, ви все одно зберігаєте лише використану частину, але поведінка виділення і стиснення може мати значення.
• Воно може швидко збільшити споживання спеціального vdev. Датасети з дрібними файлами часто бувають «повністю з малими блоками». Це суть, але і пастка.

Dnodes, dnodesize, and “metadata that behaves like data”

ZFS зберігає метадані на файл у dnodes. Коли розширені атрибути та ACL важкі (думаємо: корпоративні файлообміни з агресивним аудитом і Windows-клієнтами), dnodes можуть роздутися. Якщо dnodes не поміщаються в «bonus buffer», ZFS може виливати метадані в окремі блоки, що збільшує читання. Налаштування як xattr=sa і dnodesize=auto можуть зменшити розтікання та підсилити вигоду від спеціального vdev.

Чому це відчувається як «турбо»

Для багатьох навантажень з дрібними файлами критичний шлях:

1. Пошук записів директорій (I/O метаданих).
2. Читання атрибутів файлу (ще метадані I/O).
3. Читання даних дрібного файлу (малі випадкові читання).

Якщо ці кроки відбуваються на HDD, ви обмежені переміщенням головки і глибиною черги. Якщо вони відбуваються на NVMe, ви обмежені CPU, рівнем потрапляння ARC і моделлю потоків додатка. Це інша проблема, і загалом краща.

Жарт №2: HDD чудово навчають терпінню. На жаль, ваш CI-пайплайн не підписувався на цей курс.

Навантаження, які виграють (і які ні)

Найкращі кандидати

Спеціальні малі блоки блищать, коли ваш робочий набір включає багато дрібних файлів і операцій, насичених метаданими:

• Дерева вихідного коду та артефакти збірки (мільйони дрібних файлів, повторні обходи, багато викликів stat).
• Шари образів контейнерів (розпаковування та багато дрібних файлів, паралельна екстракція).
• Навантаження типу Maildir (багато дрібних повідомлень як окремі файли).
• Веб-хостинг і контент CMS (тисячі дрібних PHP-файлів, плагіни, ескізи, метадані).
• Корпоративні файлові шарі з глибокими деревами (активний перегляд директорій, перевірки ACL, Windows-клієнти).
• Репозиторії резервних копій з багатьма дрібними чанками (залежно від інструменту; деякі створюють багато дрібних об’єктів).

Змішані результати

VM-образи і бази даних можуть отримати непряму вигоду, бо метадані і непрямі блоки стають швидшими, але зазвичай ці навантаження домінуються середніми-до-великих випадковими I/O та поведінкою синхронних записів. Якщо ви намагаєтеся виправити затримку бази даних, ймовірно, потрібно говорити про SLOG, recordsize, ashift і налаштування додатка в першу чергу.

Погані кандидати

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

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

The non-negotiable rule: redundancy or regret

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

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

Sizing: the part everyone underestimates

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

• Наклад метаданих для наявних та майбутніх даних.
• Площа даних дрібних файлів під вашим порогом special_small_blocks.
• Зростання сніпшотів (метадані та малі блоки можуть множитися при зміні).
• Запас для продуктивності та здоров’я алокатора.

Практична ментальна модель: якщо ви зберігаєте мільйони дрібних файлів, «дані» можуть бути маленькими, але
кількість об’єктів робить метадані значними. Дерево з 50 мільйонами файлів може бути «лише» кілька терабайт, але все одно стати метаданою-машиною.

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

Choosing a threshold

Типові пороги — 8K, 16K, 32K, інколи 64K. Правильне значення залежить від:

• Розподілу розмірів файлів у вас.
• Як швидко ви можете збільшити спеціальну ємність.
• Чи дійсно «дрібні файли» в цьому датасеті чутливі до затримки.

Починайте консервативно. Ви можете підвищити поріг пізніше; знизити його не переміщує існуючі блоки назад.

Compression and special

Стиснення змінює ефективний розмір блока, що зберігається. Якщо ви маєте compression=zstd, багато «середніх» файлів можуть стиснутися до блоків нижче вашого порогу і опинитися на special. Це іноді чудово, а іноді — сюрприз.

Device selection and endurance

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

Реалізація: покроково з реальними командами

Команди нижче припускають OpenZFS на Linux. Якщо ви на FreeBSD, концепції і більшість команд однакові,
але шляхи пристроїв і деякі інструменти відрізняються. Замініть імена пулів/датасетів і ідентифікатори пристроїв під вашу систему.

Task 1: Confirm pool topology and current health

cr0x@server:~$ sudo zpool status -v
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 0 days 02:11:32 with 0 errors on Sun Dec 22 03:15:12 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            /dev/disk/by-id/...     ONLINE       0     0     0
            /dev/disk/by-id/...     ONLINE       0     0     0
            /dev/disk/by-id/...     ONLINE       0     0     0
            /dev/disk/by-id/...     ONLINE       0     0     0
            /dev/disk/by-id/...     ONLINE       0     0     0
            /dev/disk/by-id/...     ONLINE       0     0     0

errors: No known data errors

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

Task 2: Identify candidate SSD/NVMe devices by stable IDs

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep -E 'nvme|ssd|ata' | head
lrwxrwxrwx 1 root root 13 Dec 24 09:10 nvme-SAMSUNG_MZVLB1T0HBLR-00000_S4EWNX0R123456 -> ../../nvme0n1
lrwxrwxrwx 1 root root 13 Dec 24 09:10 nvme-SAMSUNG_MZVLB1T0HBLR-00000_S4EWNX0R789012 -> ../../nvme1n1

Інтерпретація: використовуйте /dev/disk/by-id, щоб уникнути сюрпризів із перенумерацією пристроїв після перезавантажень або заміни HBA.

Task 3: Check ashift and general pool properties

cr0x@server:~$ sudo zdb -C tank | grep -E 'ashift|name'
        name: 'tank'
        ashift: 12

Інтерпретація: ashift=12 означає 4K сектора, що добре. Спеціальні vdev також повинні бути правильно вирівняні;
загалом не бажано міксувати це так, щоб створювати непотрібне підсилення записів.

Task 4: Add a mirrored special vdev (metadata class)

cr0x@server:~$ sudo zpool add tank special mirror \
  /dev/disk/by-id/nvme-SAMSUNG_MZVLB1T0HBLR-00000_S4EWNX0R123456 \
  /dev/disk/by-id/nvme-SAMSUNG_MZVLB1T0HBLR-00000_S4EWNX0R789012

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

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            ONLINE       0     0     0
          raidz2-0                                      ONLINE       0     0     0
            /dev/disk/by-id/...                         ONLINE       0     0     0
            ...
          special
            mirror-1                                    ONLINE       0     0     0
              nvme-SAMSUNG_MZVLB1T0HBLR...123456        ONLINE       0     0     0
              nvme-SAMSUNG_MZVLB1T0HBLR...789012        ONLINE       0     0     0

Інтерпретація: пул тепер має клас special. З цього моменту метадані можуть виділятися там (залежно від флагів і типу блоків). Доля пулу тепер прив’язана до цього дзеркала. Моніторьте його як слід.

Task 5: Verify special vdev allocation is recognized

cr0x@server:~$ sudo zpool list -v tank
NAME         SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank        54.5T  31.2T  23.3T        -         -    23%    57%  1.00x  ONLINE  -
  raidz2-0  54.5T  31.2T  23.3T        -         -    23%    57%
  special    1.8T   120G   1.7T        -         -     2%     6%

Інтерпретація: ви бачите окрему ємність для special. Слідкуйте за цим; «special зайнятий лише на 6%» — заспокійливе речення, яке ви хочете повторювати.

Task 6: Create a dataset for the small-file workload with sane defaults

cr0x@server:~$ sudo zfs create -o atime=off -o compression=zstd -o xattr=sa tank/work
cr0x@server:~$ sudo zfs get -o name,property,value atime,compression,xattr tank/work
NAME       PROPERTY     VALUE
tank/work  atime        off
tank/work  compression  zstd
tank/work  xattr        sa

Інтерпретація: вимкнення atime зменшує записи метаданих для навантажень з переважно читанням. xattr=sa часто зменшує розтікання xattr в окремі об’єкти для Linux-розширених атрибутів, що допомагає в бурях з дрібними файлами.

Task 7: Enable special small blocks on that dataset

cr0x@server:~$ sudo zfs set special_small_blocks=16K tank/work
cr0x@server:~$ sudo zfs get special_small_blocks tank/work
NAME       PROPERTY              VALUE   SOURCE
tank/work  special_small_blocks  16K     local

Інтерпретація: нові блоки даних файлів до 16K будуть виділятися на спеціальному vdev. Це не перепише старі дані.

Task 8: Ensure dnodes can scale with metadata-heavy workloads

cr0x@server:~$ sudo zfs set dnodesize=auto tank/work
cr0x@server:~$ sudo zfs get dnodesize tank/work
NAME       PROPERTY   VALUE  SOURCE
tank/work  dnodesize  auto   local

Інтерпретація: dnodesize=auto дозволяє більші dnodes при потребі, що може зменшити додаткові метаданіні блоки
і покращити обхід директорій та доступ до атрибутів. Це може збільшити метаданіний слід — плануйте ємність.

Task 9: Baseline small-file behavior before and after (practical micro-benchmark)

cr0x@server:~$ mkdir -p /tank/work/testtree
cr0x@server:~$ /usr/bin/time -f "elapsed=%E" bash -c 'for i in $(seq 1 200000); do echo x > /tank/work/testtree/f_$i; done'
elapsed=0:04:31

cr0x@server:~$ /usr/bin/time -f "elapsed=%E" bash -c 'find /tank/work/testtree -type f -exec stat -c %s {} \; > /dev/null'
elapsed=0:00:46

Інтерпретація: не беріть абсолютні числа занадто серйозно між системами; дивіться на відносні зміни і на те, куди зміщується час (CPU проти I/O). Також: 200k файлів достатньо, щоб показати біль, не перетворюючи файлову систему на довгостроковий науковий проєкт.

Task 10: Observe real-time I/O distribution (special vs main)

cr0x@server:~$ sudo zpool iostat -v tank 2 5
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        31.3T  23.2T    210   1800   8.3M   145M
  raidz2-0  31.2T  23.3T     40    220   7.9M    40M
  special    140G  1.6T     170   1580   420K   105M
----------  -----  -----  -----  -----  -----  -----

Інтерпретація: ви хочете бачити багато IOPS записів/метаданих на special vdev замість безжального нарощування HDD vdev. Пропускна здатність на special може виглядати «маленькою», тоді як операцій багато — це нормально.

Task 11: Check dataset properties that commonly interact with small blocks

cr0x@server:~$ sudo zfs get -o name,property,value recordsize,primarycache,logbias,sync tank/work
NAME       PROPERTY      VALUE
tank/work  recordsize    128K
tank/work  primarycache  all
tank/work  logbias       latency
tank/work  sync          standard

Інтерпретація: для дерев дрібних файлів recordsize зазвичай не ваш важіль (воно більше важить для великих файлів і баз даних). Але primarycache можна налаштувати, якщо ARC зажатий, а sync може вбити продуктивність, якщо ви ненавмисно робите синхронні записи.

Task 12: Find whether special is filling up and why

cr0x@server:~$ sudo zfs list -o name,used,available,usedbysnapshots,usedbydataset,usedbychildren -r tank/work
NAME                 USED  AVAIL  USEDSNAP  USEDDS  USEDCHILD
tank/work           1.02T   9.1T      120G    900G         -

cr0x@server:~$ sudo zpool list -v tank | sed -n '1,5p'
NAME         SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank        54.5T  32.2T  22.3T        -         -    24%    59%  1.00x  ONLINE  -
  raidz2-0  54.5T  31.6T  22.9T        -         -    24%    58%
  special    1.8T   600G   1.2T        -         -     9%    33%

Інтерпретація: якщо використання special зростає непропорційно порівняно з використанням датасету, у вас може бути датасет з високим циклом змін, просування через стиснення або сніпшоти, що закріплюють блоки. Відстежуйте used-by-snapshots уважно.

Task 13: Force rewriting old blocks to migrate to special (controlled)

Оскільки special_small_blocks не є ретроактивним, можливо, ви захочете переписати дані на місці. Ви можете це зробити,
копіюючи всередині датасету (що виділяє нові блоки за поточною політикою) або використовуючи send/receive до нового датасету.

cr0x@server:~$ sudo zfs snapshot tank/work@rewrite-start
cr0x@server:~$ sudo rsync -aHAX --delete /tank/work/ /tank/work_rewritten/

Інтерпретація: це інтенсивно використовує I/O. Робіть це з запобіжними механізмами (обмеження швидкості, вікна поза піком) і переконайтеся, що special має ємність, щоб вмістити мігрувані блоки.

Task 14: Verify special class is actually being used for small blocks

cr0x@server:~$ sudo zfs get -r special_small_blocks tank/work
NAME       PROPERTY              VALUE  SOURCE
tank/work  special_small_blocks  16K    local

cr0x@server:~$ sudo zdb -dddd tank/work | head -n 20
Dataset tank/work [ZPL], ID 123, cr_txg 45678, 1.02T, 720000 objects

    Object  lvl   iblk   dblk  dsize  dnsize  lsize   %full  type
       123    1   128K    16K    16K     512   16K    100%  ZFS plain file
       124    1   128K    16K    16K     512   12K     75%  ZFS plain file

Інтерпретація: вивід zdb змінюється за версіями, але ви шукаєте ознаки, що блоки даних малі й виділяються за поточною політикою. Для глибшої перевірки корелюйте з zpool iostat -v під час піків навантаження і дивіться, як зростають операції на special.

Експлуатація: моніторинг, планування ємності та оновлення

What you monitor changes when special exists

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

• Вільне місце на основних vdev (класична метрика).
• Вільне місце на special vdev (нова скеля).

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

Three corporate-world mini-stories

Mini-story 1: The incident caused by a wrong assumption

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

Неправильне припущення було тонким: «special — лише метадані; він не виросте значно». Вони оцінили дзеркальний NVMe special клас, виходячи з правила великого пальця з давнішого розгортання тільки для метаданих. Потім встановили special_small_blocks=64K, щоб «бути в безпеці», бо багато файлів були менші за 50KB.

Через два місяці special vdev ферми збірок був на неприємному рівні зайнятості. Система почала видавати попередження про виділення та періодичні затримки. Розробники описували це як «схоже, що сховище має панічні атаки», що несправедливо, але не цілком неправда.

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

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

Mini-story 2: The optimization that backfired

Команда корпоративних файлових сервісів спробувала «оптимізувати все» в одному вікні змін: додано special vdev, поріг встановлено на 32K, стиснення змінено з lz4 на zstd, і atime змінено — плюс масова міграція даних, щоб переписати старі блоки на special.

Відкат не був у тому, що zstd поганий або special ризиковий. Це була комбінація регуляторів і часу. Міграція переписала величезні обсяги дрібних даних і метаданих. Стиснення зменшило деякі блоки нижче порога 32K, що означало, що набагато більше даних опинилося на special, ніж передбачалося. Утримання сніпшотів прив’язувало додаткові блоки. Підсилення записів спеціального дзеркала зросло.

Симптом у продакшні був «випадкова повільність». Не повний збій — гірше. Мікс спайків затримки, довгих виводів директорій і скарг від деяких користувачів у будь-який момент. Моніторинг показував NVMe пристрої з високою затримкою під час сплесків, в той час як HDD vdev виглядали майже не задіяними.

Відновлення вимагало операційної скромності: зупинити міграцію переписування, відкотити найбільш агресивні пороги на найактивніших датасетах і перезапустити міграцію пізніше меншими партіями з явними обмеженнями I/O. Вони також впровадили SLO по затримці запису для special пристроїв. Це не гарна метрика; але різниця між «ми знаємо, що воно хворе» і «ми дізнаємося від віце-президента».

Mini-story 3: The boring but correct practice that saved the day

Інша команда керувала артефактним сховищем на ZFS для внутрішніх релізів. Вони спочатку використовували special vdev лише для метаданих і увімкнули special_small_blocks лише для одного датасету, який використовувався для індексів і маніфестів. Нічого героїчного: дзеркало корпоративних SSD, консервативний поріг (8K) і агресивне оповіщення по використанню special.

Через шість місяців один SSD почав видавати помилки носія. Пул став деґрадованим, але нічого більшого не сталося — ніякої паніки, ніякого хаосу. У них був рукопис: замінити пристрій, resilver, перевірити. Вони практикували це в стенді з тією ж топологією. (Так, стенд. Річ, яку всі заявляють, що мають, і яку ніхто не фінансує.)

Справжнє порятунок прийшло від ще менш захопливої речі: у них були заплановані scrubs і вони переглядали звіти scrub. Кількість помилок диска повільно зростала протягом тижнів, і вони замінили диск до того, як це стало 3 ранку pager. Resilver пройшов швидко, бо special було дзеркальним, маленьким і здоровим.

Урок не в «купіть кращі SSD». Урок в «ставтеся до special vdev як до першокласного ресурсу». Якщо метадані пулу живуть там, ваша експлуатаційна зрілість має жити там теж.

Практичні операційні метрики

Речі, за якими я навчився стежити у реальних середовищах:

• Ємність special vdev (абсолютна і тенденція). Алерти повинні спрацьовувати рано.
• Затримка special vdev (читання і запис) під час відомих піків навантаження.
• Фрагментація пулу і чи змінюється поведінка алокатора після змін політик.
• Утримання сніпшотів і датасети з високим циклом змін, які прив’язують блоки special.
• Тиск ARC, бо кешування метаданих змінює патерни попадань/промахів.

Upgrades and lifecycle: plan the “how do we add more later?”

Ви можете додавати додаткові дзеркальні special vdev для розширення спеціальної ємності (як додати ще одне дзеркало до класу special). Ви не можете легко видалити special vdev з пулу у більшості практичних виробничих налаштувань. Це двері в один бік для багатьох операторів.

Тому ваш проєкт повинен передбачати зростання. Якщо ви думаєте «нам ніколи не знадобиться більше 2TB special», ви, ймовірно, скоро дізнаєтеся щось про розподіл розмірів файлів у вас.

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

Коли хтось каже «дрібні файли повільні» або «git checkout повзе», ви можете витратити день на теорії. Ось практична трирівнева тріаж-методика, яка швидко знаходить вузьке місце.

First: confirm the bottleneck is storage and not the client

1. Перевірте обмеження на стороні клієнта: завантаження CPU, однопоточна екстракція, антивірусний сканер або затримка мережі.
2. На сервері стежте за навантаженням системи і I/O wait.

cr0x@server:~$ uptime
 09:41:22 up 102 days,  3:12,  5 users,  load average: 12.11, 11.90, 10.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
 8  2      0 812344  91232 9023112   0    0   420  1800 3200 7000 12  6 55 27  0

Інтерпретація: високий wa підказує про затримку з боку сховища. Це не доказ, але сильний натяк.

Second: identify whether special is helping or hurting

1. Перевірте стан і ємність special.
2. Побачте IOPS і затримки по vdev під час повільної операції.

cr0x@server:~$ sudo zpool status tank | sed -n '1,25p'
  pool: tank
 state: ONLINE
config:
        NAME          STATE     READ WRITE CKSUM
        tank          ONLINE       0     0     0
          raidz2-0    ONLINE       0     0     0
          special
            mirror-1  ONLINE       0     0     0

cr0x@server:~$ sudo zpool list -v tank | tail -n 3
  raidz2-0  54.5T  31.6T  22.9T        -         -    24%    58%
  special    1.8T   1.4T   420G        -         -    18%    77%

Інтерпретація: special на 77% — це червоний прапор. Навіть якщо сьогодні продуктивність прийнятна, алокатор і майбутнє зростання не будуть ввічливими.

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

Інтерпретація: якщо special має величезні черги/операції і зростаючу затримку, тоді як HDD практично бездіяльні, special — ваш вузький горлечко (занадто малий, занадто повільний або йому доручено занадто багато).

Third: validate dataset policy and workload reality

1. Підтвердіть, що датасет має очікувані властивості.
2. Перевірте, чи синхронні записи, сніпшоти або стиснення змінили поведінку.
3. Шукайте сюрпризи «не ретроактивно»: старі блоки все ще на HDD.

cr0x@server:~$ sudo zfs get -o name,property,value special_small_blocks,compression,atime,xattr,dnodesize -r tank/work
NAME       PROPERTY              VALUE
tank/work  special_small_blocks  16K
tank/work  compression           zstd
tank/work  atime                 off
tank/work  xattr                 sa
tank/work  dnodesize             auto

Інтерпретація: якщо датасет не має встановленої властивості, ви не використовуєте функцію. Якщо має, але продуктивність не змінилася, ви можете бути обмежені синхронними записами, CPU або дані не були перезаписані.

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

Mistake 1: Adding a non-redundant special vdev

Симптом: Все працює, поки не перестане; коли пристрій виходить з ладу, пул може стати відновити неможливо.

Виправлення: Завжди робіть дзеркало (або RAIDZ) для special vdev. Якщо ви вже зробили це неправильно, вважайте це терміновим технічним боргом і плануйте міграцію до правильно спроєктованого пулу. «Виправляти на місці» — не те захоплення, яке вам потрібне.

Mistake 2: Setting special_small_blocks too high “just in case”

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

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

Mistake 3: Forgetting that compression can move more data onto special

Симптом: Після увімкнення zstd або підвищення рівня стиснення використання special пришвидшується, особливо для «середніх» файлів, які добре стискаються.

Виправлення: Переоцініть поріг і відбір датасетів. Розгляньте менший поріг (8K/16K) для стиснутих датасетів, які містять багато помірно великих, але добре стискуваних файлів.

Mistake 4: No alerting on special vdev usage

Симптом: Пул має багато вільного місця, але операції відмовляються або затримки зростають; команда в розгубленості, бо «пул лише на 60% заповнений».

Виправлення: Налаштуйте алерти на використання класу special окремо, з раннім порогом (наприклад, попередження на 60–70%, критично на 80–85%, налаштовано за темпом зростання і ризиковістю).

Mistake 5: Assuming enabling the property makes existing data faster

Симптом: Ви встановили special_small_blocks, користувачі повідомляють про відсутність покращення, і хтось каже «воно не працює.»

Виправлення: Поясніть і сплануйте переписування: перемістіть дані до нового датасету через send/receive або перепишіть файли на місці (обережно). Перевірте з zpool iostat -v під час роботи навантаження.

Mistake 6: Overloading special with too many datasets at once

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

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

Mistake 7: Ignoring snapshots and churn

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

Виправлення: Аудитуйте утримання сніпшотів і датасети з високою циклічністю змін. Налаштуйте політику сніпшотів або перемістіть високо-циклічні навантаження в окремі пули/датасети з індивідуальними правилами збереження.

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

Checklist A: Decide whether special small blocks is the right tool

1. Підтвердіть, що навантаження домінує метаданими/дрібними файлами (повільний find, повільний stat, повільне untar).
2. Підтвердіть, що вузьке місце — затримка/IOPS сховища, а не мережа чи CPU.
3. Виміряйте розподіл розмірів файлів і кількість об’єктів (приблизно достатньо, але виміряйте).
4. Вирішіть, які датасети дійсно це потребують (не вмикайте масово).

Checklist B: Design the special vdev safely

1. Виберіть резервну топологію (мінімум дзеркало).
2. Виберіть пристрої з відповідною витривалістю і стабільною поведінкою при відключенні живлення для вашого середовища.
3. Оцініть ємність для метаданих + очікуваних малих блоків + наклад сніпшотів + зростання.
4. Плануйте розширення: залиште відсіки/слоти або PCIe-ланки, і бюджет на додавання ще одного дзеркала пізніше.
5. Створіть алерти спеціально для використання special та помилок пристрою.

Checklist C: Rollout plan that won’t wake you up at 3 a.m.

1. Додайте special vdev і перевірте здоров’я пулу.
2. Увімкніть на одному датасеті спочатку з консервативним порогом (8K або 16K).
3. Виміряйте до/після на реальних операціях (checkout, untar, індексація, сканування директорій).
4. Переписуйте дані тільки якщо потрібно, і обмежуйте міграції.
5. Розширюйте сферу датасетом за датасетом, спостерігаючи за трендом використання special.

Checklist D: Ongoing operations

1. Щотижневий огляд тренду використання special та зростання сніпшотів.
2. Заплановані scrubs і перегляд їхніх результатів.
3. Перевірки стану пристроїв (SMART/NVMe логи) інтегровані з порогами оповіщення.
4. Квартальна валідація: протестуйте процедуру заміни пристрою і resilver (у безпечному середовищі).

Extra practical tasks (ops-focused)

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

Task 15: Check ARC stats (metadata caching pressure)

cr0x@server:~$ sudo arcstat 1 5
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
09:52:01   812   102     12    48   47    40   39    14   14   96G   110G

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

Task 16: Quick check of mountpoint and dataset mapping (avoid tuning the wrong dataset)

cr0x@server:~$ mount | grep tank
tank/work on /tank/work type zfs (rw,xattr,noacl)

cr0x@server:~$ sudo zfs list -o name,mountpoint -r tank | grep -E '^tank/work|/tank/work'
tank/work  /tank/work

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

Task 17: Check snapshot count and retention pressure

cr0x@server:~$ sudo zfs list -t snapshot -o name,used,creation -S creation | head
NAME                      USED  CREATION
tank/work@daily-2025-12-24 1.2G  Wed Dec 24 02:00 2025
tank/work@daily-2025-12-23 1.1G  Tue Dec 23 02:00 2025
tank/work@daily-2025-12-22 1.3G  Mon Dec 22 02:00 2025

Інтерпретація: сніпшоти не безкоштовні. На датасетах з високим циклом змін сніпшоти закріплюють старі малі блоки і метадані.

FAQ

1) Is a special vdev the same thing as L2ARC?

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

2) Do I need special small blocks if I already have lots of RAM for ARC?

Можливо. ARC допомагає, якщо ваш робочий набір вміщується і патерн доступу дружній до кешу. Але навантаження з дрібними файлами часто перевищують ARC або включають холодні сканування (думаємо: CI-ранери, що стартують з нуля). Special vdev зменшує «штраф за промах», роблячи так, щоб промахи потрапляли на SSD/NVMe замість HDD.

3) What’s a good starting value for special_small_blocks?

8K або 16K — розумна відправна точка для багатьох середовищ. Якщо ви стрибнете до 64K, ви погоджуєтеся зберігати багато реальних даних на special. Це може бути правильно, але це рішення має бути обґрунтоване розрахунками ємності, а не відчуттями.

4) Can I enable it on the whole pool at once?

Технічно ви можете встановити його на датасетах широко, але з операційної точки зору не варто. Впроваджуйте по датасету, вимірюйте і стежте за трендом використання special. Special — це спільний ресурс; один шумний датасет може його вжити.

5) Why didn’t performance improve after I set the property?

Поширені причини: ваші дані не були переписані (властивість не ретроактивна), ваш вузький горлечко — синхронні записи або мережа, навантаження CPU-залежне, або special насичений/повільний. Перевірте з zpool iostat -v під час навантаження.

6) What happens if the special vdev fills up?

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

7) Can I remove a special vdev later?

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

8) Should I also move metadata to SSD by using a “metadata-only” pool layout?

Special vdev — це саме така концепція, інтегрована в класи виділення ZFS. Якщо ваш пул повністю на SSD, special vdev навряд чи допоможе багато. Якщо ваш пул на HDD, special може бути великим виграшем без переміщення всіх даних на SSD.

9) Does xattr=sa matter for this topic?

Часто так. Коли xattr живуть в області системних атрибутів, ZFS може уникати окремих об’єктів xattr для багатьох випадків, зменшуючи I/O метаданих. Це робить сканування директорій і навантаження, насичені атрибутами, швидшими і може зменшити тиск на ємність та IOPS special.

10) Should I use RAIDZ for the special vdev instead of mirrors?

Дзеркала поширені для special, бо вони зберігають низьку затримку і просту поведінку відновлення. RAIDZ може бути життєздатним для економії ємності, але ви повинні бути комфортні з підсиленням записів і динамікою відновлення. Для більшості навантажень, чутливих до затримки дрібних файлів, дзеркальні special vdev — типовий безпечний вибір.

Висновок

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

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

Починайте консервативно, вимірюйте чесно і розширюйте обережно. Так ви отримаєте турбо без згорілого головного блоку.