Розмір SLOG у ZFS: скільки вам насправді потрібно (не «чим більше — тим краще»)

Що SLOG насправді робить (і чого не робить)

У ZFS ZIL (ZFS Intent Log) — це механізм, який робить синхронні записи безпечними. Якщо додаток просить,
щоб запис був підтверджений («sync»), ZFS має змогу відтворити цей запис після збою. За замовчуванням ZFS зберігає
ZIL на дисках пулу. Це працює, але може бути повільно, тому що змушує низьколатентні, дрібні, write-heavy I/O
накладатися на ті самі vdev, що виконують все інше.

SLOG (Separate LOG device) — це просто окреме місце для запису записів ZIL. Воно не зберігає ваші дані довгостроково.
Це не L2ARC. Це не магічний важіль «більше IOPS». Це спосіб перетворити «затримку sync-запису» з «що може зробити ваш пул під навантаженням»
на «що може швидко й надійно підтвердити ваш SLOG».

Ментальна модель, яка не підведе о 3:00

Думайте про sync-запис як про два кроки:

1. ZFS отримує запис і потребує надійної обіцянки, перш ніж ACK клієнту.
2. ZFS пізніше записує фактичні блоки в звичайний пул у складі коміту TXG.

З SLOG крок 1 стає «записати лог-запис у SLOG, виконати flush, відправити ACK». Крок 2 все ще відбувається в основному пулі
під час коміту TXG. SLOG потрібен, щоб зробити ACK швидким і безпечним; він не прискорює основну масову частину ваших steady-state записів.

Якщо ваше навантаження здебільшого асинхронне (бази даних з write-back, масові копії, інгест медіа), SLOG може майже не відігравати ролі.
Якщо навантаження синхронно-навантажене (NFS, iSCSI з write barriers, образи VM на NFS, бази з жорсткою довговічністю), SLOG може бути різницею між «нормально»
та «будь ласка, припиніть надсилати мені повідомлення».

Одна парафразована думка Вернера Фогельса (CTO Amazon), яка чудово підходить до розмірування SLOG: усе виходить з ладу; проектуйте так, щоб збій був нормальним, локалізованим випадком.
Ваш дизайн SLOG має припускати, що пристрій помре, бо це станеться згодом.

Цікаві факти та історичний контекст

• ZFS завжди мав ZIL; SLOG — опціональний. Ранні користувачі часто звинувачували ZFS у затримках sync, хоча насправді «шпінделі поводяться як шпінделі».
• Коміти TXG періодичні (зазвичай порядку секунд), тому ZIL зазвичай короткоживучий: це майданчик, а не сховище.
• «SLOG» — це розмовне скорочення; у ZFS говорять про «log vdev». Термін прижився, бо інженери зберігання даних люблять абревіатури так само, як коти люблять коробки.
• NFS зробив SLOG відомим, бо багато клієнтів NFS за замовчуванням використовують синхронну семантику для безпеки, особливо для datastore VM та інтенсивної метаданих діяльності.
• Power-loss protection (PLP) став визначальною характеристикою хороших SLOG-пристроїв, коли SSD стали достатньо швидкими і «затримка» випередила «пропускну здатність» як обмежуючий фактор.
• Ранні споживчі SSD брехали (іноді ненавмисно) про поведінку flush; тому поради щодо SLOG сильно схиляються до підприємницьких дисків з PLP.
• SLOG зазвичай крихітний у порівнянні з розміром пулу. У багатьох продакшен-системах десятки гігабайтів вже щедро.
• Дзеркальні SLOG-и стали звичними не тому, що ZFS не може впоратися з втратою SLOG (зазвичай може), а тому, що оператори ненавидять уникнути зайвих простоїв і страшних сигналів моніторингу.
• NVMe змінив розмову: вже не «чи можна зробити sync-записи терпимими?», а «як не дозволити швидкому пристрою приховувати повільний, перевантажений пул?»

Правило розмірування, яке витримає зіткнення з продакшеном

Ось незручна правда: розмір SLOG майже ніколи не про ємність. Це про затримку,
надійність і моделі записів. Ємність — останній пункт, і невеликий.

Що ви насправді розмірюєте

SLOG має бути достатньо великим, щоб вмістити невідкладні записи ZIL, які були підтверджені клієнтам, але ще не закомічені
в основний пул. Ці записи звільняються при синхронізації TXG. У стабільній системі ZIL не зростає безупинно; він коливається.

Практична формула розмірування виглядає так:

Потрібна ємність SLOG ≈ пікова стійка швидкість sync-записів × найгірший час до синхронізації TXG + накладні витрати.

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

Число, з якого більшість людей має починати

Для багатьох змішаних навантажень почніть із 16–64 GiB SLOG, дзеркально, якщо вам важливий час без відмов. Це не мем.
Це тому, що:

• TXG зазвичай комітить у порядку кількох секунд.
• Багато систем не тримають стійких multi-gigabyte-per-second sync записів; вони тримають це в async режимі.
• Вам потрібен запас на сплески і на випадок, коли «TXG sync уповільнився, бо пул зайнятий».

Якщо вам потрібно більше ніж 64–128 GiB для SLOG, я підозрюю, що ви намагаєтесь вирішити проблему пропускної здатності пулу за допомогою лог-пристрою.
Так люди купують дорогі пластирі для поламаних ніг.

Жарт №1: SLOG на 2 TB — це як встановити гелікоптерну площадку на каное — вражає на зустрічі, збираєздивка в воді.

Коли «більше» дійсно гірше

Деякі SSD стають повільнішими при тривалих дрібних записах, коли у них закінчується SLC-кеш або напружуються внутрішні таблиці відображення.
Великий споживчий диск може виглядати швидким у бенчмарку, але впасти під час реальних sync-штормів. Тим часом менший
підприємницький NVMe з PLP зберігає нудну стабільність. У зберіганні даних «нудний» — це комплімент.

Затримка — це реальний бюджет

Клієнтам байдуже, що ваш SLOG може робити 3 GB/s послідовних записів. Sync-записи зазвичай дрібні (4–128 KiB),
часто випадкові, і підпорядковані flush / FUA семантиці. Метрика, яка має значення — це 99-й процентиль затримки
при надійних записах.

Як виглядає «добре»

• Чудово: під 100 мікросекунд затримки на надійний запис на реальному PLP NVMe під навантаженням.
• Добре: кілька сотень мікросекунд до ~1 ms, стабільно.
• Погано: багатомілісекундні сплески, особливо періодичні (вони узгодяться з поведінкою TXG і тайм-аутами клієнтів).
• Жахливо: десятки чи сотні мілісекунд під час GC SSD або коли диск бреше про flush.

Чому пул все одно важливий

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

Навантаження: коли SLOG допомагає, а коли це косметика

Навантаження, що часто отримують вигоду

• NFS-датастори для віртуалізації, де гіпервізор робить sync-записи для безпеки VM.
• iSCSI з write barriers або файлові системи гостьових ОС, які часто викликають fsync.
• Бази даних із увімкненою довговічністю (часті fsync), особливо при дрібних комітах.
• Навантаження, насичені метаданими: багато операцій create/rename/fsync.

Навантаження, де SLOG зазвичай марний

• Велике послідовне інгестування (медіа, бекапи), яке асинхронне або може бути асинхронним.
• Аналітичні батчі, де записи буферизуються і рідко комітяться.
• Все, де sync=disabled (так, швидко; ні, не безпечно).

Пастка «sync write»: рішення ухвалює ваш додаток, а не ви

ZFS дотримується запитаної семантики. Якщо клієнт просить sync, ZFS буде робити sync. Якщо клієнт не просить — ZFS не буде.
Тому розмірування SLOG без спостереження за робочим навантаженням — це чиста астрологія продуктивності.

Вибір пристрою: те, що постачальники не рекламують

Негайні вимоги для реального SLOG-пристрою

• Power-loss protection (PLP): конденсатори або еквівалент, щоб flush був фактично надійним.
• Послідовна низька затримка при тривалих дрібних записах: не лише «пік IOPS».
• Витривалість: sync-шторм може спричиняти жахливе write-amplification; обирайте відповідно.
• Правильна поведінка flush/FUA: ви хочете, щоб пристрій дотримувався write barriers.

Який клас ємності купувати

Купуйте за затримкою й PLP, потім підберіть ємність, що покриває обчислену потребу з запасом. На практиці:

• 16–64 GiB ефективної потреби: зазвичай підходить enterprise SSD/NVMe 100–400 GB.
• Високий rate sync або довгі часи TXG sync: 400–800 GB дає запас, але не робіть з нього трофейний диск.
• Мульти-орендарне сховище для багатьох клієнтів: розгляньте дзеркальний NVMe SLOG зі стабільною затримкою, а не більшу ємність.

Чому споживчі SSD — погана ідея (навіть коли вони «працюють»)

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

Дзеркалити чи ні: математика надійності і операційна реальність

Втрата SLOG-пристрою зазвичай не призводить до втрати пулу. ZFS може повернутися до використання on-pool ZIL.
Але «зазвичай» не заспокоює, коли ви працюєте в продакшені.

Операційний вплив втрати одного SLOG залежить від реалізації й оточення:

• Продуктивність може впасти миттєво (sync-записи повертаються на диски пулу).
• Може знадобитися заміна апаратури під тиском.
• Деякі команди обирають аварійний простій, щоб відновити очікуваний профіль затримок, замість «лягати ногами».

Мій упереджений за замовчуванням: дзеркальте SLOG, якщо система обслуговує чутливих до затримки sync-клієнтів (NFS для VM, бази даних, спільне сховище).
Додаткові витрати зазвичай менші за вартість першої зустрічі на нараді після інциденту.

Жарт №2: Один диск SLOG у продакшені — це як одна ключ-карта для всього офісу: ефективно, поки хтось не впустить її в латте.

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

Єдине розмірування, яке має значення — це те, яке ви можете захистити вимірюваннями. Ось практичні завдання, які можна виконати сьогодні.
Кожне містить: команду, що означає вивід, і рішення, яке ви приймаєте.

Завдання 1: Визначити, чи має ваш пул SLOG і його топологію

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

        NAME                         STATE     READ WRITE CKSUM
        tank                         ONLINE       0     0     0
          raidz2-0                   ONLINE       0     0     0
            sda                      ONLINE       0     0     0
            sdb                      ONLINE       0     0     0
            sdc                      ONLINE       0     0     0
            sdd                      ONLINE       0     0     0
            sde                      ONLINE       0     0     0
            sdf                      ONLINE       0     0     0
        logs
          mirror-1                   ONLINE       0     0     0
            nvme0n1p1                ONLINE       0     0     0
            nvme1n1p1                ONLINE       0     0     0

errors: No known data errors

Значення: Є дзеркальний log vdev (SLOG), що використовує дві NVMe-розділи. Добре.
Якщо ви не бачите секції logs, ви використовуєте on-pool ZIL.

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

Завдання 2: Перевірити налаштування sync для датасету (тест «хтось щось хитрував?»)

cr0x@server:~$ sudo zfs get -o name,property,value -s local,inherited sync tank/vmstore
NAME         PROPERTY  VALUE
tank/vmstore sync      standard

Значення: standard шанує запити додатків. always примушує sync (часто повільніше),
disabled брешуть клієнтам (швидко, але небезпечно).

Рішення: Якщо ви знайдете sync=disabled на продакшен-віртуальних машинах або базах даних, трактуйте це як прийняття ризику,
а не як налаштування продуктивності.

Завдання 3: Підтвердити, що навантаження справді виконує sync-записи

cr0x@server:~$ sudo zpool iostat -v tank 1 5
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                         12.1T  43.7T    210    980  32.1M  88.4M
  raidz2-0                   12.1T  43.7T    210    780  32.1M  61.2M
    sda                          -      -     35    130  5.3M   9.9M
    sdb                          -      -     34    129  5.2M   9.8M
    sdc                          -      -     36    131  5.4M  10.0M
    sdd                          -      -     35    128  5.3M   9.7M
    sde                          -      -     35    131  5.3M  10.0M
    sdf                          -      -     35    131  5.3M  10.0M
logs                             -      -      0    200   0K   27.2M
  mirror-1                       -      -      0    200   0K   27.2M
    nvme0n1p1                    -      -      0    100   0K   13.6M
    nvme1n1p1                    -      -      0    100   0K   13.6M
--------------------------  -----  -----  -----  -----  -----  -----

Значення: Записи потрапляють у vdev logs. Це лог-трафік sync.
Якщо пропускна здатність логу близька до нуля, а клієнти скаржаться на затримки, ваше навантаження може бути переважно async або існує інша точка звуження.

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

Завдання 4: Подивитися затримку по датасетах з розширеним iostat (OpenZFS)

cr0x@server:~$ sudo zpool iostat -r -v tank 1 3
                              capacity     operations     bandwidth    total_wait     disk_wait
pool                        alloc   free   read  write   read  write   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----  ----- -----   ----- -----
tank                         12.1T  43.7T    220    990  33.0M  90.1M   2ms  24ms     1ms  20ms
  raidz2-0                   12.1T  43.7T    220    790  33.0M  62.0M   3ms  28ms     2ms  23ms
logs                             -      -      0    200   0K   28.1M    -    1ms      -    1ms
--------------------------  -----  -----  -----  -----  -----  -----  ----- -----   ----- -----

Значення: log vdev показує ~1 ms write wait, в той час як основний vdev значно гірший. Це очікувано: SLOG швидкий, пул повільніший.
Якщо write wait логу високий — ваш SLOG є вузьким місцем для ACK sync.

Рішення: Якщо write wait логу постійно вищий за прийнятний для додатка, замініть SLOG-пристрій (за затримкою), а не «збільшуйте ємність».

Завдання 5: Підтвердити ashift і вирівнювання пристрою (гігієна продуктивності)

cr0x@server:~$ sudo zdb -C tank | grep -E 'ashift|vdev_tree' -n | head
34:        vdev_tree:
58:                ashift: 12

Значення: ashift: 12 вказує на 4K сектора. Невирівнювання може спричиняти write amplification і сплески затримки.

Рішення: Якщо ashift невірний для ваших пристроїв — плануйте перебудову/міграцію. Ви не зможете «віднастроїти» неправильний ashift.

Завдання 6: Перевірити, чи пристрій SLOG підтримує стійкі записи (ознаки PLP)

cr0x@server:~$ sudo nvme id-ctrl /dev/nvme0n1 | egrep -i 'oncs|vwc|psd|mn'
mn      : INTEL SSDPE2KX040T8
oncs    : 0x001f
vwc     : 0x0001

Значення: vwc вказує на наявність Volatile Write Cache. Це не доводить PLP, але дає корисну підказку для інвентаризації.
Справжнє підтвердження — через модель і специфікацію виробника, але ви принаймні можете виявити явні невідповідності.

Рішення: Якщо ви не можете встановити впевненість у PLP — не використовуйте пристрій для SLOG у системі, де важлива коректність.

Завдання 7: Перевірити, чи TRIM/discard увімкнено і працює (стабільність затримок)

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

Значення: TRIM може допомогти steady-state поведінці SSD, зменшуючи довгострокові «прірви» затримки.
Це не інструмент розмірування SLOG, але змінює історію «через кілька тижнів стало повільно».

Рішення: Якщо ви на SSD/NVMe і платформа підтримує, розгляньте autotrim=on після тестування.

Завдання 8: Спостерігати поведінку TXG опосередковано через статистику ZFS (Linux)

cr0x@server:~$ grep -E 'sync|async|txg' /proc/spl/kstat/zfs/txg | head -n 20
1 0 0x01 4 336 64080000 2110536636251
name                            type data
birth                           4    174541
timeout                         4    5
synced                          4    174538
opened                          4    174540

Значення: timeout показує цільовий інтервал TXG (часто 5s). Якщо ваш пул не встигає sync TXG швидко,
«реальний» інтервал розтягується, і SLOG має тримати записи довше.

Рішення: Якщо TXG sync відстає під час піку — виправляйте пропускну здатність/затримку пулу; не просто збільшуйте SLOG.

Завдання 9: Захопити тиск sync-записів таргетованим fio-тестом (обережно)

cr0x@server:~$ sudo fio --name=sync4k --directory=/tank/test --rw=randwrite --bs=4k --iodepth=1 --numjobs=1 --size=1G --fsync=1 --runtime=20 --time_based --group_reporting
sync4k: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
fio-3.33
Starting 1 process
sync4k: Laying out IO file (1 file / 1024MiB)
Jobs: 1 (f=1): [w(1)][100.0%][w=580KiB/s][w=145 IOPS][eta 00m:00s]
sync4k: (groupid=0, jobs=1): err= 0: pid=14219: Fri Dec 26 12:14:21 2025
  write: IOPS=148, BW=594KiB/s (608kB/s)(11.6MiB/20s)
    lat (usec): min=820, max=9980, avg=1420.53, stdev=401.11
    clat percentiles (usec):
     |  1.00th=[  950],  5.00th=[ 1057], 10.00th=[ 1106], 50.00th=[ 1369]
     | 90.00th=[ 1795], 95.00th=[ 1975], 99.00th=[ 2474], 99.90th=[ 5866]

Значення: Цей тест виконує дрібні записи з fsync. Важливі percentiles затримки.
Якщо 99-й процентиль — кілька мілісекунд, VM і бази відчують «фризи».

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

Завдання 10: Переконатися, що SLOG справді використовується шляхом властивостей датасету

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

Значення: logbias=latency підштовхує ZFS використовувати SLOG для sync-поведінки. throughput може зменшити залежність від SLOG у деяких патернах.

Рішення: Для VM/NFS/баз даних, де важлива затримка sync — тримайте logbias=latency. Не сприймайте це як «включити і стане швидше» без підтверджень.

Завдання 11: Перевірити періодичні затримки і корелювати з системною I/O затримкою

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

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
sda              5.2   120.1    0.30    9.50      164.3     7.20   58.30     9.10    60.40   0.95  99.1
nvme0n1          0.0    98.0    0.00   12.80       267.0     0.10    1.05     0.00     1.05   0.08   0.9

Значення: Магнітні диски завантажені ~99% з ~60 ms await і тягнуть TXG sync часом.
NVMe в порядку; вузьке місце — vdev пулу.

Рішення: Якщо диски пулу завантажені, виправляйте макет vdev, додавайте vdev або зменшуйте write amplification. Більший SLOG не змінить того, що sda горить.

Завдання 12: Перевірити тиск ARC (щоб не звинувачувати SLOG у проблемах пам’яті)

cr0x@server:~$ sudo arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:15:01  3120   210      6   180   5     20   1    10   0   112G   128G
12:15:02  2980   260      9   225   8     25   1    10   0   112G   128G
12:15:03  3410   240      7   210   6     20   1    10   0   112G   128G

Значення: Якщо ARC трясеться і misses стрибнули, ви можете бути звужені по читанню, а не по sync-записах.
SLOG тут не допоможе.

Рішення: Якщо miss% високий і затримки викликані читаннями — налаштуйте пам’ять/ARC, додайте RAM або перегляньте recordsize/special vdev рішення.

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

cr0x@server:~$ sudo zpool get -H -o property,value ashift,autotrim,listsnapshots,autoreplace tank
ashift	12
autotrim	on
listsnapshots	off
autoreplace	off

Значення: Не прямо розмірування SLOG, але це показники базової операційної наміри. autoreplace off — поширено; просто переконайтесь, що у вас є план заміни.

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

Завдання 14: Симулювати вплив видалення SLOG (вікно планового техобслуговування)

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

        NAME                         STATE     READ WRITE CKSUM
        tank                         ONLINE       0     0     0
          raidz2-0                   ONLINE       0     0     0
            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
        logs
          nvme1n1p1                  ONLINE       0     0     0

errors: No known data errors

Значення: Ви видалили одну сторону дзеркала; працюєте без дзеркалення. Це контрольований спосіб перевірити, наскільки ви залежите від SLOG.

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

Швидка інструкція діагностики

Коли користувачі кажуть «сховище повільне», вони описують симптом. Ваше завдання — знайти, який підсистем бреше.
Ось швидка, продакшен-класу послідовність, яка швидко знаходить вузькі місця, пов’язані з SLOG.

1) Підтвердьте, що це дійсно затримка sync

• Перевірте, чи використовує уражений датасет NFS/iSCSI/VMs/бази даних.
• Запустіть zpool iostat -v і подивіться, чи записи потрапляють у logs.
• Перевірте властивість датасету sync на предмет сюрпризів.

2) Вирішіть: SLOG повільний чи пул повільний?

• Якщо vdev логу показує високу write wait: ваш SLOG — фактор, що обмежує.
• Якщо log vdev швидкий, але диски пулу мають високі await/%util: пул не встигає sync TXG.
• Якщо ні те, ні інше: підозрюйте клієнт/мережу, налаштування NFS або поведінку додатка (fsync-шторм).

3) Знайдіть періодичність і корелюйте

• Шукайте сплески кожні кілька секунд (ритм TXG) або хвилин (GC SSD або задачі зі знімками).
• Корелюйте з iostat -x і ZFS zpool iostat -r за затримками.

4) Перевірте клас SLOG-пристрою

• Підтвердьте модель з PLP (інвентар + інформація контролера).
• Перевірте на прошивки з відомими проблемами, термальне тротлінг і проблеми з PCIe-слотом (NVMe може знижувати швидкість).

5) Лише після цього говоріть про розмір

Якщо ви не можете показати, що ZIL заповнюється понад поточну ємність SLOG між TXG sync, «більший SLOG» — це суєрстична міра.
Виправте затримку, пропускну здатність пулу, семантику sync. Розмір — останній.

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

1) VM datastore зависає на 1–5 секунд, потім відновлюється

Симптом: періодичні затримки, часто узгоджені з вибухами метаданих.

Корінна причина: TXG sync триває занадто довго, бо vdev пулу насичені; SLOG прискорює шлях ACK, але не може врятувати потопаючий пул.

Виправлення: додати vdev, перейти на дзеркала для IOPS, зменшити write amplification (recordsize, volblocksize, compression), або розділити навантаження. Перевірте за допомогою iostat -x.

2) SLOG «допомагає» тиждень, потім затримки дивакують

Симптом: поступове зростання sync-затримки, час від часу огидні сплески.

Корінна причина: споживчий SSD у steady-state колапс (GC, виснаження SLC-cache), відсутність TRIM або термальний троттлінг.

Виправлення: замінити на PLP enterprise-пристрій; увімкнути autotrim=on, якщо доречно; моніторити температури NVMe і стан PCIe.

3) Відмова SLOG призводить до простою «бо ми злякалися»

Симптом: пул лишається online, але продуктивність падає в прірву; команда вирішує влаштувати простій.

Корінна причина: нездзеркалений SLOG, що обслуговує критичне sync-навантаження; відмова переводить sync-трафік назад у пул.

Виправлення: дзеркалити SLOG; тримати запасні пристрої; відпрацювати заміну; налаштувати оповіщення про деградацію log vdev.

4) «Ми додали великий SLOG і нічого не змінилося»

Симптом: та сама пропускна здатність, ті самі скарги на затримку.

Корінна причина: навантаження здебільшого async, або вузьке місце — читання, мережа, CPU, або пропускна здатність запису пулу.

Виправлення: виміряйте активність log vdev; перевірте ARC misses; підтвердіть налаштування NFS/клієнтів; профілюйте fsync-поведінку додатка перед зміною заліза.

5) Неконсистентність даних після відключення живлення

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

Корінна причина: SLOG-пристрій без реального PLP, який підтверджував записи прематурально.

Виправлення: використовувати тільки enterprise PLP-пристрої; не покладатися на «UPS врятує» як на стратегію довговічності; перевіряти політику щодо семантики sync.

6) SLOG швидкий, але sync-записи все одно повільні

Симптом: затримки log vdev виглядають низькими, але клієнти бачать високі часи коміту.

Корінна причина: додаток робить додаткові fsync, налаштування NFS сервер/клієнт примушують sync, або домінує мережна затримка.

Виправлення: перевірте параметри монтирування клієнтів, налаштування експорту NFS, налаштування довговічності бази; вимірюйте end-to-end затримку, а не лише диск.

Три корпоративні історії з полі бою

Інцидент через хибне припущення: «SLOG — це write cache»

Середня SaaS-компанія використовувала ZFS для внутрішнього кластера віртуалізації. Команда зберігання додала «великий швидкий NVMe» як SLOG,
бо в документації procurement написано «write cache for ZFS». Це був споживчий диск, але графіки бенчмарків були чудові.

Кластер одразу відчув покращення. Тікети сповільнились. Команда проголосила перемогу і перейшла далі. Через два місяці один рафт відчув відключення живлення.
UPS захистив більшість серверів, але один storage head впав. Після перезавантаження пул імпортувався. Видимих помилок ZFS не було.
Але команда бази даних почала повідомляти про порушені інваріанти: підтверджені гостями транзакції зникли.

Постмортем був жорстким, бо ZFS «виглядала здоровою». Відмова була семантичною: SLOG-пристрій підтвердив flush, який не був фактично стійким.
ZFS зробила те, що попросили; пристрій збрехав про виконання.

Виправлення було нудним, але правильним: PLP NVMe для SLOG, дзеркалення, і політика, що забороняє споживчі диски в write-ack path.
Також вони перестали називати SLOG «кешем» у внутрішній документації. Слова важливі. Неправильне слово створює неправильну модель, яка виписує чеки,
які ваші дані не зможуть оплатити.

Оптимізація, що відбилася назад: примусове sync=always «щоб користуватись SLOG»

У великому підприємстві команда помітила, що їхній блискучий SLOG майже не мав трафіку в робочий час. Хтось вирішив, що SLOG «марнується»
і застосував sync=always до основного NFS-датасету, щоб виправдати залізо. Зміна потрапила під час «жорсткої» ітерації по зберіганню з добрими намірами, але без достатнього скептицизму.

За день відгуки додатків стали джиттерними. Не катастрофічно повільно — гірше. Перервчасто. Команди шукали DNS, потім балансувальники, потім версії ядра,
бо графіки продуктивності виглядали «нормально» у середніх величинах.

Справжня проблема була самонаведеною: навантаження, які раніше писали async (і були на те розраховані), тепер були примушені до sync-семантики.
SLOG з охотою прийняв потік дрібних комітів, а пул мусив їх поглинути на TXG sync. Хвостова затримка зросла по всій системі.
Зміна також збільшила write amplification і знос SSD.

Відкот до sync=standard стабілізував затримки миттєво. SLOG залишили, бо NFS-метадані і певні клієнти виграли від нього.
Але урок закріпився: не примушуйте семантику довговічності, щоб «використати» куплений пристрій. Спочатку зробіть систему правильною, потім пришвидшуйте там, де це важливо.

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

Фінансова фірма використовувала ZFS-backed NFS для кластера, що обробляв чутливі до часу батчі. Дизайн зберігання був непомітний:
дзеркальний SLOG на PLP SSD, оповіщення підключені до on-call, і квартальні тренування, де симулювали відмову лог-пристрою.

Одного кварталу лог-пристрій почав кидати media errors. Моніторинг спрацював. On-call замінив його у робочий час без драм, бо все було відпрацьовано.
Продуктивність майже не змінилась, бо лог був дзеркалений і пережив залишковий пристрій.

Підсумок: ніхто поза інфраструктурою не помітив нічого. Це успіх у операціях: відсутність історій.
Команда написала внутрішню пам’ятку, оновила руківник і перевірила версії прошивок по парку.

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

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

Крок за кроком: як правильно розмірювати і розгортати SLOG

1. Підтвердьте, що навантаження sync-навантажене.
   Використовуйте zpool iostat -v у піковий час. Якщо логи показують активність — ви в SLOG-території.
2. Виміряйте прийнятну затримку.
   Для VM і баз даних прагніть стабільної підмілісекундної затримки на стійкий запис, якщо можливо.
3. Оціни ємність.
   Піковий rate sync × найгірший час TXG sync × накладні витрати. Якщо ви не знаєте rate — виміряйте.
4. Виберіть клас пристрою спочатку, розмір — потім.
   PLP enterprise SSD/NVMe, стабільна затримка, адекватна витривалість. Уникайте споживчих компонентів у write-ack шляху.
5. Дзеркальте для продукції.
   Особливо якщо сховище обслуговує багато клієнтів або у вас жорсткі вікна обслуговування.
6. Розділіть свідомо.
   Використовуйте виділений розділ для SLOG, якщо потрібно, але не діліть пристрій з випадковими робочими навантаженнями.
7. Додайте чисто.
   Переконайтесь, що zpool status показує його під logs.
8. Підтвердіть покращення тестами sync.
   Використовуйте безпечні fio-тести на некритичному датасеті або в плановому вікні. Порівнюйте хвостову затримку, а не лише середні значення.
9. Налаштуйте моніторинг здоров’я log vdev і затримки.
   Сигналізуйте про помилки пристрою, деградацію і значні зміни у log vdev wait times.
10. Відпрацюйте відмову.
    Практикуйте заміну лог-пристрою. Якщо ви не можете зробити це спокійно — ви ще не підготовлені.

Чек-лист для закупівлі (роздрукуйте це перед тим, як хтось купить «швидкий SSD»)

• PLP: так, задокументовано.
• Стабільна затримка випадкових записів у steady-state: послідовна, а не лише пікові бенчмарки.
• Рейтинг витривалості відповідний очікуваному sync-обсягу.
• Прошивка зріла і відома як хороша у вашій ОС/ядері.
• Терміка: не буде тротлити у вашому шасі.
• Форм-фактор і інтерфейс: NVMe зазвичай кращий для затримки; SAS може бути прийнятним, якщо стабільний.
• Бюджет на дзеркалення включено.

FAQ

1) Чи зробить більший SLOG ZFS швидшим?

Зазвичай — ні. Розмір SLOG рідко має значення, коли він вже «достатній». Важливі затримка і довговічність. Якщо продуктивність покращується з більшим SLOG,
часто це означає, що ваш TXG sync займає забагато часу і ви тимчасово буферизуєте більше даних — не вирішуючи кореневої причини.

2) Як дізнатися, чи моє навантаження використовує SLOG?

Запустіть zpool iostat -v під час навантаження і перевірте, чи vdev logs показує операції/пропускну здатність.
Якщо близько до нуля — ваше навантаження не виконує багато sync-записів або вони не проходять через цей шлях пулу.

3) Чи SLOG те саме, що L2ARC?

Ні. L2ARC — це кеш для читань. SLOG — для ZIL, що стосується стійких підтверджених sync-записів після збою.
Змішувати ці поняття в голові — шлях до покупки неправильного заліза.

4) Що станеться, якщо SLOG-пристрій помре?

Зазвичай пул лишається online і ZFS повертається до використання in-pool ZIL, але продуктивність sync-записів може сильно впасти.
Операційно очікуйте оповіщень і потенційних видимих для клієнтів змін у затримці.

5) Чи слід дзеркалити SLOG?

Якщо вам важливі стабільна затримка і uptime для sync-навантажень: так. Якщо це лабораторний стенд або не критична система: можливо ні.
Але розумійте, яку ризик/зручність ви вибираєте — це не лише «зекономити відсік».

6) Чи можна використовувати розділ великого NVMe як SLOG?

Так, але не діліть цей NVMe з іншими навантаженнями, які можуть ввести латентні сплески. Контенція руйнує сенс виділеного SLOG.
Якщо розділяєте — тримайте пристрій присвяченим ролям ZFS.

7) Чи sync=disabled усуває потребу в SLOG?

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

8) Чи logbias=throughput швидший за logbias=latency?

Може бути, залежно від патернів записів, але це не безкоштовний виграш. Для клієнтів, чутливих до затримки sync, latency зазвичай краще.
Змінюйте лише з вимірюваннями і планом відкату.

9) Який розумний розмір SLOG для Proxmox або хостів VM на NFS?

Зазвичай 16–64 GiB ефективної потреби, реалізовані як дзеркальна пара PLP NVMe 100–400 GB. Якщо ви спостерігаєте стійкі високі sync-rate
і повільні TXG sync — коригуйте, але перевірте, що ви не приховуєте вузьке місце пулу.

10) Чи може швидкий SLOG приховувати повільний пул?

Коротко — так. Він може зробити ACK-и швидкими, поки пул все ще борсається з комітами TXG. Зрештою система отримає зворотний тиск.
Якщо пул хронічно насичений — виправляйте дизайн пулу.

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

Розмірюйте SLOG як оператор, а не як колекціонер. Ви хочете пристрій, який може швидко, правильно і стабільно підтверджувати sync-записи —
і ємність, що покриває сплеск між TXG sync з запасом. Ось і все.

Наступні кроки, що дійсно змінюють ситуацію:

1. Виміряйте, чи sync-записи — це проблема (zpool iostat -v, властивість датасету sync, fio fsync-тести у безпечному вікні).
2. Якщо sync-записи обмежують — купуйте за PLP + стабільність затримки, а не за розміром. Дзеркальте, якщо цінуєте uptime.
3. Якщо TXG sync повільний — припиніть шукати SLOG і переробіть пул для write IOPS/пропускної здатності.
4. Напишіть руківник на випадок відмови log vdev і відпрацюйте його хоча б раз. Ваше майбутнє «я» буде вдячне.