ZFS: Використання NVMe як SLOG — коли це ідеально і коли надмірно

SLOG в одній фразі (і чому це важливо)

SLOG — це виділений пристрій для ZFS‑ових записів ZIL, який прискорює синхронні записи, швидко й безпечно підтверджуючи намір запису без очікування основного пулу.

Прочитайте ще раз і підкресліть «синхронні». Якщо ваше навантаження переважно асинхронні записи, читання або навантажене CPU, NVMe як SLOG — дорогий плацебо. Якщо навантаження визначається затримкою синхронних записів (NFS із sync, ESXi датастори, деякі бази даних, деякі VM‑навантаження), хороший SLOG — це чит‑код.

Також: у ZFS вже є ZIL навіть без SLOG. За замовчуванням ZIL живе на дисках пулу. Додавши SLOG, ви не «увімкнете журнал», ви переміщаєте гарячу частину шляху синхронного запису на щось швидше (і бажано надійніше).

Що SLOG справді прискорює (і чого ніколи не прискорить)

Шлях синхронного запису простою мовою

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

Без SLOG ці ZIL‑записи потрапляють на ті самі vdev, що й ваші дані. З SLOG ці записи потрапляють на пристрій журналу натомість, який може мати значно нижчу затримку, ніж RAIDZ на HDD або навіть SATA SSD.

Чого допомагає SLOG

• Затримка синхронного запису: те, що клієнти відчувають як «мій VM лагає» або «NFS відчувається тягучим».
• IOPS для синхронних записів: особливо багато дрібних операцій із fsync.
• Контенція на vdev пулу: переміщення трафіку ZIL може зменшити довільний write‑тиск на основний пул під час синхронних піків.

Чого SLOG не допоможе

• Читання (це роль ARC, L2ARC і розмітки vdev).
• Асинхронні записи (ZFS буферизує їх у RAM і скидає по межах TXG; SLOG не на цьому критичному шляху).
• Послідовна пропускна здатність (це здебільшого пропускна здатність vdev).
• Навантеження, обмежені CPU (контролювання контрольної суми, стиснення, шифрування або просто переповнений хост).

Сухий факт: SLOG не зробить погану розмітку пулу кращою. Він може зробити синхронні записи менш болісними, поки ви плануєте кращу розмітку.

Жарт №1: Купувати SLOG для асинхронного навантаження — як ставити турбіну на припаркований автомобіль. Це вражаюче обладнання, але машина так і не поїде.

Коли NVMe як SLOG — ідеальний варіант

1) Експорти NFS, де клієнти вимагають sync‑семантики

Багато NFS‑клієнтів (та адміністраторів) наполягають на безпечних записах, і NFS часто використовується для даних, чутливих до втрат: VM‑датастори, сховища артефактів збірки, домашні директорії з «мій редактор викликає fsync» тощо.
Якщо ваш експорт налаштовано на sync (або поведінка клієнта фактично примушує sync), затримка підтвердження цих ZIL‑записів — це ваш користувацький досвід.

Це канонічний випадок виграшу від SLOG: пул на HDD (або RAIDZ зі SSD) що обслуговує NFS зі стабільним fsync‑трафіком. Поставте низьколатентний NVMe з PLP перед цим, і ви відчуєте різницю.

2) Сховище віртуалізації з багатьма дрібними синхронними записами

Платформи VM і файлові системи гостьових ОС генерують синхронні записи частіше, ніж здається. Журнали, оновлення метаданих, зброси баз даних у VM, поведінка гостьової ОС та налаштування на рівні застосунків накопичуються.
Добрий SLOG може перетворити «рандомні 8K синхронні записи з затримкою 10–20ms» в «субмілісекундні до кількох мілісекунд», що є різницею між «нормально» і «чому UI зависає».

3) Бази даних, які справді покладаються на fsync()

Деякі бази даних домінуються затримкою підтвердження коміта. Якщо база налаштована правильно для вимоги надійності (і ви цього хочете), ви в синхронній зоні.
Швидкий, безпечний SLOG може зменшити варіацію часу комітів — саме варіація викликає спайки p‑tail затримок і помітні зупинки для користувачів.

4) У вас повільний основний пул, який ви ще не можете перебудувати

Інколи ви успадковуєте пул «RAIDZ2 на nearline HDD», бо хтось оптимізував витрати за ТБ і забув, що затримка — теж витрата.
NVMe SLOG може бути тактичною пластиркою: він зменшить біль для синхронних споживачів, поки ви плануєте реальну правку (більше vdev, дзеркала, special vdev або зовсім інша архітектура).

5) Вам потрібна передбачувана надійність під навантаженням

Найкращі SLOG‑пристрої не лише швидкі; вони стабільні. Продуктивність синхронних записів — це не тільки середнє значення, а й хвостова затримка.
Побутові SSD можуть виглядати чудово, поки не сядуть у внутрішню GC або на «write cliff», і тоді ваш «надійний запис» раптом займає 50ms. Користувачі це помічають.

Коли SLOG — це надмір

1) Ваше навантаження переважно асинхронні записи

Копіювання файлів, імпорт медіа, резервні копії, що стримлять послідовно, записи об’єктного сховища, що батчаться, аналітичні конвеєри — ці сценарії зазвичай не блокуються на sync‑комітах.
ZFS поглине багато цього в ARC і скине по межах TXG. SLOG тут не потрібен.

2) Ви насправді прив’язані до читань або метаданих

Класична хибна діагностика: «зберігання повільне», коли вузьке місце — промахи кешу, замало vdev або метадані розкидані по HDD.
Можливо, вам потрібні більше дзеркал, special vdev для метаданих/малих блоків, більше RAM для ARC або тонке налаштування recordsize. Ніщо з цього — не SLOG.

3) Ви можете (і маєте) виправити вимогу sync політикою

Іноді правильний крок — це політика, а не залізо: чи справді вам потрібен sync для цього датасету? Ви експортуєте NFS з sync тому, що «так завжди робили», хоча дані не критичні й уже репліковані?
Якщо ви можете допускати невелику втрату при збої, встановлення sync=disabled для правильного датасету дає більший приріст, ніж будь‑який SLOG. Але це підвищує ризик. Не робіть цього необачно.

4) У вас немає захисту від втрати живлення — ви «швидкі, але брешете»

Уся робота SLOG — забезпечити безпеку синхронних записів. Якщо ваш пристрій обманює у відповіді на flush або втрачає дані при відключенні живлення, ви можете почати підтверджувати надійні записи, які фактично не збереглися. Це не помилка продуктивності. Це корупція з хорошим маркетингом.

5) Ваш пул уже достатньо швидкий для sync

Якщо у вас all‑SSD дзеркальний пул з доброю затримкою і вузьке місце по sync вже мале, маргінальні виграші від SLOG можуть бути важко виправдані.
Виміряйте спочатку. Якщо p99 sync‑затримка вже у низьких одиничних мілісекундах і користувачі не скаржаться, у вас є кращі місця для витрат вашого бюджету складності.

Цікаві факти та історія, що впливають на рішення

1. ZFS народився в Sun у середині 2000‑х з явним фокусом на цілісність даних: контрольні суми, copy‑on‑write і транзакційні семантики не були другорядними думками.
2. ZIL існує в кожному пулі, незалежно від того, додаєте ви SLOG чи ні. «Окремий» — опціональний; журнал намірів — ні.
3. Записи SLOG зазвичай короткоживучі: записи ZIL потрібні для відновлення після збою, не як довготривалий журнал типу ext4. Їх відкидають після коміту TXG.
4. Ранні поради «SSD як журнал» походять із ери, коли пули на HDD були звичними, а SSD — дорогими; різниця в продуктивності для синхронних записів була величезною й очевидною.
5. Захист від втрати живлення (PLP) став поділом між «споживчий SSD здається ок» і «підприємницький SSD правильно поводиться». Коректність ZIL залежить від чесної поведінки flush.
6. SLOG не потребує великої ємності, бо йому потрібно тримати лише невелике вікно незавершених синхронних записів — зазвичай секунди — до коміту TXG.
7. Дзеркалення SLOG — про доступність, а не швидкість: якщо SLOG виходить з ладу, пул продовжує працювати, але ви втрачаєте швидкий шлях для sync‑записів (і може виникнути ризик під час заміни).
8. NVMe змінив розмову, зробивши низьку затримку доступною, але це також спростило купівлю невідповідного пристрою: споживчий NVMe швидкий, але PLP і стабільність затримки — складніші питання.
9. sync=disabled у ZFS має репутацію, бо може зробити бенчмарки героїчними, змінюючи гарантії надійності. Це не безкоштовний обід; це інший контракт.

Потреби в апаратурі: затримки, PLP, витривалість і чому «швидко» недостатньо

Затримка важливіша за пропускну здатність

Продуктивність SLOG визначається тим, як швидко пристрій може зафіксувати дрібні записи і безпечно їх скинути. Вам важливі:
низька затримка запису, низька затримка flush і стабільна хвостова затримка. Пристрій, що робить 7GB/s послідовних записів, але зависає на flush — поганий SLOG.

PLP — невід’ємна умова для серйозних синхронних навантажень

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

Чи можна використовувати споживчий NVMe як SLOG? Так. Чи слід це робити для критичних синхронних навантажень? Ні, якщо ви не хочете пояснювати інцидентній групі, чому «надійний коміт» зник. Використовуйте відповідний інструмент.

Витривалість важлива, але не настільки, як бояться

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

Форм‑фактор і підключення мають значення в експлуатації

U.2/U.3 або корпоративні M.2 з належним охолодженням і моніторингом простіше експлуатувати в продакшні, ніж випадкова споживча паличка, схована під GPU.
Також подумайте про hot‑swap і як ви заміните його о 2 ранку, не перетворивши «заміна лог‑пристрою» на повноцінне вікно технічного обслуговування.

Парафраз: Werner Vogels: Ви проектуєте системи, припускаючи, що речі ламаються; надійність приходить від очікування відмов і швидкого відновлення.

Розмір, дзеркалення та топологічні вибори

Якого обсягу має бути SLOG?

Менший, ніж ви думаєте. SLOG потрібен лише для поглинання максимального обсягу незавершених синхронних записів між комітами TXG.
Таймаут TXG за замовчуванням зазвичай близько 5 секунд. Навіть якщо у вас сотні MB/s синхронних записів, потрібний простір журналу не величезний.
На практиці 8–32GB ефективного простору часто достатньо; люди ставлять 100–400GB бо такою є ємність SSD, а не тому що ZFS цього потребує.

Але не шкодуйте запасу. Залиште запас для сплесків і пам’ятайте, що продуктивність погіршується, якщо пристрій майже повний або сильно фрагментований всередині.

Дзеркаліть SLOG, якщо простої або ризик дорогоцінні

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

Не плутайте «log vdev» зі «special vdev»

SLOG призначений для ZIL (записи намірів). Special vdev — для метаданих і малих блоків (і може кардинально покращити продуктивність HDD‑пулів з великою кількістю I/O по метаданих).
Вони вирішують різні проблеми. Купити SLOG, коли вам потрібен special vdev — класична дорога помилка.

Розділення пристрою на партиції для SLOG можливе — але часто погана практика

Так, можна розбити NVMe і використовувати маленький слайс як SLOG. Ні, не робіть так необачно в продакшні.
Змішування навантажень на одному пристрої підвищує варіацію і ускладнює домени відмов. Якщо потрібно, ізолюйте через окремі пристрої і тримайте поведінку SLOG передбачуваною.

Жарт №2: Розбивати один споживчий NVMe на «SLOG + L2ARC + swap» — це як використовувати один парашут для двох людей: креативно, але приземлення стає дивним.

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

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

Завдання 1: Підтвердити, чи у вас взагалі є SLOG (і який саме)

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

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
            sdc                     ONLINE       0     0     0
            sdd                     ONLINE       0     0     0
        logs
          nvme0n1p1                 ONLINE       0     0     0

errors: No known data errors

Що це означає: У вас є log vdev (logs) на nvme0n1p1.

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

Завдання 2: Перевірити налаштування sync для датасету (контракт навантаження)

cr0x@server:~$ zfs get -r sync tank/vmstore
NAME          PROPERTY  VALUE  SOURCE
tank/vmstore  sync      standard  local

Що це означає: Поведінка sync за замовчуванням («шанувати запити застосунку на sync»).

Рішення: Якщо тут disabled, ваш SLOG, ймовірно, мало допоможе, бо ви наказали ZFS ігнорувати sync‑семантику. Якщо always, ви примусово навантажили шлях SLOG — можливо навмисно, можливо ні.

Завдання 3: Перевірити, як налаштовано NFS‑експорт (sync vs async)

cr0x@server:~$ cat /etc/exports
/tank/vmstore 10.10.0.0/24(rw,sync,no_subtree_check)
/tank/media   10.10.0.0/24(rw,async,no_subtree_check)

Що це означає: vmstore — sync (SLOG релевантний). media — async (SLOG переважно не релевантний).

Рішення: Сконцентруйте зусилля SLOG там, де потрібний sync. Не намагайтеся «оптимізувати» async‑експорти SLOG і дивуватися, чому нічого не змінилося.

Завдання 4: Подивитися, чи навантаження взагалі генерує синхронні записи

cr0x@server:~$ arcstat.py 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:10:01   222    12      5     2    1    10    4     0    0   42G   64G
12:10:02   240    14      5     3    1    11    4     0    0   42G   64G
12:10:03   230    11      4     2    1     9    4     0    0   42G   64G

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

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

Завдання 5: Спостерігати затримки ZFS і перевірити, чи саме записи проблема

cr0x@server:~$ zpool iostat -v tank 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        20.1T  10.4T    120    980  1.2M  38.4M
  raidz2-0  20.1T  10.4T    120    840  1.2M  32.1M
    sda         -      -     30    210   310K  8.1M
    sdb         -      -     28    205   295K  8.0M
    sdc         -      -     31    212   305K  8.0M
    sdd         -      -     31    213   310K  8.0M
logs            -      -      0    140      0  6.3M
  nvme0n1p1     -      -      0    140      0  6.3M

Що це означає: Ви бачите записи на пристрої журналу. Це сильно свідчить про те, що відбувається синхронна активність.

Рішення: Якщо записів на лог‑пристрій нуль, хоча користувачі скаржаться на «затримку sync», можливо, ви фактично не робите синхронних записів або sync десь відключений. Перевіряйте поведінку клієнта/застосунку.

Завдання 6: Перевірити статистику ZIL/SLOG через kstats (Linux OpenZFS)

cr0x@server:~$ sudo kstat -p | egrep 'zfs:0:zil|zfs:0:vdev_log' | head
zfs:0:zil:zil_commit_count                           184229
zfs:0:zil:zil_commit_writer_count                     182910
zfs:0:zil:zil_commit_wait_count                        1319
zfs:0:zil:zil_itx_count                              920114
zfs:0:vdev_log:vdev_log_write_bytes               12899323904

Що це означає: Коміти відбуваються; деякі змушені були чекати. Логи байтів ненульові.

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

Завдання 7: Підтвердити, що NVMe має підказки про PLP і визначити модель

cr0x@server:~$ sudo nvme id-ctrl /dev/nvme0 | egrep 'mn|vid|oacs|oncs|vwc'
mn      : INTEL SSDPE2KX040T8
vid     : 0x8086
oacs    : 0x17
oncs    : 0x5f
vwc     : 0x01

Що це означає: Ви визначили точну модель; vwc вказує на інформацію про volatile write cache (не гарантія PLP, але підказка).

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

Завдання 8: Перевірити стан NVMe і лічильники помилок

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 43 C
available_spare                     : 100%
percentage_used                     : 2%
data_units_written                  : 184,992
media_errors                        : 0
num_err_log_entries                 : 0

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

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

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

cr0x@server:~$ sudo nvme smart-log /dev/nvme0 | egrep 'temperature|critical_warning'
critical_warning                    : 0x00
temperature                         : 72 C

Що це означає: 72°C фліртує з територією тротлінгу для багатьох дисків, залежно від моделі та потоку повітря.

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

Завдання 10: Переконатися, що лог‑пристрій справді використовується для sync I/O

cr0x@server:~$ sudo zdb -C tank | egrep -A2 'log'
        log
            type: 'disk'
            id: 2
            guid: 12759911906639365414

Що це означає: Конфіг пулу містить log vdev.

Рішення: Якщо ви очікували log vdev, але не бачите його, можливо, ви додали його в інший пул або він відпав і був видалений. Виправте конфігурацію перед тонким налаштуванням.

Завдання 11: Виміряти затримку синхронних записів безпосередньо контрольним тестом (використовуйте обережно)

cr0x@server:~$ fio --name=syncwrite --filename=/tank/vmstore/fio.test --rw=write --bs=8k --iodepth=1 --numjobs=1 --direct=1 --fsync=1 --size=512m --runtime=20 --time_based --group_reporting
syncwrite: (groupid=0, jobs=1): err= 0: pid=1337: Sat Dec 16 12:10:55 2025
  write: IOPS=1450, BW=11.3MiB/s (11.8MB/s)(226MiB/20002msec)
    clat (usec): min=190, max=14200, avg=640.12, stdev=410.50

Що це означає: Це синхронний сценарій (fsync=1). Середня затримка коміту ≈0.64ms з деякими хвостовими спайками.

Рішення: Якщо затримка — кілька мілісекунд на NVMe SLOG, перевіряйте пристрій і шлях (PCIe‑лінія, тротлінг, контенція). Якщо десятки мілісекунд — ймовірно, відкат до пулу або проблемна поведінка пристрою.

Завдання 12: Підтвердити поведінку TXG і тиск «брудних» даних (чому sync може зависати)

cr0x@server:~$ cat /proc/spl/kstat/zfs/txgs
217 5 0x01 184 4608 2401924197 836746120 0 0

Що це означає: Статистика TXG присутня; на деяких системах поля парсяться для часу і беклогу інструментами. Головна думка: TXG syncing не повинен постійно відставати.

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

Завдання 13: Перевірити, чи пул обмежений через замало vdev (математика IOPS)

cr0x@server:~$ zpool list -v tank
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank       30.5T  20.1T  10.4T        -         -    22%    65%  1.00x  ONLINE  -
  raidz2-0 30.5T  20.1T  10.4T        -         -    22%    65%      -  ONLINE  -

Що це означає: Один RAIDZ vdev. Часто це чудово для ємності, але не для IOPS.

Рішення: Якщо ваше навантаження багато випадкових I/O, особливо для VM‑зберігання, правильне виправлення — більше vdev (striped mirrors), а не SLOG.

Завдання 14: Підтвердити ashift і вирівнювання (щоб уникнути самошкоджуваної латентності)

cr0x@server:~$ zdb -C tank | egrep 'ashift'
                    ashift: 12

Що це означає: Вирівнювання на 4K (ashift=12), що загалом правильно для сучасних дисків і SSD.

Рішення: Якщо бачите ashift: 9 на 4K дисках, можна отримати патологічне write amplification і затримки. Це виправляється лише перебудовою пулу, а не SLOG.

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

Коли хтось кричить «зберігання повільне», а у вас 20 хвилин до наступної ескалації, це найшвидший шлях визначити, чи релевантний SLOG.

По-перше: визначте, чи боль — це затримка синхронного запису

• Перевірте датасет sync і протокольні налаштування (NFS/SMB/iSCSI). Якщо sync не в грі, SLOG не герой.
• Шукайте сліди активності лог‑пристрою (zpool iostat -v, що показує записи під logs).
• За можливості, запустіть невеликий контрольований fio sync‑тест на датасеті (не робіть цього на крихкій системі в пікове навантаження).

По‑друге: перевірте, що пристрій SLOG не є вузьким місцем

• Стан NVMe (nvme smart-log) і температура. Тротлінг породжує «містичну» хвостову затримку.
• kstats для очікувань комітів ZIL: чи ростуть вони під час спайків затримки?
• Підтвердіть, що log vdev ONLINE і не несподівано відпав/не видалений.

По‑третє: якщо з sync все в порядку, знайдіть реальне вузьке місце

• Рівень промахів читань: ARC‑треш проти реальних дискових читань.
• Розмітка пулу: замало vdev або RAIDZ для VM‑навантажень — повторний злочинець.
• Перевантаження CPU: шифрування/стиснення/перевантажені ядра можуть маскуватися під «повільні диски».
• Мережа: затримки NFS часто живуть у світі NIC/MTU/interrupts, а не в пулі.

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

1) «Ми додали NVMe SLOG і нічого не покращилося.»

Симптоми: Бенчмарки майже не змінились; користувачі все ще скаржаться; zpool iostat показує мінімальну активність логу.

Корінь проблеми: Навантаження не доміноване синхронними записами (або sync відключено, або клієнти не роблять sync).

Виправлення: Підтвердьте через zfs get sync, опції NFS експорту та синхронний fio тест. Якщо вузьке місце — читання/метадані, розгляньте ARC/special vdev/зміну розмітки vdev.

2) «Середня затримка покращилась, але p99 все ще жахливий.»

Симптоми: Середня затримка падає; інколи залишаються багато мілісекундні простійні сплески.

Корінь проблеми: Тротлінг NVMe, внутрішній GC, баги прошивки або контенція через спільне використання пристрою.

Виправлення: Перевірте температуру, логи контролера і уникайте колокації L2ARC/swap/інших навантажень на тому самому пристрої. Використовуйте корпоративний SSD зі стабільною затримкою.

3) «Після відмови SLOG все стало непридатно повільним.»

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

Корінь проблеми: Відмова єдиного лог‑пристрою прибрала низьколатентний шлях; основний пул не може впоратися з навантаженням sync‑IOPS.

Виправлення: Дзеркаліть SLOG. Також виправте базову здатність пулу до випадкового запису, якщо вона фундаментально не відповідає навантаженню.

4) «Ми використали споживчий NVMe, і після події живлення були дивні корупції.»

Симптоми: Непослідовності на рівні застосунків, аномалії відновлення БД, іноді без очевидних помилок ZFS.

Корінь проблеми: Пристрій підтвердив flush без реальної персистентності (немає PLP, volatile cache, прошивка).

Виправлення: Використовуйте PLP‑підтримувані корпоративні пристрої для SLOG. Забезпечте стабільне живлення (UPS) і бажано дзеркалення SLOG для критичних навантажень.

5) «Ми примусово встановили sync=always скрізь і тепер повільніше.»

Симптоми: Пропускна здатність запису впала; затримки зросли; SLOG показує велику активність.

Корінь проблеми: Ви перетворили асинхронний трафік на синхронний і перевантажили шлях коміту.

Виправлення: Використовуйте sync=always лише там, де це явно потрібно. Для загальних датасетів тримайте стандартне standard.

6) «Ми дзеркалили SLOG і очікували подвоєння продуктивності.»

Симптоми: Швидкість не змінилася; інколи трохи погіршилась.

Корінь проблеми: Дзеркала забезпечують відмовостійкість; кожен ZIL‑запит має бути зафіксований на обох пристроях.

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

Три короткі корпоративні історії з реального світу

Інцидент через неправильне припущення: «SLOG робить усе швидшим»

Середня SaaS‑компанія експлуатувала ZFS‑бекенд NFS для артефактів CI і шарів контейнерних образів. Команда зберігання почула «NVMe робить ZFS швидким» і встановила блискучий пристрій журналу на кожен фаєр.
Інцидент, який вони намагалися вирішити, — таймаути збірок у пікові години.

Після зміни нічого не покращилося. Графіки вперто не крутилися. Команда збірки все ще бачила таймаути, і тепер команді зберігання довелося захищати покупку, яка не вплинула на показники.
Старший інженер нарешті поставив грубе питання: «Ми взагалі обмежені синхронними записами?»

Вони перевірили експорти. Шлях артефактів був змонтований з налаштуваннями, що віддавали перевагу пропускній здатності і дозволяли певний ризик; вузьке місце виявилося в читанні метаданих і обходах директорій на пулі з великими RAIDZ vdev на HDD.
Вирішення не було в додаткових лог‑пристроях. Воно полягало в додаванні special vdev для метаданих/малих блоків і перегляді recordsize для гарячих шляхів.
SLOG не був неправильним. Він просто був не релевантним. Хибне припущення — вважати «швидкий пристрій» універсальним чарівним рішенням.

Оптимізація, що відштовхнулась: «Використаємо дешевий споживчий NVMe як SLOG»

Рефреш інфраструктури заради економії призвів до рішення використати споживчий NVMe як SLOG у компанії, що хостить мульти‑тенантні навантаження ZFS поверх iSCSI. Команда хотіла знизити латентність комітів для кількох чатких баз даних.
Хтось запропонував споживчий NVMe: «Він швидкий і лише для журналу. Все буде добре.»

Так воно й було — поки не трапився реальний інцидент з електроживленням. Не драматичний, просто короткий бліп: перезапуск PDU під час рутинної роботи. Системи піднялися. ZFS імпортував пул чисто. Нема криків.
Тиждень по тому орендар почав скаржитися на непослідовний стан застосунку. Потім ще один.

Розслідування було болісним, бо нічого не виглядало явно зламаним. Пул був здоровий. Scrub чисті. Проблема пахла «надійні записи, які не були насправді надійними» — найнеприємніший тип загадки.
Згодом вони пов’язали перші скарги з бліпом живлення і моделлю споживчого NVMe, використаною для SLOG.

Остаточне виправлення було нудним: замінити SLOG на корпоративні диски з PLP, дзеркалити їх і перестати ставитися до semantics flush як до опціональної. Продуктивність залишилась доброю, а головне — обіцянки системи відповідали реальності. Оптимізація провалилась, бо оптимізували не те: початкову вартість над коректністю.

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

Регульоване підприємство експлуатувало ZFS‑пристрій, що обслуговував NFS для віртуалізації та внутрішніх БД. У них був дзеркалений SLOG на корпоративних SSD з PLP.
Ніхто не святкував це. Він просто мовчки обслуговував синхронні записи.

Одного дня один SLOG почав логувати помилки носія. Моніторинг сповістив, і on‑call SRE зробив найменш героїчну річ: виконав runbook.
Вони підтвердили, що пул все ще використовує дзеркалений лог, перевірили здоров’я другого пристрою і запланували заміну на той же день.

Під час заміни клієнти практично нічого не помітили. Затримка не підстрибнула. Не було екстреного вікна змін.
Команда замінила пристрій, додала його назад до дзеркала логу й спостерігала швидке завершення resilver, бо log vdev малий, а процес добре відпрацьований.

Мораль не в «дзеркалити SLOG завжди». Вона в тому, що продакшн повертає інвестиції у нудну дисципліну: резервування там, де воно важливе, моніторинг з деталями та відпрацьовані процедури, щоб не вчитися командам ZFS під час інциденту.

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

Крок‑за‑кроком: вирішіть, чи потрібен вам SLOG

1. Ідентифікуйте навантаження: NFS для VM? бази даних? домашні директорії? послідовні бекапи?
2. Підтвердіть поведінку sync: датасет sync, опції NFS експорту, налаштування на рівні застосунків щодо надійності.
3. Виміряйте: синхронний fio‑тест на стендовому датасеті; порівняйте p95/p99 затримки з SLOG і без, якщо можливо.
4. Перевірте дизайн пулу: якщо це один RAIDZ vdev, що обслуговує VM I/O, виправляйте це насамперед.
5. Визначте толерантність до ризику: якщо дані мають бути безпечними, не будуйте рішення на sync=disabled.

Крок‑за‑кроком: розгорнути NVMe SLOG розумно

1. Оберіть залізо з PLP і стабільною затримкою. Розглядайте «enterprise» як вимогу, а не як настрій.
2. Віддавайте перевагу дзеркаленню, якщо важлива стабільність продуктивності при відмові пристрою.
3. Встановлюйте з охолодженням: NVMe‑тротлінг — це інцидент продуктивності в камуфляжі.
4. Додавайте log vdev у контрольоване вікно і перевіряйте використання під реальним навантаженням.
5. Моніторте: температури, логи помилок і поведінку очікувань комітів ZIL.

Крок‑за‑кроком: безпечні експлуатаційні звички

1. Тримайте SLOG‑пристрої для однієї мети.
2. Фіксуйте модель/версію прошивки пристрою в інвентарі.
3. Тестуйте відмову: симулюйте видалення в вікні технічного обслуговування і підтвердіть, що деградація продуктивності прийнятна.
4. Майте runbook заміни з інструкціями, як повернути дзеркальний лог і перевірити стан пулу.

Поширені дії ZFS для управління SLOG

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

Додати дзеркалений SLOG

cr0x@server:~$ sudo zpool add tank log mirror /dev/nvme0n1p1 /dev/nvme1n1p1

Що це означає: Додає дзеркалений log vdev; ZIL‑записи комітяться на обох пристроях.

Рішення: Використовуйте, коли вам потрібно, щоб швидкий шлях sync пережив відмову пристрою.

Видалити існуючий log vdev

cr0x@server:~$ sudo zpool remove tank nvme0n1p1

Що це означає: Видаляє лог‑пристрій (якщо у вашій версії/config це дозволено). Синхронні записи повертаються до in‑pool ZIL.

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

Питання та відповіді (FAQ)

1) Чи те саме SLOG і ZIL?

Ні. ZIL — це механізм на‑диску журналу намірів для синхронних записів. SLOG — окремий пристрій, який може тримати записи ZIL, щоб вони комітилися швидше.

2) Чи прискорить додавання SLOG мої SMB‑шари?

Іноді так, але лише якщо навантаження важке по синхронних записах і SMB налаштовано/використовується так, що примушує семантику надійності.
Вимірюйте. Не припускайте. Проблеми з SMB часто пов’язані з метаданими, oplocks або мережею/CPU.

3) Чи можна використовувати будь‑який NVMe як SLOG?

Можна, але не слід для критичних даних, якщо він не має PLP і стабільної поведінки flush.
«Швидкий» — це не вимога; вимога — «швидкий і чесний при відключенні живлення».

4) Чи дзеркалити SLOG?

Якщо втрата SLOG спричинить помітний інцидент продуктивності (а це часто буває для NFS+VM‑навантажень), дзеркаліть.
Якщо це лабораторний стенд і ви можете терпіти раптовий провал продуктивності, один пристрій може бути прийнятним.

5) Як зрозуміти, чи клієнти роблять синхронні записи?

Ви виводите це з поведінки: активність лог‑пристрою, статистика ZIL‑комітів, налаштування застосунків і контрольні тести (fio з fsync). Чесний підхід — виміряти під навантаженням, схожим на продакшн, і перевірити кореляцію затримки з комітами ZIL.

6) Чи допомагає SLOG при scrub або resilver?

Ні. Scrub і resilver читають і відтворюють дані. SLOG прискорює саме підтвердження синхронних записів.

7) Який зв’язок між SLOG і L2ARC?

Абсолютно різні речі: L2ARC — розширення кешу читань; SLOG — прискорювач синхронних записів.
Люди купують обидва, коли відчаюються. Часто релевантний лише один, іноді жоден.

8) Чи безпечно sync=disabled, якщо в мене є UPS?

UPS зменшує ймовірність раптової втрати живлення, але не усуває kernel panic, скиди контролера чи баги прошивки.
sync=disabled змінює семантику надійності. Використовуйте лише тоді, коли дані витрачаються або зберігаються інакше, і ви прийняли ризик свідомо.

9) Наскільки важлива ємність SLOG?

Зазвичай не дуже. Важливіше — затримка, поведінка flush і консистентність. Ємність має покривати вікно незавершених синхронних записів плюс запас.

10) Якщо у мене all‑SSD дзеркальний пул, чи все ще потрібен SLOG?

Часто ні, бо синхронна затримка пулу може бути вже добрею. Але якщо ви обслуговуєте чутливі до затримки NFS/iSCSI й бачите вузьке місце на підтвердженнях sync, SLOG все ще може допомогти.
Виміряйте спочатку; не купуйте обладнання за звичкою.

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

NVMe як SLOG ідеальний, коли у вас дійсно є тиск синхронних записів і потрібні надійні підтвердження з низькою, передбачуваною затримкою.
Це надмір, коли навантаження асинхронне, читано‑опріоритезоване, залежить від метаданих або просто постраждало від розмітки пулу, що не може давати випадкові IOPS.

Наступні кроки, які реально змінюють результат:

1. Доведіть, що sync — це вузьке місце: перевірте налаштування датасету/експорту, спостерігайте записи логу, запустіть синхронний fio‑тест.
2. Перевірте ваш SLOG‑пристрій: PLP‑підтримка, здоров’я, охолодження та стабільність. Якщо це споживчий клас — розглядайте це як рішення про ризик, а не технічну деталь.
3. Проектуйте під відмови: дзеркаліть SLOG, якщо важлива стабільність продуктивності, і відпрацьовуйте заміну.
4. Виправляйте пул, якщо це реальна проблема: більше vdev, дзеркала для IOPS, special vdev для метаданих і достатньо RAM для ARC частіше кращі за «ще один гаджет».

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