Розмір спеціального VDEV у ZFS: яким має бути (щоб не шкодувати)

Що насправді робить спеціальний vdev

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

Що потрапляє на спеціальний vdev?

• Метадані: непрямі блоки, dnodes, структури каталогів, вказівники блоків, spacemap-і та інша «облікова» інформація, необхідна для пошуку й управління даними.
• Опційно, дрібні блоки, коли на датасеті або zvol встановлено special_small_blocks.

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

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

Жарт №1: спеціальний vdev як ящик для дрібниць — якщо зробити його занадто малим, туди все одно все поміститься, просто ящик перестане зачинятися.

Метадані маленькі… поки не стануть великими

Люди недооцінюють метадані, бо уявляють собі «імена файлів і часові мітки».
Метадані ZFS включають структури, які забезпечують copy-on-write, сніпшоти, контрольні суми, стиснення й дерева вказівників блоків.
Більше блоків і більша фрагментація — більше метаданих. Багато дрібних файлів — більше метаданих. Багато сніпшотів — більше метаданих.

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

Факти й історичний контекст (щоб поведінка була зрозумілою)

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

1. Класи розподілу special у ZFS з’явилися відносно пізно порівняно з основними функціями ZFS; ранній ZFS більше покладався на «всі vdev рівні» макети,
   плюс L2ARC/SLOG для формування продуктивності.
2. Ввід/вивід метаданих часто більш випадковий, ніж вводи даних. ZFS може стримити великі послідовні читання, але доступ до метаданих зазвичай стрибає по дисковому дереву.
3. Copy-on-write множить роботу з метаданими. Кожен новий запис оновлює вказівники блоків вгору по дереву, а сніпшоти зберігають старі вказівники.
4. dnodes стали більшими з часом. Функції на кшталт dnodesize=auto і «товсті dnodes» існують, бо упаковка більше атрибутів у dnode зменшує додаткові вводи/виводи,
   але це також змінює слід метаданих і макет.
5. Відмова special vdev може бути катастрофічною, якщо він зберігає метадані, необхідні для збору пулу. Це не теоретично — це наслідок дизайну.
6. Розрив у затримках SSD продовжує зростати. Сучасні NVMe можуть обробляти випадкові читання за десятки мікросекунд; HDD — у мілісекундах.
   100× різниця на навантаженні, насиченому метаданими, — не рідкість.
7. Стиснення й дрібні записи змінюють економіку. Коли пул записує багато дрібних стиснутих блоків, метадані й «гарячість дрібних блоків»
   починають виглядати схожими з точки зору I/O.
8. Сніпшоти збільшують метадані. Кожен сніпшот зберігає старі шляхи вказівників блоків; видалення перетворюється на управління deadlist, а не на негайне звільнення.
9. Розширити пул — легко; виправити special vdev — ні. Ви можете додати vdev для збільшення ємності, але у більшості продакшн-систем не можна просто видалити спеціальний vdev і безболісно піти.

Перефразована ідея від Werner Vogels (CTO Amazon): «Усе постійно ламається — проектуйте на випадки відмов, а не на найкращу поведінку».
Підбір розміру special vdev — саме це: проектуйте під відмови, а не під перфоманс дня нуль.

Принципи підбору розміру, які не застаріють

Принцип 1: Визначте, яку проблему ви вирішуєте

Є дві легітимні причини додати спеціальний vdev:

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

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

Принцип 2: «Це тільки метадані» — шлях до того, щоб сторінки пам’яті заповнилися

Недостатній розмір special vdev призводить до парадоксального результату: ZFS намагається розміщувати метадані/дрібні блоки там, він заповнюється, розподіли стають обмеженими,
і раптом те, що додали для продуктивності, стає вузьким місцем і інколи фактором ризику.

Принцип 3: Дзеркала для спеціальних vdev у продакшні

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

Принцип 4: Плануйте зростання та чурн, а не сирий об’єм

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

Принцип 5: Уникайте патерну «один крихітний special vdev на все»

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

Жарт №2: інженери зберігання не вірять у магію — крім випадку, коли «тимчасовий» датасет живе на special vdev три роки.

Математика підбору розміру, яку можна захистити в рев’ю змін

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

Крок 1: Визначте, чи включені дрібні блоки

Якщо ви не встановлюватимете special_small_blocks, ви головним чином підбираєте місце під метадані.
Якщо ви встановите його (поширені значення: 8K, 16K, 32K), потрібно бюджетувати й дрібні блоки даних.

Крок 2: Використайте емпіричні правила (потім перевірте)

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

• Тільки метадані: почніть з 0.5%–2% від сирої ємності пулу для загальних файлових навантажень.
  Якщо у вас багато дрібних файлів, багато сніпшотів або сильний чурн — орієнтуйтеся вище.
• Метадані + дрібні блоки: почніть з 5%–15% залежно від порогу дрібних блоків і робочого навантаження.
  Образи VM з блоками 8K–16K можуть швидко спожити ємність special.

Діапазон підбору — не невизначеність; він відображає, що пул із 10 мільйонами 4K файлів поводиться інакше, ніж пул із 20 TB медіафайлів.

Крок 3: Перетворіть правило пальця в жорстке число

Приклад: у вас 200 TB сирого HDD пулу.

• Тільки метадані при 1%: 2 TB special.
• Метадані + дрібні блоки при 10%: 20 TB special (тепер ви будуєте рівень, а не прикрасу).

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

Крок 4: Додайте буфер «не загнати себе в кут»

Заповненість special vdev викликає оперативний страх, бо може обмежувати розміщення метаданих.
Ставтеся до нього як до файлової системи журналу: не експлуатуйте її на 95% і вважайте це перемогою.

Розумна політика:

• Цільове стійке використання: 50–70%
• Попередження на: 75%
• Сигнал тривоги на: 85%

Крок 5: Урахуйте накладні витрати на надлишковість special vdev

Дзеркальний special vdev зменшує корисну ємність удвічі. Два 3.84 TB NVMe дають вам ~3.84 TB корисної (мінус slop/накладні).
Якщо ваш розрахунок каже «треба 2 TB», не купуйте «два по 1.92 TB» і сподівайтеся. Купуйте більші. Витривалість SSD і write amplification реальні.

Крок 6: Розгляньте витривалість (DWPD), якщо дрібні блоки на special

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

Підбір special vdev — це також рішення про ризик

Недостатній розмір означає:

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

Надмірний розмір означає:

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

Оберіть свій біль.

Підбір під навантаження (VM, файлові сервери, бекап, схожі на об’єкти)

Загальний файловий сервер (домашні каталоги, спільне інженерне зберігання)

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

Рекомендації щодо розміру:

• Почніть з 1–2% сирої ємності для тільки метаданих.
• Якщо очікуються мільйони дрібних файлів, рухайтеся до 2–4%.
• Тримайте special_small_blocks вимкненим, якщо ви не можете обґрунтувати його по спостереженнях I/O.

Зберігання для VM (zvol, бекенд гіпервізора)

VM-навантаження — це місце, де люди стають жадібними й вмикають special_small_blocks.
Це може працювати дуже добре, бо багато I/O у VM — дрібні випадкові читання/записи.
Але це може й «з’їсти» ваш special vdev, бо поріг — як пилосос: йому байдуже, чи блок «важливий», він лише дивиться на розмір.

Рекомендації щодо розміру:

• Тільки метадані: усе ще корисно, але менш драматично.
• Метадані + дрібні блоки: плануйте 8–15% сирої ємності залежно від volblocksize і профілю I/O.
• Розгляньте окремі пули для критичних за латентністю VM замість перевантаження загального пулу.

Цілі для бекапу (великі послідовні записи, інколи дедуп)

Репозиторії бекапів зазвичай — це робочі навантаження з великими блоками і дружні до стрімів.
Прискорення метаданих допомагає для управління сніпшотами і операцій з каталогами, але не завжди є безперечним переможцем.

• Тільки метадані special vdev: помірний розмір (0.5–1.5%) зазвичай достатній.
• Дрібні блоки: часто непотрібні; уникайте, якщо не виміряли реальної проблеми з випадковим I/O.

Макети «під об’єкт» (мільйони дрібних об’єктів, багато переліків)

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

• Плануйте 2–5% тільки для метаданих, залежно від розподілу розмірів об’єктів.
• Слідкуйте за політикою сніпшотів; об’єктні сховища плюс сніпшоти можуть множити утримання метаданих.

Проєктні рішення: дзеркала, RAIDZ, ashift, надлишковість і чому варто бути нудним

Задзеркалте — і спокійний сон

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

Виберіть розумний ashift

Використовуйте ashift=12 для більшості сучасних SSD і HDD; це вирівнює на 4K сектори.
Неправильний ashift може витрачати простір або знижувати продуктивність.
Зазвичай ви не можете змінити ashift після створення vdev без перебудови.

Не змішуйте сумнівні SSD з критичними ролями

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

Очікуйте: special vdev покращує латентність, не пропускну здатність

Послідовна пропускна здатність може майже не змінитися.
Змінюється «досвід дрібних випадкових» операцій: запити метаданих, читання дрібних блоків і ланцюжок вказівників, що шукає дані.
Це робота по латентності, тому відчувається як «усе швидше», а не «ми подвоїли GB/s».

Розумійте, що відбувається, коли special vdev заповнюється

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

• продуктивність погіршується (метадані потрапляють на повільні 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
            sde                     ONLINE       0     0     0
            sdf                     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

Що означає вивід: У вас є клас special, що складається з дзеркальної пари NVMe. Добре.
Якщо special vdev — один диск, це ризик, який варто переглянути негайно.

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

Завдання 2: Швидко перевірити тиск на ємність special vdev

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank  120T   48T   256K   /tank

Що означає вивід: Простір пулу — не те саме, що простір special vdev. Ця команда прямо не показує використання special.
Вона повідомляє, чи загальна заповненість пулу може сприяти фрагментації й стресу розподілів.

Рішення: Якщо пул сам по собі понад ~80% заповнений, очікуйте гіршої поведінки розподілів і вважайте підбір special більш терміновим.

Завдання 3: Показати розподіл по vdev, включно зі special

cr0x@server:~$ zpool list -v tank
NAME         SIZE   ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH
tank        200T    152T    48T        -         -    38%    76%  1.00x  ONLINE
  raidz2-0  200T    148T    52T        -         -    39%    74%      -  ONLINE
  special  3.50T   3.10T   410G       -         -    52%    88%      -  ONLINE

Що означає вивід: Special vdev на 88% заповнений. Це зона небезпеки. Фрагментація теж висока.

Рішення: Плануйте розширення special зараз. Не чекайте на 95%. Ваш запас уже зник.

Завдання 4: Підтвердити, чи дрібні блоки направляються на special

cr0x@server:~$ zfs get -r special_small_blocks tank
NAME            PROPERTY              VALUE                  SOURCE
tank            special_small_blocks  0                      default
tank/vmstore    special_small_blocks  16K                    local
tank/home       special_small_blocks  0                      inherited from tank

Що означає вивід: Лише tank/vmstore направляє блоки ≤16K на special. Цей датасет, ймовірно, драйвер росту.

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

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

cr0x@server:~$ zfs list -t snapshot -o name,used -S used | head
NAME                               USED
tank/vmstore@hourly-2025-12-26     2.3T
tank/vmstore@hourly-2025-12-25     2.1T
tank/home@daily-2025-12-25         320G
tank/vmstore@hourly-2025-12-24     1.9T

Що означає вивід: Багато сніпшотів з великим «used» свідчить, що утримання збереженого стану зберігає старі дерева блоків.
Робота зі метаданими та spacemap зростає зі збільшенням кількості і чурну сніпшотів.

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

Завдання 6: Виявити шаблони датасетів, що створюють метадані-шторм (багато дрібних файлів)

cr0x@server:~$ zfs get -r recordsize,compression,atime,xattr tank/home
NAME       PROPERTY     VALUE     SOURCE
tank/home  recordsize   128K      default
tank/home  compression  lz4       local
tank/home  atime        off       local
tank/home  xattr        sa        local

Що означає вивід: Гідні дефолти. xattr=sa може зменшити додаткові I/O, зберігаючи xattr у dnode (де можливо).
Це може змінити шаблони метаданих, часто на краще, але все ще відноситься до «сфери метаданих».

Рішення: Тримайте ці налаштування консистентними; уникайте випадкових змін по датасетах, якщо не можете їх обґрунтувати.

Завдання 7: Перевірити, чи увімкнено dedup (розмір special змінюється радикально)

cr0x@server:~$ zpool get dedup tank
NAME  PROPERTY  VALUE  SOURCE
tank  dedup     off    default

Що означає вивід: Dedup вимкнено. Добре; таблиці dedup можуть бути величезними і суттєво вплинути на розрахунок розміру/витривалості.

Рішення: Якщо dedup увімкнено, перегляньте розмір special з максимальною обережністю; може знадобитися набагато більше SSD і RAM.

Завдання 8: Перевірити, чи метадані справді потрапляють на special (iostat по vdev)

cr0x@server:~$ zpool iostat -v tank 1 5
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank         152T    48T  1.20K  3.80K   95M  210M
  raidz2-0   148T    52T    200  1.10K   70M  180M
    sda         -      -     30    180   11M   30M
    sdb         -      -     28    175   10M   30M
    sdc         -      -     32    185   12M   32M
    sdd         -      -     33    190   12M   32M
    sde         -      -     35    185   12M   31M
    sdf         -      -     42    185   13M   31M
  special   3.10T   410G  1.00K  2.70K   25M   30M
    mirror-1     -      -  1.00K  2.70K   25M   30M
      nvme0n1    -      -    520  1.40K   12M   15M
      nvme1n1    -      -    480  1.30K   13M   15M

Що означає вивід: Special виконує більшість операцій (IOPS), навіть якщо пропускна здатність помірна. Це типово: метадані потребують IOPS, а не пропускної здатності.

Рішення: Якщо special насичений по IOPS (високий await на NVMe, черги), можливо, потрібна ширша special або швидші SSD — не лише більше ємності.

Завдання 9: Перевірити підтримку TRIM і чи ввімкнено її (впливає на довговічність і продуктивність SSD)

cr0x@server:~$ zpool get autotrim tank
NAME  PROPERTY  VALUE     SOURCE
tank  autotrim  on        local

Що означає вивід: Autotrim увімкнено. Це допомагає SSD підтримувати продуктивність і зменшує write amplification у багатьох випадках.

Рішення: Якщо autotrim вимкнено на SSD-backed special, розгляньте його вмикнення (після перевірки стабільності trim на вашій платформі).

Завдання 10: Переконатися в здоров’ї пристроїв special на рівні диска (SMART)

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | egrep "Critical Warning|Percentage Used|Media and Data Integrity Errors|Data Units Written"
Critical Warning:                   0x00
Percentage Used:                    18%
Media and Data Integrity Errors:    0
Data Units Written:                 62,114,928

Що означає вивід: Жодних критичних попереджень, 18% витривалості використано, немає помилок носія. Добре.

Рішення: Якщо Percentage Used високий або з’являються помилки носія, плануйте заміну превентивно — спеціальні vdev не місце для очікування.

Завдання 11: Оцінити, скільки простору прив’язано до датасетів, насичених метаданими (грубий індикатор)

cr0x@server:~$ zfs list -o name,used,logicalused,compressratio -S used tank | head
NAME         USED  LOGICALUSED  COMPRESSRATIO
tank/vmstore 78T   110T        1.41x
tank/home    22T   26T         1.18x
tank/backup  18T   19T         1.05x

Що означає вивід: VM store домінує і стискається, що часто корелює з дрібнішими блоками на диску і підвищеною активністю метаданих.

Рішення: Розглядайте tank/vmstore як основний драйвер підбору розміру special і планування витривалості.

Завдання 12: Перевірити, чи ваш special vdev використовується для звичайних даних через налаштування дрібних блоків

cr0x@server:~$ zdb -bbbbb tank/vmstore | head -n 30
Dataset tank/vmstore [ZPL], ID 54, cr_txg 12345, 4.20T, 10.2M objects
  bpobj: 0x0000000000000000
  flags: 
  dnode flags: USED_BYTES USERUSED_ACCOUNTED USEROBJUSED_ACCOUNTED
  features: 
    org.openzfs:spacemap_histogram
    org.openzfs:allocation_classes
...

Що означає вивід: Наявність org.openzfs:allocation_classes вказує, що класи розподілу використовуються.
Це не кількісно вимірює використання, але підтверджує, що пул підтримує набір функцій.

Рішення: Якщо ви не бачите функцій allocation class і думали, що маєте special vdev, ви або на старішому стеку, або в іншій реалізації.
Скоригуйте очікування і підтвердіть за допомогою zpool status.

Завдання 13: Виявити, чи ви поруч з «урвищем заповнення special»

cr0x@server:~$ zpool list -Ho name,cap,frag tank
tank	76%	38%

Що означає вивід: Загальний пул 76% заповнений і 38% фрагментований. Фрагментація збільшують роботу з метаданими і накладні на розподіл.

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

Завдання 14: Додати новий дзеркальний special vdev (розширення ємності sane way)

cr0x@server:~$ sudo zpool add tank special mirror /dev/nvme2n1 /dev/nvme3n1

Що означає вивід: Це додає ще один дзеркальний special vdev до пулу, збільшуючи ємність special і IOPS.
Існуючі метадані автоматично не мігрують, але нові алокації можуть використовувати доданий простір залежно від поведінки й конфігурації.

Рішення: Якщо special понад 75–80%, розширення — це продакшн-зміна, яку краще зробити раніше, ніж пізніше.
Перевірте модель пристрою/прошивку й наслідки ashift перед підтвердженням.

Завдання 15: Підтвердити, що пул тепер показує додатковий special vdev

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
            sde                     ONLINE       0     0     0
            sdf                     ONLINE       0     0     0
          special
            mirror-1                ONLINE       0     0     0
              nvme0n1               ONLINE       0     0     0
              nvme1n1               ONLINE       0     0     0
            mirror-2                ONLINE       0     0     0
              nvme2n1               ONLINE       0     0     0
              nvme3n1               ONLINE       0     0     0

errors: No known data errors

Що означає вивід: Існують два дзеркальні special vdev. Клас special тепер ширший і більший.

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

Завдання 16: Перевірити, які датасети можуть бути кандидатами на відключення розміщення дрібних блоків (контроль ризику)

cr0x@server:~$ zfs get -r -s local special_small_blocks tank | grep -v "VALUE *0"
tank/vmstore  special_small_blocks  16K  local

Що означає вивід: Лише один датасет має локально встановлене значення.

Рішення: Якщо ємність special — обмеження, розгляньте зниження порогу (наприклад, 16K → 8K) або вимкнення на менш критичних датасетах.
Не змінюйте це без тестування; спочатку виміряйте вплив на латентність.

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

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

Перше: Чи special vdev близький до заповнення?

cr0x@server:~$ zpool list -v tank
NAME         SIZE   ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH
tank        200T    152T    48T        -         -    38%    76%  1.00x  ONLINE
  raidz2-0  200T    148T    52T        -         -    39%    74%      -  ONLINE
  special  3.50T   3.10T   410G       -         -    52%    88%      -  ONLINE

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

Друге: Чи special насичений по IOPS або латентності?

cr0x@server:~$ zpool iostat -v tank 1 10
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank         152T    48T  1.60K  5.10K  120M  260M
  raidz2-0   148T    52T    220  1.30K   80M  190M
  special   3.10T   410G  1.38K  3.80K   40M   70M

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

Третє: Хтось направив дрібні блоки на special і забув?

cr0x@server:~$ zfs get -r special_small_blocks tank
NAME            PROPERTY              VALUE                  SOURCE
tank            special_small_blocks  0                      default
tank/vmstore    special_small_blocks  16K                    local
tank/home       special_small_blocks  0                      inherited from tank

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

Четверте: Чи проблема насправді в загальній фрагментації пулу чи тиску ємності?

cr0x@server:~$ zpool list -Ho cap,frag tank
76%	38%

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

П’яте: Чи пристрій special хворий (SMART, помилки, перезавантаження)?

cr0x@server:~$ dmesg | egrep -i "nvme|I/O error|reset|timeout" | tail -n 10
[123456.789] nvme nvme0: I/O 987 QID 6 timeout, aborting
[123456.790] nvme nvme0: Abort status: 0x371
[123456.800] nvme nvme0: reset controller

Якщо ви бачите ресети/таймаути, не «налаштовуйте ZFS». Виправте апарат/прошивку/шлях.
Рішення: замініть пристрій, оновіть прошивку, перевірте топологію PCIe, управління живленням і підключення (якщо U.2/U.3).

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

1) Симптом: Переліки каталогів і find раптово повільні

Корінь проблеми: Special vdev близький до заповнення або насичений метаданими IOPS; метадані переливаються на HDD або розміщення обмежене.

Виправлення: Перевірте zpool list -v. Якщо special CAP > 80%, розширіть клас special (додайте ще одну дзеркальну пару). Якщо він насичений, розширте ширину або використайте швидші SSD.

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

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

Виправлення: Зменшіть частоту/утримання сніпшотів для датасетів з високим чурном; плануйте очищення сніпшотів у непіковий час; розширте special ємність і IOPS, якщо сніпшоти — незмінна вимога.

3) Симптом: Special vdev непередбачено швидко заповнився після ввімкнення special_small_blocks

Корінь проблеми: Поріг занадто високий (наприклад, 32K) для навантаження з багатьма дрібними записами (VM, БД), що фактично тераїть велику частину даних на SSD.

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

4) Симптом: Після додавання special vdev продуктивність майже не покращилась

Корінь проблеми: Навантаження переважно великі послідовні I/O; метадані не були вузьким місцем. Або пропуски ARC викликані даними, а не метаданими.

Виправлення: Перевірте zpool iostat -v і метрики додатків. Не підключайтеся до всіх налаштувань; special vdev не універсальний прискорювач.

5) Симптом: Імпорт пулу не вдається або зависає після втрати NVMe

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

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

6) Симптом: Зношення NVMe різко зростає

Корінь проблеми: Special vdev отримує дрібні записи плюс чурн; autotrim вимкнено; клас витривалості SSD недостатній.

Виправлення: Увімкніть autotrim, якщо стабільно працює; обирайте SSD з більшою витривалістю; зменшіть область використання дрібних блоків; моніторте SMART Percentage Used.

7) Симптом: «Випадкові» регресії продуктивності після апгрейдів або зміни властивостей

Корінь проблеми: Змінено властивості датасету (recordsize/volblocksize/special_small_blocks), змінивши шаблони розміщення і перемістивши гарячі I/O на special несподівано.

Виправлення: Аудит змін властивостей за допомогою zfs get -r (локальні значення). Розглядайте special_small_blocks як керовану зміну з планом відкату.

Три корпоративні міні-історії (анонімізовано, болісно правдоподібні)

Інцидент через неправильне припущення: «Метадані — це мало»

Середня компанія мала великий HDD пул, який обслуговував монолітний файлшар і репозиторій збірок.
Вони додали дзеркальний special vdev з двох невеликих, але швидких NVMe. У тікеті зміни було написано «метадані малі; 400 GB корисного — цілком достатньо».
Усі кивнули, бо всім подобаються дешеві перемоги.

Шість місяців було чудово. Збірки прискорилися. Домашні каталоги відчувалися швидко. Хтось навіть написав у чаті «ZFS special vdev = безкоштовний перформанс» — що мало б бути індикатором передінциденту.

Потім з’явилася вимога з комплаєнсу: підвищити частоту сніпшотів і продовжити утримання «на всяк випадок».
Сніпшоти накопичилися. Збірки продовжували чурнити. Багато дрібних файлів створювалося й видалялося. Ємність special підкралася вгору, але ніхто не стежив за класом special окремо.
Вони дивилися на загальну ємність пулу, бачили багато вільного місця на HDD і вважали, що все гаразд.

Першим симптомом не було алерту. Люди почали скаржитися: «ls повільний», «git status зависає», «CI таймаути під час очистки».
До моменту, коли SRE заглянув, special був у глибині 90-х відсотків, і система проводила весь час за дорогими операціями розподілу.
Виправлення було простим, але неприємним: аварійне додавання ще однієї дзеркальної пари special і перегляд політик сніпшотів.

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

Оптимізація, що повернулась бумерангом: Увімкнення small blocks скрізь

Інша команда запускала віртуалізацію на ZFS з гібридним пулом: HDD для ємності, special vdev для метаданих.
Пройшов спринт по оптимізації, бо кілька латентно-чутливих VM були незадоволені у пікові години.
Хтось прочитав про special_small_blocks і вирішив «зробити пул швидшим», встановивши на батьківський датасет, щоб це успадковувалося скрізь.

Миттєвий бенчмарк виглядав добре. Проблемні VM покращилися. Спринт закінчився з акуратним слайдом: «Ми використали SSD для дрібного I/O».
Ніхто не поцікавився, яка частка записів нижче порогу, або чи має special витривалість, щоб бути частковим рівнем.

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

Вони відкочували налаштування для більшості датасетів і лишили його лише для невеликої підмножини VM, які цього справді потребували.
Також розширили class special і стандартизували SSD з вищою витривалістю.
Урок засвоїли: special_small_blocks — не безкоштовний обід; це проєктне рішення, яке перетворює пристрої метаданих на рівень.

Нудна, але правильна практика, що врятувала день: Алерти на CAP special і зношення

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

Вони також відстежували індикатори зношення NVMe і мали політику заміни до того, як пристрої ставали проблемними.
Коли special CAP досяг попереджувального порогу, це запускало звичайний процес зміни, а не бойову кімнату.
У команди був план: перевірити датасети з small-block placement, перевірити ріст сніпшотів і спрогнозувати ємність.

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

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

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

Покроково: підбір розміру нового special vdev

1. Класифікуйте навантаження: прискорення тільки метаданих проти метадані + дрібні блоки.
   Якщо не можете відповісти — зупиніться і виміряйте I/O перш ніж йти далі.
2. Виберіть стартовий коефіцієнт:
   • Тільки метадані: 1–2% сирої ємності пулу (2–4% якщо багато дрібних файлів/сніпшотів).
   • Метадані + дрібні блоки: 5–15% сирої ємності (вищий для VM і низьких порогів).
3. Додайте буфер: розмір повинен забезпечувати нормальну роботу при рівні використання класу special до 70%.
4. Виберіть надлишковість: дзеркальні special vdev. Ніяких винятків у продакшні, якщо ви не любите ризикувати збереженням даних інших.
5. Виберіть клас SSD: віддавайте перевагу PLP (захист від втрати живлення) і адекватній витривалості, особливо якщо маршрутуються дрібні блоки.
6. Налаштуйте моніторинг: відстежуйте CAP special, special frag, помилки/reset NVMe, SMART зношення і зміни в zpool status.
7. Впроваджуйте обережно: якщо вмикаєте розміщення дрібних блоків, робіть це по датасетах і валідуйте перед розширенням.

Покроково: коли special уже замалий

1. Підтвердіть CAP special за допомогою zpool list -v.
2. Визначте датасети, що драйвлять ріст через zfs get -r special_small_blocks і кількість сніпшотів.
3. Розширте class special додавши ще одну дзеркальну пару special vdev.
4. Зменшіть майбутній тиск: знизьте поріг special_small_blocks або обмежте його критичними датасетами.
5. Впорядкуйте утримання: політики сніпшотів відповідають реальному RPO/RTO, а не тривозі.
6. Перевірте зношення: упевніться, що бюджет витривалості SSD ще спрацьовує.

Операційний чеклист: щотижня (так, щотижня)

• Перевірити zpool status на предмет помилок пристроїв.
• Перевірити zpool list -v і сигналізувати, якщо special CAP > 75%.
• Перевірити SMART зношення на пристроях special.
• Аудит датасетів з увімкненим special_small_blocks.
• Переглянути кількість сніпшотів і відповідно їх чистити.

FAQ

1) Чи можна ставитися до special vdev як до кеша?

Ні. L2ARC — це кеш. SLOG — це лог-пристрій. Special vdev може містити критично важливі для пулу метадані. Втрата його може означати втрату пулу.
Проєктуйте його як первинне сховище.

2) Як зрозуміти, чи варто вмикати special_small_blocks?

Вмикайте лише якщо у вас виміряна проблема з випадковим I/O на HDD vdev і у вас є бюджет ємності/витривалості SSD.
VM-стори — часті кандидати; загальні файлові шару зазвичай нормально працюють з only-metadata special.

3) Яке значення використовувати для special_small_blocks?

Консервативні дефолти: 8K або 16K для цільових датасетів. Вищі пороги захоплюють більше I/O, але швидше споживають special ємність.
Почніть з меншого, вимірюйте, потім розширюйте за потребою.

4) Що відбувається, коли special vdev заповнюється?

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

5) Чи можна потім видалити special vdev?

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

6) Які пристрої краще для special: NVMe, SATA SSD чи щось інше?

NVMe ідеальний для IOPS і низької латентності метаданих. SATA SSD все одно може значно допомогти в порівнянні з HDD.
Чим більше навантаження на метадані, тим важливіше NVMe.

7) Чи додавання більшої кількості дзеркал special покращує продуктивність?

Часто так. Більше дзеркал збільшує IOPS-ємність і знижує черги. Також збільшує ємність.
Але це не вирішить фундаментально перевантажений пул або патологічний чурн датасетів.

8) Чи безпечно використовувати RAIDZ для special vdev?

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

9) Як розмір special vdev пов’язаний з ARC/RAM?

ARC допомагає кешувати метадані і дані в RAM. Special vdev зменшує штраф, коли метадані не в ARC.
Якщо ARC замалий, special все одно допоможе, але ви можете маскувати проблему з пам’яттю.

10) Якщо я додаю special vdev, чи перемістяться існуючі метадані на нього?

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

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

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

1. Запустіть zpool list -v і зафіксуйте CAP special. Якщо понад 75% — відкрийте тікет на зміну ємності.
2. Запустіть zfs get -r special_small_blocks і складіть список датасетів, які це використовують. Перевірте, що кожен з них налаштований свідомо.
3. Перегляньте кількість сніпшотів і політику утримання. Якщо ви тримаєте історію «аби було», ви платите за це у метаданих.
4. Додайте моніторинг для використання класу special і зношення NVMe. Якщо ви моніторите лише загальну ємність пулу, ви дивитеся на невірну панель.
5. Якщо проєктуєте новий пул, підбирайте special так, щоб у стійкому стані він був менше 70% використання, дзеркальте його і купуйте SSD з витривалістю, відповідною до вашого навантаження.

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