ZFS: єдина «безпечна» настройка, яка непомітно руйнує продуктивність з часом

Все виглядає здоровим. Pool — ONLINE. Немає помилок. ARC теплий. Затримки… дивні. Читання, які раніше були нудними, тепер стрибкоподібні, і ваші графіки схожі на знайому криву «повільно вариться жаба». Люди звинувачують мережу. Або гіпервізор. Або «ZFS як ZFS».

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

Налаштування: atime=on (і чому це бомба уповільнення продуктивності)

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

Речовиною часто виступає нешкідливе за замовчуванням: atime=on. Оновлюється час доступу. Кожного разу, коли файл читають, його метадані отримують оновлення часу доступу. На багатьох системах це нормально. На завантаженому ZFS-датасеті — особливо з великою кількістю дрібних файлів, навантаженнями, що генерують багато метаданих, або VM — це генератор записів, прихований під читанням.

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

Рекомендація: для майже всіх продакшн-датасетів встановлюйте atime=off. Увімкнюйте його тільки тоді, коли можете назвати конкретну поведінку застосунку, яка потребує часу доступу, і виміряли накладні витрати.

Що atime насправді робить у ZFS

На папері atime простий: коли файл читають, файловій системі потрібно оновити метадані: «цей файл був доступний у час X». Звучить як крихітна зміна. Але в файлових системах з copy-on-write, як ZFS, «дрібні оновлення метаданих» не завжди дрібні.

Чому оновлення метаданих може стати реальним записом

ZFS використовує copy-on-write. Оновлення метаданих зазвичай означає запис нових блоків метаданих, оновлення вказівників блоків і зрештою фіксацію цих змін у пулі. Це не зло; так ZFS забезпечує цілісність. Але це означає, що навантаження, яке могло б бути тільки для читання, перетворюється на постійний потік записів — часто дрібних, розкиданих, частково синхронних у невірних шарах і часто розташованих так, що їх важко звести до послідовного вводу-виводу.

Чому це важливіше на хостах VM і контейнерів

Хости віртуалізації багато читають: бібліотеки, бінарні файли, кеші пакетів, шари контейнерів і образи VM. Вони також регулярно сканують каталоги, виконують stat файлів і роблять багато короткочасних доступів. Якщо atime=on, ці «читання» також змінюють метадані. Тепер хост виконує фоні записи, тоді як ви клянетеся, що це «в основному тільки читання». Ваші графіки затримок не погоджуються.

«Але це ж лише один таймстемп»

Так. І все ж: одне оновлення часу доступу на кожне читання, помножене на мільйони читань на день — це уже не просто таймстемп. Це повноцінне навантаження.

Короткий жарт №1: Вмикнути atime у продакшені — як поставити прапорець «будь ласка, логувати все» у вашому гарячому шляху. Працюватиме чудово… поки не перестане.

Чому це погіршується з часом (непомітно)

Частина «з часом» робить цю настройку особливо ефективною в витрачанні вашого часу. Коли atime=on, ви додаєте безперервний фоновий потік дрібних оновлень метаданих. ZFS групуватиме їх у TXG, але шаблони все одно важливі. За місяці ви можете отримати:

• Більше дрібних записів, ніж прогнозувалася для вашого навантаження.
• Більше блоків метаданих, що оновлюються й переписуються частіше, ніж очікували.
• Більше фрагментації, особливо якщо вільне місце зменшується або класи алокації зазнають стресу.
• Більше конкуренції у каналі запису: синхронізація TXG, SPA space maps, черги vdev.
• Менше ефективного кешування, бо метадані витісняють «корисні» кешовані дані.

Проблема не лише в IOPS; це хвостова латентність

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

Чому це ховається на виду

Моніторинг зазвичай класифікує ввід/вивід як читання проти записів на рівні блочного пристрою. Але atime перетворює читання на метадані-записи, які можуть не виглядати як «записи вашого застосунку». Це виглядає як фонові операції файлової системи. І оскільки це «нормально», це рідко ставлять під сумнів.

Факти й історичний контекст (коротко й по суті)

1. Час доступу старший за більшість вашої інфраструктури. UNIX відстежує atime/mtime/ctime десятиліттями, задовго до появи SSD, гіпервізорів і мікросервісів, які зробили «дрібні метадані-записи» дорогими в масштабах.
2. Linux ввів relatime як компроміс. Індустрія помітила накладні витрати atime роками тому; relatime оновлює atime менш агресивно (часто раз на добу або коли змінюється mtime/ctime).
3. Історично ZFS за замовчуванням віддавав перевагу коректності й очікуванням POSIX. За замовчуванням atime=on відповідає традиційній семантиці, а не сучасним очікуванням продуктивності.
4. CoW-файлові системи по-іншому платять за метадані. Ext* може оновлювати in-place; ZFS записує нові блоки метаданих. Це сила для цілісності — і вартість для марного шуму.
5. Atime взаємодіє зі снапшотами. Снапшоти зберігають старі метадані; часті перезаписи метаданих можуть збільшувати churn блоків, що реферуються, і ускладнювати облік простору.
6. Навантаження NFS і SMB можуть підсилювати оновлення atime. Операції метаданих по мережевих файлових системах можуть викликати додаткові перевірки доступу й торкання файлів, що збільшує частоту оновлень.
7. Формати образів VM вас не врятують. Навіть якщо гість робить «тільки читання», гостева файловa система хоста все одно може оновлювати atime для файлу образу VM і для кешів на хості.
8. Багато пристроїв і NAS-продуктів тихо вимикають atime. Не тому, що вони ненавидять POSIX, а тому, що вони ненавидять тикети підтримки про «NAS став повільним».
9. Спеціальні vdev змінили правила гри для метаданих. Сучасні можливості OpenZFS, як спеціальні класи алокації, можуть ізолювати метадані на швидші пристрої — це корисно, але також спосіб замаскувати справжню проблему (зайві записи).

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

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

Компанія A керувала великою CI-флотилією. Все було «незмінним» за політикою: артефакти завантажувалися, тести виконувалися, результати відправлялися. Сховище було ZFS-пулом на SSD з комфортним запасом. Припущення було просте і розумне: «CI-рунери в основному читають; вони не зношуватимуть диски і не навалюватимуть пул.»

Через кілька тижнів збірки почали таймаутитись. Не постійно — достатньо, щоб підривати довіру розробників. Команда ганялася за звичайними підозрюваними: продуктивність реєстру, DNS, CPU steal на вузлах Kubernetes, мережеві втрати. Дашборди сховища показували в основному читання. Пул не мав помилок контрольних сум. SMART чистий. Усім було по-різному некомфортно.

Підказка була в записових IOPS, які не відповідали жодному відомому шляху запису. На ZFS-хості датасет, що містив кеші раннерів, мав atime=on. Кожне читання залежності під час збірок оновлювало час доступу сотень тисяч файлів. Навантаження не було «тільки читання». Це було «читання плюс метадані-записи». Під навантаженням синки TXG вирівнювалися з фазами тестування, роблячи хвостову латентність схожою на випадкові затримки обчислень.

Вони вимкнули atime для датасету кешу і нічого не перезавантажували. Таймаути зникли. Постмортем був коротким і трохи принизливим — теж корисним: мала зміна навчила їх сумніватися у «налаштуваннях за замовчуванням».

Міні-історія №2: Оптимізація, що відбилася бумерангом

Компанія B хостила мультиорендні вебзастосунки на кластері VM з ZFS. Вони стали кмітливими: розмістили «гарячі» датасети на швидких SSD-дзеркалах, а «холодні» — на масивному сховищі. Потім вирішили оптимізувати збір статистики, увімкнувши детальніший облік доступів до файлів. Деяка проміжна логіка хотіла atime для евікції кешу, тож вони широко включили atime=on.

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

Класика: оптимізація припустила, що atime — це «лише метадані» і отже дешева на SSD. Але atime-оновлення створили постійний потік дрібних, розсіяних записів, що заважали звичайному збігу записів у пулі. Гірше того, ці записи також збільшили фрагментацію метаданих. Через місяці навіть операції читання вимагали більше метаданих, які промахувалися повз ARC і зверталися до диска.

Вони перемістили кілька датасетів, яким реально потрібен був atime, на ізольовані пули з налаштованими параметрами й залишили решту з atime=off. Додавання заліза допомогло, але відключення марного навантаження допомогло більше. Урок: якщо не можете пояснити, навіщо потрібна функція, ви не оптимізуєте — ви додаєте змінну.

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

Компанія C мала змішане середовище: файлові шари, зберігання VM і кілька баз даних. У них була правило: кожен датасет має оголосити свій намір. VM-датасети отримують відомий набір властивостей. Файлові шари — інший. Усе «спеціальне» потребує тікета з обґрунтуванням. Здається бюрократією. Насправді це спосіб уникнути випадкової складності.

Коли нова команда додавала сервіс лог-аналітики, вони попросили датасет зі строгими POSIX-семантиками «на всяк випадок». Інженер зі зберігання запитав: «Визначте ваші реальні вимоги». Вони протестували й зʼясували, що сервіс не використовує atime взагалі; він використовує mtime і власний індекс. Датасет створили з atime=off, compression=on і recordsize, узгодженим з навантаженням.

Через шість місяців інше середовище з тим самим сервісом в іншому місці мало «повільно горючу» проблему: зростаюча латентність, фрагментація і періодичні синхронізаційні бурі. У Компанії C таких проблем не було. Їхні системи не були магічними; вони були нудними. Нудні налаштування, нудні базові лінії, нудні аудити.

Момент, що врятував день, не був героїчним пошуком помилок. Це була відсутність проблеми — бо вони мали профіль за замовчуванням, що її уникав.

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

Це послідовність «в мене 20 хвилин до дзвінка про інцидент». Не філософствуйте. Не налаштовуйте десять речей. Визначте домінуюче звуження і підтвердіть, чи є у грі churn через atime.

Перше: доведіть, що у вас проблема латентності сховища (не CPU/мережа)

1. Перевірте латентність на рівні застосунку проти латентності диска на хості. Якщо сплески латентності застосунку корелюють із латентністю vdev ZFS — це реальна проблема.
2. Шукайте черги: високі await і зростаючий aqu-sz вказують, що пристрій не встигає.

Друге: визначте, чи «читання викликає записи»

1. Перевірте властивість atime на гарячому шляху датасету.
2. Скореляйте навантаження читань із несподіваними write IOPS і активністю TXG sync.

Третє: вирішіть, чи вузьке місце в метаданих

1. Висока кількість операцій з метаданими, часті дрібні записи, ARC під тиском від метаданих: ви обмежені метаданими.
2. Якщо у вас є спеціальний vdev, перевірте, чи він перевантажений. Якщо ні — задумайтесь, чи варто його додавати, але тільки після вимкнення непотрібних atime-оновлень.

Четверте: виправте найменш ризикований крок першим

1. Вимкніть atime на датасетах, де він не потрібен.
2. Перевірте латентність і write IOPS через години, не дні.

Короткий жарт №2: Якщо ваш «тільки читання» сервіс робить 5,000 write IOPS, то сервіс або бреше, або ваша файлова система дуже ентузіастична.

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

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

Task 1: Find datasets with atime enabled

cr0x@server:~$ zfs get -r -o name,property,value,source atime tank
NAME                 PROPERTY  VALUE  SOURCE
tank                 atime     on     default
tank/vm              atime     off    local
tank/home            atime     on     inherited from tank
tank/ci-cache        atime     on     local

Що це означає: tank/home успадкував on. tank/ci-cache явно встановлено в on.

Рішення: Визначте, які з цих датасетів знаходяться на критичних шляхах продуктивності. Плануйте встановити atime=off для тих, кому це не потрібно.

Task 2: Confirm where the hot I/O is (dataset I/O)

cr0x@server:~$ zfs iostat -v tank 2 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        3.12T  1.88T    850   2100   110M   95.0M
  mirror                    3.12T  1.88T    850   2100   110M   95.0M
    nvme0n1                     -      -    430   1050  55.2M  48.0M
    nvme1n1                     -      -    420   1050  54.8M  47.0M
--------------------------  -----  -----  -----  -----  -----  -----

Що це означає: Записи високі відносно очікуваного. Цей вивід сам по собі не доводить atime, але показує реальний тиск записів.

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

Task 3: Check whether the dataset is mounted with the expected behavior

cr0x@server:~$ zfs get -o name,property,value,source mountpoint,canmount,atime tank/ci-cache
NAME          PROPERTY    VALUE             SOURCE
tank/ci-cache mountpoint  /tank/ci-cache    local
tank/ci-cache canmount    on                default
tank/ci-cache atime       on                local

Що це означає: Датасет змонтовано і він активно оновлює atime.

Рішення: Якщо застосунок не використовує atime, вимкніть його.

Task 4: Disable atime safely (dataset-level)

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

Що це означає: Нові доступи не оновлюватимуть метадані часу доступу в цьому датасеті.

Рішення: Застосуйте спочатку до найгірших датасетів. Уникайте змін у кореневих/системних датасетах, доки не впевнені, що нічого не залежить від семантики atime.

Task 5: Verify the change actually applied

cr0x@server:~$ zfs get -o name,property,value,source atime tank/ci-cache
NAME          PROPERTY  VALUE  SOURCE
tank/ci-cache atime     off    local

Що це означає: Властивість встановлена локально і збережеться.

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

Task 6: See if “read traffic” still triggers writes after the change

cr0x@server:~$ zpool iostat -v tank 1 5
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        3.12T  1.88T    900    420   120M   18.0M
  mirror    3.12T  1.88T    900    420   120M   18.0M
    nvme0n1     -      -    450    210  60.0M  9.1M
    nvme1n1     -      -    450    210  60.0M  8.9M

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

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

Task 7: Check pool health and errors (don’t skip this)

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 03:12:44 with 0 errors on Sun Feb  2 03:20:11 2026
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror    ONLINE       0     0     0
            nvme0n1 ONLINE       0     0     0
            nvme1n1 ONLINE       0     0     0

errors: No known data errors

Що це означає: Немає проблем цілісності. Добре — тепер робота з продуктивністю має сенс.

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

Task 8: Inspect ARC behavior and memory pressure (Linux OpenZFS)

cr0x@server:~$ arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:44:01   850    90     10    40   44    50   56     0    0   48G   64G
12:44:02   900    85      9    38   45    47   55     0    0   48G   64G
12:44:03   920    82      9    36   44    46   56     0    0   48G   64G

Що це означає: ~9–10% miss rate може бути прийнятним, але якщо промахи зростають під час навантаження, повʼязаного з метаданими, ви побачите звернення до диска й затримки.

Рішення: Якщо ARC постійно під тиском і промахи метаданих високі, подумайте, чи не витісняє корисний кеш metadata churn (наприклад, atime). Вимкнення atime — дешевий виграш.

Task 9: Measure TXG sync behavior (a proxy for “write pipeline stress”)

cr0x@server:~$ grep -i txg /proc/spl/kstat/zfs/txg | head
12 1 0x01 87 4224 1122334455 987654321

Що це означає: На Linux статистика txg може бути непрозорою; зазвичай ви використовуєте інструменти вищого рівня і корелюєте з zpool iostat та латентністю. Суть — шукати періодичні синхронізаційні сплески.

Рішення: Якщо бачите бурі записів, що збігаються зі сплесками латентності застосунку, спочатку зменшіть фоновий churn (atime), потім перевіряйте налаштування sync/журнальних пристроїв.

Task 10: Check dataset recordsize and workload alignment

cr0x@server:~$ zfs get -o name,property,value,source recordsize tank/vm tank/home
NAME      PROPERTY    VALUE   SOURCE
tank/vm   recordsize  16K     local
tank/home recordsize  128K    default

Що це означає: VM-датасети часто використовують менші блоки. Домашні директорії з багатьма дрібними файлами можуть бути ок навіть з 128K, але метадані все одно домінують, якщо atime увімкнено.

Рішення: Не женіться за recordsize перед тим, як усунути очевидні джерела churn. Налаштування recordsize не врятує від самостійно спричинених atime-записів.

Task 11: Confirm whether a dataset is used for databases or log-like workloads

cr0x@server:~$ zfs get -o name,property,value,source logbias,sync tank/db
NAME     PROPERTY  VALUE    SOURCE
tank/db  logbias   latency  default
tank/db  sync      standard default

Що це означає: За замовчуванням налаштування консервативні. Для баз даних ви можете мати навмисну поведінку sync. Це окремо від atime, але не переплутайте sync-латентність з atime.

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

Task 12: Identify whether the dataset is snapshot-heavy (space and churn visibility)

cr0x@server:~$ zfs list -t snapshot -o name,used,refer,mountpoint -s used | tail -n 5
tank/home@daily-2026-01-30     12.4G   220G  -
tank/home@daily-2026-01-31     13.1G   220G  -
tank/home@daily-2026-02-01     13.8G   220G  -
tank/home@daily-2026-02-02     14.2G   220G  -
tank/home@daily-2026-02-03     14.9G   220G  -

Що це означає: Зростання «used» у снапшотах може відображати churn у датасеті. atime-оновлення можуть додавати до churn, особливо в патернах метаданих, навіть коли вміст файлів не змінюється.

Рішення: Якщо зростання снапшотів дивне для «в основному читання» датасету, перевірте atime і інші поведінки, що змінюють метадані.

Task 13: Check pool free space (fragmentation accelerant)

cr0x@server:~$ zpool list tank
NAME   SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank  5.00T  3.12T  1.88T        -         -    38%    62%  1.00x  ONLINE  -

Що це означає: Фрагментація 38% і заповненість 62% не катастрофічні, але якщо CAP підніметься до 80–90%, розподіл алокацій стане більш розкиданим. atime-churn додає більше дрібних алокацій у цю кашу.

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

Task 14: Look at per-vdev latency (where the pain is)

cr0x@server:~$ zpool iostat -v tank -l 1 3
                              capacity     operations     bandwidth    total_wait     disk_wait
pool                        alloc   free   read  write   read  write   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----
tank                        3.12T  1.88T    920    480   125M   22.0M    2ms   18ms    1ms   16ms
  mirror                    3.12T  1.88T    920    480   125M   22.0M    2ms   18ms    1ms   16ms
    nvme0n1                     -      -    460    240  62.5M  11.1M    2ms   17ms    1ms   15ms
    nvme1n1                     -      -    460    240  62.5M  10.9M    2ms   19ms    1ms   17ms
--------------------------  -----  -----  -----  -----  -----  -----  -----  -----  -----  -----

Що це означає: Очікування запису значно вищі, ніж очікування читання, хоча навантаження виглядає «орієнтованим на читання». Це відповідає метаданим-сплескам записів.

Рішення: Якщо вимкнення atime зменшує write wait, ви підтвердили його причетність. Якщо ні — розслідуйте sync-записи, поведінку SLOG і насичення vdev.

Task 15: Validate dataset property inheritance (catch accidental defaults)

cr0x@server:~$ zfs get -r -o name,property,value,source atime tank/home
NAME                 PROPERTY  VALUE  SOURCE
tank/home            atime     on     inherited from tank
tank/home/users      atime     on     inherited from tank
tank/home/projects   atime     on     inherited from tank

Що це означає: Одна «нешкідлива» властивість у корені пулу може отруїти всі дочірні датасети.

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

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

1) «Наше навантаження, орієнтоване на читання, генерує купи записів»

Симптоми: Високі write IOPS під час піків читань; періодичні сплески записів; хвостова латентність.

Корінь: atime=on на гарячих датасетах; активність читань викликає записи метаданих.

Виправлення: Вимкніть atime на таких датасетах: zfs set atime=off pool/dataset. Перевірте зниження write IOPS.

2) «Продуктивність погіршилась поступово протягом місяців»

Симптоми: Те саме залізо, те ж навантаження, зростаюча латентність; більша варіативність; гірший 99p.

Корінь: Накопичений churn метаданих + фрагментація; atime — стабільне джерело churn.

Виправлення: Зупиніть churn (atime off), тримайте вільний простір на пулі, а якщо фрагментація серйозна — розгляньте міграцію через send/receive.

3) «Ми додали швидші диски і це майже не допомогло»

Симптоми: Оновлення заліза дає незначний ефект; сплески лишаються.

Корінь: Навантаження домінують дрібні випадкові метадані-записи; ви масштабували не ту вісь.

Виправлення: Приберіть непотрібні метадані-записи (atime), потім профілюйте залишкові вузькі місця (sync, special vdev, ARC).

4) «Снапшоти їдять простір на в основному читаному датасеті»

Симптоми: used у снапшоті зростає швидше, ніж очікувалось; користувачі наполягають «ми нічого не змінювали».

Корінь: Метадані-оновлення враховуються як зміни. atime-оновлення — це зміни.

Виправлення: Вимкніть atime; перегляньте частоту й збереження снапшотів. Не звинувачуйте користувачів у фізиці.

5) «Файлові шари NFS/SMB гальмують, але диски не завантажені»

Симптоми: Інтерактивна повільність; затримки в листингах каталогів; дрібні операції лагають.

Корінь: Операції метаданих чутливі до латентності; atime-оновлення додають записовий тиск, що проявляється як джиттер.

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

6) «Ми змінили atime і нічого не сталося»

Симптоми: Немає видимого покращення після вимкнення atime.

Корінь: Навантаження не було кероване atime, або інша налаштування домінує (sync-записи, маленький recordsize з sync, SLOG-проблеми, SMR-диски, погана прошивка).

Виправлення: Дотримуйтесь швидкого плану діагностики: перевірте латентність vdev, поведінку sync, промахи ARC і заповненість/фрагментацію. Не крутіть перемикачі без розслідування.

Чеклисти / покроковий план

Чеклист A: Визначте, де потрібен atime (зазвичай нікуди)

1. Перелік датасетів і поточний стан atime (zfs get -r atime).
2. Класифікуйте датасети за навантаженням: VM, DB, CI cache, домашні теки, бекапи, object store, шари.
3. Для кожного датасету відповідайте: «Що зламається, якщо atime буде off?» Якщо відповідь «не впевнений», ставте off і тестуйте.
4. Визначте кілька реальних споживачів atime (деякі поштові системи, старі backup/audit-скрипти, нішева логіка евікції кешу).
5. Документуйте винятки при створенні датасету.

Чеклист B: Безпечний план відкату для відключення atime

1. Виберіть один високонавантажений датасет (не root). Вимкніть atime.
2. Вимірюйте: write IOPS, vdev write wait, латентність застосунку і зростання снапшотів протягом 24 годин.
3. Катайте на подібні датасети пакетами.
4. Якщо є питання відповідності, перевірте, чи необхідні аудиторні сигнали не використовують atime (зазвичай не використовують).
5. Встановіть розумне значення батьків за замовчуванням для нових датасетів (зазвичай atime=off).

Чеклист C: Якщо пул уже деградував із часом

1. Спочатку зупиніть churn: atime off на гарячих датасетах.
2. Підтвердіть, що вільний простір пулу здоровий; плануйте розширення, якщо CAP високий.
3. Перевірте, чи метадані є вузьким місцем (промахи ARC, дрібні IO, високий write wait).
4. Якщо фрагментація серйозна і продуктивність все ще погана, розгляньте контрольовану міграцію send/receive на новий пул або іншу розкладку датасетів.
5. Лише потім оцінюйте додатки як special vdev для метаданих. Вони потужні, але не виправдання тримати atime увімкненим скрізь.

One operations quote (because it’s still true)

Парафразована ідея, приписувана Donald Knuth: Передчасна оптимізація може бути коренем багатьох проблем.

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

FAQ

1) Чи atime=on насправді «небезпечно»?

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

2) Якщо Linux має relatime, чи є подібне у ZFS?

ZFS експонує atime як властивість датасету (on/off). Деякі платформи мають додаткову поведінку, але операційно слід трактувати це як бінарний вибір і за замовчуванням ставити off, якщо не потрібно.

3) Які застосунки реально потребують atime?

Декілька: деякі поштові доставки і maildir-робочі процеси, певні backup/audit-скрипти, написані давно, і нішева логіка евікції кешу. Більшість сучасних систем використовує mtime, ctime, inotify-подібні механізми або власні метадані застосунку.

4) Чи вимкнення atime порушить POSIX?

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

5) Чи зменшить відключення atime зношення SSD?

Часто так, бо воно усуває клас записів. Наскільки це важливо — залежить від інтенсивності навантаження і витривалості SSD, але зменшення зайвих записів рідко шкідливе.

6) Чому деградація продуктивності проявляється «з часом», а не відразу?

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

7) Чи варто ставити atime=off на корінь пулу?

Зазвичай так — на топ-рівневих датасетах, які ви використовуєте як батьків для реальних навантажень. Потім явно вмикайте atime на рідкісних датасетах, де воно потрібно. Це запобігає випадковому успадкуванню дорогої поведінки.

8) Чи atime — єдина причина, через яку ZFS сповільнюється?

Ні. Тиск заповненості, фрагментація, шаблони sync-записів, невідповідний recordsize, відсутність special vdev для метаданих і поганий дизайн vdev можуть шкодити. atime — просто підступний фактор, бо ховається за «читанням».

9) Якщо у мене вже є special vdev для метаданих, чи можна тримати atime увімкненим?

Можна, але не варто за замовчуванням. Special vdev може поглинути I/O метаданих, але ви все одно генеруєте зайву роботу і збільшуєте churn. Вилікуйте причину спочатку, потім використовуйте special vdev для реальної інтенсивності метаданих.

10) Як швидко чекати покращення після вимкнення atime?

Часто в межах хвилин — годин у вигляді зменшених write IOPS і нижчих write wait. Довготривалі покращення (менше зростання фрагментації, рідші сплески) проявляються за днями — тижнями.

Висновок: що змінити в понеділок вранці

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

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

1. Інвентаризуйте датасети й знайдіть, де atime=on успадковано або встановлено локально.
2. Вимкніть atime на критичних по продуктивності датасетах, якщо не можете довести його потребу.
3. Повторно виміряйте write IOPS, латентність vdev і зростання простору снапшотів після зміни.
4. Стандартизуйте профілі властивостей датасетів, щоб не відтворити проблему через шість місяців під час «швидкого» створення ресурсу.

ZFS — машина надійності. Але вона безстрашно виконуватиме марну роботу, якщо ви її попросите. Не робіть цього.