ZFS dnodesize=auto: підсилення метаданих, про яке всі забувають

Розмови про продуктивність ZFS зазвичай обертаються навколо яскравих ручок: recordsize, спеціальні vdev, slog-пристрої, стиснення та вічне «робимо дзеркало чи RAIDZ?». Тим часом одна з найефективніших оптимізацій метаданих тихо сидить у кутку, як запасне колесо, про яке ви забули: dnodesize=auto.

Якщо у вас робочі навантаження з великою кількістю крихітних файлів, інтенсивними розширеними атрибутами (xattrs), ACL або постійним потоком операцій обходу директорій, dnodesize=auto може бути різницею між «диски idle, але все повільно» і «метадані знову нудні». Ця стаття про те, як зробити метадані нудними — бо нудні метадані це подарунок, який ви цінуєте після виклику о 03:00 через повільний ls.

Зміст

• Що таке dnode (і чому вам це має бути важливо)
• Що насправді робить dnodesize=auto
• Чому всі забувають про цю налаштування
• Факти та історичний контекст для нарад
• Які навантаження отримають вигоду (а які ні)
• Як безпечно увімкнути
• Практичні завдання (команди + інтерпретація)
• Швидкий план діагностики
• Три міні-історії з корпоративного життя
• Поширені помилки, симптоми та виправлення
• Контрольні списки / покроковий план
• FAQ
• Висновок

Що таке dnode (і чому вам це має бути важливо)

У ZFS кожен файл, директорія, снапшот та об’єкт датасету описується структурою, що називається dnode (скорочено від «data node»). Уявіть його як посвідчення особи файлу плюс його адресну книгу: він зберігає метадані та вказівники на блоки, що містять вміст файлу. Коли файл маленький або «важкий» на метадані, dnode стає центром тяжіння.

Практичний наслідок такий: якщо ZFS може розмістити більше корисних метаданих всередині dnode, він може уникнути додаткових звернень за «spill blocks» — додатковими блоками, що містять переповнення метаданих, які не вмістилися. Spill blocks не є «злом», але це додаткові I/O, додатковий тиск на кеш і додаткова затримка — особливо болісно, коли ви виконуєте масу операцій над метаданими.

Більшість інцидентів з продуктивністю, з якими я працював у цій області, мали спільний почерк: читання/запис даних виглядали нормально, але обходи директорій і сценарії, що активно роблять stat (подумайте: сканери бекапів, CI-агенти, шари контейнерів, менеджери пакетів мов), перейшли від «достатньо швидко» до «чому find займає 20 хвилин?». Це метадані, і dnode — це місце, з якого починати.

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

Що насправді робить dnodesize=auto

dnodesize — це властивість датасету, яка контролює розмір dnode, що зберігаються на диску. Історично стандартний розмір dnode був 512 байт. Цього достатньо для базових метаданих файлу і обмеженої кількості вказівників блоків — підходить для багатьох навантажень, але не ідеально, коли ви пакуєте багато розширених атрибутів, ACL або іншого «додаткового» метаданого в об’єкт файлу.

Коли ви встановлюєте dnodesize=auto, ZFS може використовувати більші dnode коли це потрібно (до максимально підтримуваного розміру, зазвичай до 16K залежно від реалізації і feature flags). Він не роздуває сліпо кожен об’єкт; він встановлює розмір dnode відповідно до потреб метаданих. Мета — зменшити (або усунути) spill blocks для метаданих, які інакше не вмістилися б.

Бонусні буфери, xattr і spill blocks: суть

Кожен dnode містить «bonus buffer», куди ZFS зберігає метадані понад базових полів — такі як інформація ZPL (POSIX-слой), ACL та, залежно від конфігурації, inline xattr.

Якщо bonus buffer занадто малий, ZFS зберігає переповнення в spill block. Spill blocks — це додаткові блоки, які потрібно прочитати, щоб отримати доступ до цих метаданих. Ось момент, коли ваш простий виклик stat() перетворюється на «stat плюс додатковий випадковий I/O». Навіть на флешах це може мати значення; на HDD це може бути катастрофічно за високої конкуренції.

З dnodesize=auto bonus buffer може бути більшим, тому xattr/ACL часто можуть зберігатися безпосередньо в ньому. Практичний результат — менше IOPS, витрачених просто на питання «що це за файл?».

Auto проти фіксованого dnodesize

Ви також можете встановити dnodesize в фіксовані значення як-от 1k, 2k, 4k тощо. Фіксовані значення — це грубий інструмент: вони можуть допомогти, але можуть й витрачати простір, коли більший розмір не потрібен. auto — це підхід «збільшуй лише коли це вигідно».

Операційно мені подобається auto, тому що це найближче до «хочу гарну продуктивність метаданих без постійної переплати за кожен об’єкт». Це не магія, але розумний стандарт для сучасних змішаних навантажень.

Чому всі забувають про цю налаштування

Три причини:

1. Вона не ефектна. Ви не отримаєте графік з 2x послідовною пропускною здатністю. Ви побачите менші затримки, менше IOPS, менше зависань у завданнях, що активно працюють з директоріями — складніше похвалитися цим.
2. Вона прив’язана до feature flags та звичок створення датасетів. Багато організацій мають старі пулі, оновлені «лише достатньо», і властивості датасетів мають тенденцію фосилізуватися.
3. Проблеми з метаданими виглядають як «система повільна». Люди ганяються за CPU, мережею або віртуальним середовищем. Тим часом накопичення метаданих тихо рубає систему на тисячі дрібних порізів.

Другий короткий жарт: коли хтось каже «це всього лиш метадані», це ваше сигнал до планування довгої наради й скасування вихідних.

Факти та історичний контекст для нарад

• ZFS проєктовано з пріоритетом цілісності від початку. Контрольні суми й copy-on-write не були додатками — вони формували все, включно з розкладкою метаданих.
• Класичні dnode мали 512 байт. Це мало сенс, коли диски були повільніші й очікування щодо метаданих простіші; сучасні навантаження носять більше «багажу» на файл (ACL, xattr, мітки, метадані контейнерів).
• Розширені атрибути змінили правила гри. Операційні системи й додатки почали покладатися на xattr для міток безпеки, користувацьких метаданих і індексування — «метадані» набули реальної ваги.
• ACL можуть бути великими та говіркими. ACL NFSv4 особливо можуть роздути метадані на файлі, перетворюючи обходи директорій на бурю метаданих I/O.
• Feature flags ZFS відкрили можливості покращення на диску. Багато «нових» поведінок (включно з більш гнучким зберіганням метаданих) залежать від увімкнення фіч на рівні пулу.
• Метадані часто домінують у навантаженнях з малими файлами. У поштових скриньках, CI-робочих просторах, реєстрах мов і шарах контейнерів ви часто упираєтеся в «пошуки та stat», а не в читання корисних даних.
• Тиск на ARC може бути тиском на метадані. ARC — це кеш, але він не бездонний. Надмірні метадані або багато spill blocks можуть його «жорстко» обертати.
• Команди операцій вчилися на власних помилках. Перехід індустрії від монолітів до мікросервісів збільшив кількість дерев файлів, шарів логів і «дрібних об’єктів» — метадані стали продакшн-трафіком.

Які навантаження отримають вигоду (а які ні)

Хороші кандидати

dnodesize=auto зазвичай допомагає, якщо у вас є:

• Багато маленьких файлів і часта активність stat()/readdir() (системи збірки, менеджери пакетів, CI-агенти).
• Інтенсивні xattr (мітки безпеки, тегування додатків, метадані бекапів, потоки Samba, метадані macOS на спільному сховищі).
• Середовища з великою кількістю ACL (ACL NFSv4, корпоративні шари з складними дозволами).
• Датасети з великою кількістю снапшотів, де метадані постійно посилаються і обходяться.

Нейтральний або обмежений вплив

• Великі послідовні файли (відео, бекапи, великі бінарні об’єкти): навантаження домінують дані блоки, а не метадані.
• Патерни сховища типу object, де ви зберігаєте великі об’єкти і рідко переліковуєте директорії.

Компроміси

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

Як безпечно увімкнути

Правила високого рівня, які вбережуть від проблем:

1. Перевірте feature flags перш ніж починати. Деякі реалізації вимагають увімкнення певних функцій пулу, щоб підтримувати більші dnode. Якщо ваш пул давній — виконайте ретельну перевірку.
2. Увімкніть на рівні датасету там, де це має значення. Не треба міняти всюди. Почніть з відомих «гарячих» точок метаданих.
3. Вимірюйте до й після. Покращення метаданих з’являються в затримках, патернах IOPS і «скільки часу займає обхід директорії». Виберіть тест, який можна повторити.
4. Розумійте, що це здебільшого не ретроактивно. Якщо потрібно, щоб існуючі файли отримали вигоду, плануйте copy/rsync, send/receive міграцію або перекомпоновку.

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

Нижче наведені конкретні завдання, які ви можете виконати в продакшні (обережно) або в стенді (бажано). Кожне включає на що звертати увагу.

Завдання 1: Визначити датасети та поточний dnodesize

cr0x@server:~$ zfs list -o name,used,avail,mountpoint -r tank
NAME                 USED  AVAIL  MOUNTPOINT
tank                 980G  2.60T  /tank
tank/home            120G  2.60T  /tank/home
tank/ci              220G  2.60T  /tank/ci
tank/shares          410G  2.60T  /tank/shares

cr0x@server:~$ zfs get -o name,property,value,source dnodesize -r tank
NAME        PROPERTY   VALUE  SOURCE
tank        dnodesize  legacy local
tank/home   dnodesize  legacy inherited
tank/ci     dnodesize  legacy inherited
tank/shares dnodesize  legacy inherited

Інтерпретація: Якщо ви бачите legacy або фіксований малий розмір на датасетах з великою кількістю метаданих — у вас кандидат. «Legacy» часто означає «старий за замовчуванням».

Завдання 2: Перевірити статус feature flags пулу

cr0x@server:~$ zpool get all tank | egrep 'feature@|compatibility'
tank  compatibility  off    default
tank  feature@async_destroy  active  local
tank  feature@spacemap_histogram  active  local
tank  feature@extensible_dataset  active  local

Інтерпретація: Ви шукаєте сучасний набір функцій. Точні назви фіч залежать від платформи. Якщо ваш пул показує багато функцій як disabled або ви в режимі обмеженої сумісності, призупиніться і оцініть підтримку dnode sizing перш ніж робити припущення.

Завдання 3: Увімкнути dnodesize=auto для цільового датасету

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

Інтерпретація: Це змінює поведінку для нових/перезаписаних об’єктів у tank/ci. Воно не перепише весь датасет саме по собі.

Завдання 4: Підтвердити режим зберігання xattr (SA vs dir)

cr0x@server:~$ zfs get xattr tank/ci
NAME     PROPERTY  VALUE  SOURCE
tank/ci  xattr     sa     inherited

Інтерпретація: xattr=sa зберігає xattr в області «system attribute» (bonus buffer), коли можливо. Це добре поєднується з більшими dnode, бо більше xattr може жити inline і уникати окремих об’єктів.

Завдання 5: Перевірити режим ACL та наслідування

cr0x@server:~$ zfs get acltype,aclinherit,aclmode tank/shares
NAME        PROPERTY    VALUE      SOURCE
tank/shares acltype     nfsv4      local
tank/shares aclinherit  passthrough local
tank/shares aclmode     passthrough local

Інтерпретація: ACL NFSv4 можуть бути тяжкими на метадані. Якщо користувачі скаржаться на повільні переліки директорій на ACL-насичених шарах, підбір dnode sizing плюс налаштування xattr/SA може мати значення.

Завдання 6: Виявити поведінку, обмежену метаданими, за допомогою iostat

cr0x@server:~$ zpool iostat -v tank 1 5
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank         980G  2.60T    950   1200  12.3M  18.1M
  mirror     490G  1.30T    480    610  6.1M   9.0M
    sda         -      -    240    305  3.0M   4.5M
    sdb         -      -    240    305  3.1M   4.5M
  mirror     490G  1.30T    470    590  6.2M   9.1M
    sdc         -      -    235    295  3.1M   4.6M
    sdd         -      -    235    295  3.1M   4.5M

Інтерпретація: Висока кількість операцій при скромній пропускній здатності часто означає дрібні I/O. Це не доказ проблем з метаданими, але типовий шаблон, коли домінують обходи директорій і активність з малими файлами.

Завдання 7: Виміряти час обходу директорії (повторюваний мікро-бенчмарк)

cr0x@server:~$ time find /tank/ci/workspace -type f -maxdepth 4 -print >/dev/null

real    0m18.442s
user    0m0.312s
sys     0m2.901s

Інтерпретація: Відстежуйте це до і після змін на порівнюваних деревах файлів. Якщо ваш sys час високий, а реальний час доміновано I/O waits, підозрюйте читання метаданих.

Завдання 8: Перевірити тиск ARC і сигнали кешування метаданих

cr0x@server:~$ arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:01:10   820   140     17    60  43%    20  14%    60  43%   28G   32G
12:01:11   790   180     23    95  53%    15   8%    70  39%   28G   32G
12:01:12   810   210     26   120  57%    10   5%    80  38%   28G   32G

Інтерпретація: Підвищені misses під час операцій, що тяжіють до метаданих, можуть вказувати на thrash ARC. Менше spill blocks може зменшити кількість окремих блоків метаданих, які потрібно кешувати.

Завдання 9: Підтвердити властивості, пов’язані з продуктивністю метаданих

cr0x@server:~$ zfs get atime,compression,primarycache,secondarycache,logbias tank/ci
NAME     PROPERTY       VALUE     SOURCE
tank/ci  atime          off       local
tank/ci  compression    lz4       inherited
tank/ci  primarycache   all       default
tank/ci  secondarycache all       default
tank/ci  logbias        latency   default

Інтерпретація: Вимкнення atime зменшує запис метаданих для дерев, що читаються. Тримайте primarycache=all, якщо немає серйозної причини інакше; кешування лише метаданих (metadata) може бути корисним при обмеженій оперативній пам’яті, але це не рекомендація за замовчуванням.

Завдання 10: Перевірити, чи ви платите за spill xattr важким шляхом

cr0x@server:~$ getfattr -d -m - /tank/ci/workspace/somefile 2>/dev/null | head
# file: tank/ci/workspace/somefile
user.build_id="9f1c..."
user.origin="pipeline-17"

Інтерпретація: Це прямо не показує spill, але підтверджує, що xattr використовуються. Якщо ви бачите широке використання xattr і повільні операції з метаданими, dnode sizing стає більш релевантним.

Завдання 11: Оцінити поведінку метаданих для малих файлів простим тестом створення/stat

cr0x@server:~$ mkdir -p /tank/ci/.bench
cr0x@server:~$ rm -rf /tank/ci/.bench/*
cr0x@server:~$ time bash -c 'for i in $(seq 1 20000); do echo x > /tank/ci/.bench/f.$i; done'

real    0m24.901s
user    0m2.210s
sys     0m12.884s

cr0x@server:~$ time bash -c 'for i in $(seq 1 20000); do stat /tank/ci/.bench/f.$i >/dev/null; done'

real    0m11.332s
user    0m0.411s
sys     0m2.870s

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

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

cr0x@server:~$ zfs get -s local,inherited dnodesize -r tank | sed -n '1,12p'
NAME      PROPERTY   VALUE  SOURCE
tank      dnodesize  legacy local
tank/ci   dnodesize  auto   local
tank/home dnodesize  legacy inherited

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

Завдання 13: Використати send/receive, щоб фактично застосувати нове dnode sizing до існуючих даних (патерн міграції)

cr0x@server:~$ sudo zfs snapshot -r tank/ci@pre-dnode-mig
cr0x@server:~$ sudo zfs create -o dnodesize=auto -o xattr=sa tank/ci_new
cr0x@server:~$ sudo zfs send -R tank/ci@pre-dnode-mig | sudo zfs receive -F tank/ci_new

Інтерпретація: Це чистий метод «застосувати нові властивості до всього». Ви створюєте новий датасет з бажаними властивостями і приймаєте туди send. Все одно потрібен план відключення/переключення (mountpoint, сервіси, права), але так ви уникаєте чекання органічного перезапису.

Завдання 14: Перевірити після зміни цілеспрямованим навантаженням, що тяжіє до метаданих

cr0x@server:~$ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
cr0x@server:~$ time ls -lR /tank/ci/workspace >/dev/null

real    0m42.118s
user    0m0.902s
sys     0m6.331s

Інтерпретація: Скидання кешів руйнівне і не завжди можливе на продакшн-хостах; використовуйте стенд якщо можете. Мета — усунути «все вже в кеші» як відмовку і змусити систему показати поведінку метаданих на диску.

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

Це чекліст «у вас 15 хвилин до того, як інцидент-менеджер запитає напрям». Мета — вирішити, чи метадані є гальмом і чи dnode sizing/xattr в зоні ризику.

Перше: доведіть, що пахне метаданими

1. Перевірте симптоми: користувачі повідомляють про повільний ls -l, повільний find, повільні перевірки дозволів, повільні кроки CI як «checkout» або «npm install», але масові читання/записи виглядають нормально.
2. Подивіться на форму I/O: висока кількість IOPS, низька пропускна здатність у zpool iostat.
3. Перевірте затримки: навіть на SSD сплески латентності метаданих проявляються як хвостова латентність сервісів (p95/p99), а не падіння пропускної здатності.

Друге: визначте, де концентрується тиск метаданих

1. Знайдіть датасет: який маунт повільний? Зв’яжіть його з датасетом через zfs list.
2. Перегляньте ключові властивості: dnodesize, xattr, atime, acltype, primarycache.
3. Перевірте поведінку ARC: якщо demand misses ростуть під час обходів директорій, ймовірно, ви не кешуєте те, що думаєте.

Третє: вирішіть рівень втручання

1. Низький ризик: увімкнути dnodesize=auto для майбутніх об’єктів; встановити/підтвердити xattr=sa коли доречно; вимкнути atime якщо безпечно.
2. Середній ризик: мігрувати гарячий датасет через send/receive, щоб «перепакувати» метадані з новими налаштуваннями.
3. Високий ризик: зміни feature flags пулу, зміни спеціальних vdev або архітектурні зрушення. Не робіть цього під час інциденту, якщо ви не любите писати постмортеми, що починаються з «через надмірний оптимізм».

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

Міні-історія 1: Інцидент через невірне припущення

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

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

Насправді ARC постійно «випадав» з роботи. Кожен обхід директорії викликав парад читань метаданих, і багато з цих читань тягли spill blocks, бо файли мали важкі xattr та ACL. Нічого «не ламається» в сенсі помилок чи дисків, що відмовили. Це був просто податок, який система тихо платила — доки використання не виросло настільки, що податок перетворився на outage.

Виправлення не було драматичним. Спочатку вони перестали звинувачувати мережу. Потім увімкнули dnodesize=auto і підтвердили xattr=sa на датасеті, що використовувався для шару. Негайне покращення було скромним, бо існуючі об’єкти все ще мали малі dnode. Справжній виграш настав після запланованої міграції (send/receive у свіжий датасет з новими властивостями). Переліки директорій перестали таймаутитись, а інцидент закрився з найменш гламурною причиною: «неефективне розміщення метаданих». Для мене це комплімент — нудкі причини можна запобігти.

Міні-історія 2: Оптимізація, що дала зворотний ефект

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

Спочатку здавалося, що це виграш. Обходи директорій стали швидшими. Потім почалися збої при завантаженні контейнерів. Конвеєр збірки, який раніше плавно стримив шари, почав страждати хвостовими латентностями. В on-call з’явився новий улюблений алерт: «registry fetch timed out».

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

Вирішення було двояким: відкотити primarycache до all для змішаних навантажень і використовувати dnodesize=auto плюс xattr=sa, щоб зменшити мета-накладні витрати без голодування кеша даних. Урок старий, але вічний: не міняйте p95 однієї команди на outage іншої, якщо не можете назвати компроміс і захистити його.

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

Одна з найбільш здорових операційних практик, яку я бачив, мала ритуал, що здавався надто простим: кожного разу, коли вони створювали новий верхній датасет, вони застосовували набір базових властивостей — стиснення, atime, xattrs, політику ACL і, так, dnodesize=auto де це доречно. Вони не покладалися на племінні знання. Вони це кодували.

Місяць потому пройшов rollout безпеки: більше міток, більше xattr, більше складності ACL. Та сама зміна, яка в інших службах призводила до катастрофи. Їхнє середовище… в основному знехтувало. Було деяке зростання використання метаданих, але ніякого різкого падіння.

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

Ось прихована цінність dnodesize=auto: це не геройська кнопка порятунку; це гігієнічна настройка. Вона перетворює певні класи майбутніх інцидентів на «ми помітили регресію і впровадили», замість «ми виявили, що метадані мають фізику».

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

Помилка 1: Очікувати, що зміна dnodesize перепише існуючі файли

Симптом: Ви встановили dnodesize=auto, перезапустили навантаження, і нічого не змінилося.

Чому: Існуючі об’єкти тримають свій поточний розмір dnode, поки метадані не будуть перезаписані таким чином, щоб алокувати новий розмір dnode, або поки ви не мігруєте дані.

Виправлення: Плануйте міграцію датасету (send/receive у новий датасет з бажаними властивостями) або приймайте, що вигоди з’являтимуться поступово у міру churn файлів.

Помилка 2: Увімкнути dnodesize=auto без узгодження стратегії xattr

Симптом: Ви все ще бачите інтенсивний мета- I/O і xattr-важкі додатки залишаються повільними.

Чому: Якщо xattr зберігаються як окремі об’єкти (xattr=dir), ви все одно робите додаткові пошуки і читання навіть з більшими dnode.

Виправлення: Оцініть xattr=sa для датасету, враховуючи сумісність ОС/клієнтів і поведінку навантаження. Застосовуйте свідомо, не як суєвір’я.

Помилка 3: Застосовувати тюнінг метаданих до змішаних навантажень без розбору

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

Чому: Властивості як primarycache і навіть вибір recordsize можуть перемістити продуктивність між шляхами метаданих і даних.

Виправлення: Розділяйте датасети за типом навантаження коли можливо. Використовуйте нудкий інструмент: окремі маунтпоінти для різних «перформанс-персональностей».

Помилка 4: Сприймати повільний ls як «мережеву» проблему за замовчуванням

Симптом: SMB/NFS користувачі бачать повільні переліки директорій; команди операцій ганяються за MTU, DNS і буферами свічів.

Чому: Запит клієнта тригерить бурю метаданих lookup-ів; мережа лише кур’єр.

Виправлення: Корелюйте клієнтські операції з серверними IOPS і misses ARC. Запустіть локальний на сервері бенчмарк обходу директорії, щоб відокремити «сервер повільний» від «мережа повільна».

Помилка 5: Ігнорувати підсилення ACL

Симптом: Директорії з важкими дозволами значно повільніші за подібні директорії з простішими дозволами.

Чому: Оцінка та зберігання ACL може роздути метадані, спричиняючи більше spill і більше читань.

Виправлення: Перегляньте acltype і режим наслідування; переконайтеся, що датасет налаштований для очікуваної семантики ACL. Скомбінуйте з dnodesize=auto, щоб тримати ACL inline, коли можливо.

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

План A: Низькоризикове розгортання (вигоди для нових даних першими)

1. Виберіть правильний датасет: Ідентифікуйте датасет з найгіршими симптомами метаданих (CI workspace, спільні домашні директорії, дерева checkout коду).
2. Зніміть поточні налаштування:

   cr0x@server:~$ zfs get dnodesize,xattr,acltype,atime,compression tank/ci

3. Увімкніть dnodesize=auto:

   cr0x@server:~$ sudo zfs set dnodesize=auto tank/ci

4. Підтвердіть політику xattr:

   cr0x@server:~$ sudo zfs set xattr=sa tank/ci

5. Підтвердіть політику atime: Якщо безпечно для ваших додатків:

   cr0x@server:~$ sudo zfs set atime=off tank/ci

6. Вимірюйте за допомогою повторюваного тесту: Збережіть базовий find/stat бенчмарк і порівнюйте з часом, як створюються нові об’єкти.

План B: Роллаут з міграцією (існуючі дані отримують вигоду негайно)

1. Заплануйте вікно: Потрібен план cutover. Не імпровізуйте з обміном маунтпоінтів під час активного запису.
2. Сделайте снапшот джерела:

   cr0x@server:~$ sudo zfs snapshot -r tank/ci@mig-start

3. Створіть цільовий датасет з потрібними властивостями:

   cr0x@server:~$ sudo zfs create -o dnodesize=auto -o xattr=sa -o atime=off tank/ci_v2

4. Send/receive:

   cr0x@server:~$ sudo zfs send -R tank/ci@mig-start | sudo zfs receive -F tank/ci_v2

5. Cut over: Зупиніть писачів, зробіть фінальний інкрементальний send (якщо треба), перемонтуйте і перезапустіть сервіси.
6. Валідація після cutover: Повторіть ваші мета-бенчмарки і спостерігайте за ARC/iostat під час пікового навантаження.

План C: Запобігання дрейфу (практика, що приносить користь постійно)

1. Визначте шаблони базових датасетів по типу навантаження (загального призначення, шари, CI, логи).
2. Забезпечте через автоматизацію: створюйте датасети з явними властивостями замість наслідування невідомих дефолтів.
3. Регулярно аудитуйте:

   cr0x@server:~$ zfs get -r -o name,property,value,source dnodesize,xattr,atime,acltype tank | head -n 40

FAQ

1) Що в простих словах змінює dnodesize=auto?

Воно дозволяє ZFS виділяти більші dnode тільки коли метадані об’єкта цього вимагають, так більше метаданих може зберігатися inline і менше spill blocks буде потрібно.

2) Чи пришвидшить це все?

Ні. Воно орієнтоване насамперед на сценарії, де багато метаданих: багато маленьких файлів, багато xattr/ACL і інтенсивні обходи директорій. Великі послідовні читання/записи зазвичай не відчують різниці.

3) Чи безпечно увімкнути на існуючому датасеті?

Загалом так; це властивість датасету. Головна «підводна камінь» — очікування: воно не переробить старі файли автоматично. Безпека також залежить від підтримки платформи і увімкнених feature flags пулу.

4) Чи збільшить це використання диска?

Можливо, для об’єктів, що справді використовують більші dnode. Мета auto — платити за простір лише коли це зменшує spill blocks і підвищує ефективність.

5) Як це пов’язано з xattr=sa?

xattr=sa зберігає xattr в області system attribute (bonus buffer) коли можливо. Більші dnode означають більший бюджет для bonus buffer, що дозволяє тримати більше xattr inline і зменшувати додатковий I/O.

6) Якщо я встановлю dnodesize=auto, чи потрібен мені спеціальний vdev для метаданих?

Це вирішує різні проблеми. dnodesize=auto зменшує I/O метаданих, поміщаючи більше inline і уникаючи spill. Спеціальний vdev прискорює метадані, розміщуючи їх на швидшому носії. Можна використовувати обидва, але не вважайте одне заміною іншого.

7) Як дізнатися, чи мене шкодять spill blocks?

На практиці: повільний stat і обходи директорій, висока кількість IOPS при низькій пропускній, misses ARC під час операцій з метаданими, і непропорційне уповільнення в деревах з xattr/ACL. Доказ участі spill blocks може бути специфічним для платформи, тож ставтеся до цього як до кореляційної вправи плюс контрольовані бенчмарки.

8) Чи варто встановити dnodesize в фіксовано більший розмір замість auto?

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

9) Чи впливає dnodesize=auto на send/receive?

Воно впливає на те, як нові отримані об’єкти будуть розміщені в цільовому датасеті, бо властивості цілі визначають поведінку алокацій. Саме тому міграція через send/receive — практичний спосіб «застосувати» dnode sizing до існуючих даних.

10) Який найшвидший виграш, якщо я не можу мігрувати?

Увімкніть dnodesize=auto зараз, щоб нові файли отримували вигоду, переконайтеся, що xattr=sa підходить, і усуньте уникаємі записи метаданих (наприклад, atime=on на гарячих деревах). Потім плануйте міграцію, коли бізнес це витримає.

Висновок

dnodesize=auto — це одна з тих налаштувань ZFS, що здається неважливою — поки ви не опинитесь по той бік стіни метаданих. Воно не робить графіки пропускної здатності захопливими. Воно робить обходи директорій непомітними. Воно зменшує I/O-«податок» від xattr і ACL. І в сучасних продакшн-середовищах — де програмне забезпечення любить створювати гори дрібних файлів і прикріплювати метадані до всього — це не нішова оптимізація. Це стабільність.

Якщо запам’ятати одну операційну пораду: розглядайте метадані як першокласне навантаження. Встановлюйте dnodesize=auto свідомо на датасетах, яким це потрібно, поєднуйте з узгодженою стратегією xattr/ACL і вимірюйте результати за допомогою повторюваних тестів. Найкращий день виправити метадані — до інциденту. Другий найкращий — до наступного разу, коли ls стане вашою панеллю інцидентів.