ZFS: використання SATA SSD як SLOG — дешева модернізація, яка часто підводить

November 28, 2025 • February 3, 2026 • Читання: 6 хв • Views: 7

Було корисно?

Ви купили «швидкий» SATA SSD, додали його як SLOG у ZFS і чекали дива. Натомість отримали повільніший NFS, нестабільну затримку віртуальних машин
або — гірше — тихе зростання ризику, що проявиться лише під час першого суттєвого аварійного відключення живлення.

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

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

У ZFS є дві пов’язані концепції, які в обговореннях часто плутають: ZIL (ZFS Intent Log) і SLOG
(Separate LOG device).

ZIL: журнал у пулі, який існує незалежно від ваших бажань

ZIL — це не «додаткова функція». Це частина того, як ZFS надає POSIX-совісні семантики для синхронних записів. Коли застосунок
викликає fsync(), використовує O_SYNC або коли протокол наполягає на стабільних записах (привіт, NFS), ZFS має підтвердити запис лише після того,
як дані будуть захищені від аварії.

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

SLOG: переміщення ZIL на виділений пристрій

За замовчуванням ZIL знаходиться в основному пулі, розподілений по топ-рівневих vdev. Додавання SLOG каже ZFS: «зберігай записи ZIL тут».
Мета — знизити затримку синхронних записів і згладити штраф випадкових записів для синхронних навантажень.

Це корисно тільки якщо ваше навантаження робить синхронні записи. Якщо переважно асинхронні операції (типові масові записи, багато баз даних,
оптимізованих під async, або медіа-зберігання), SLOG буде декоративним спойлером у мінівені.

Чим SLOG не є

Не L2ARC. Він не кешує читання.
Не write-back кеш. Він не поглинає всі записи; прискорює лише підтвердження синхронних записів.
Не безкоштовний шлях до продуктивності. Невдалий SLOG може погіршити затримки й розширити радіус ураження при відмові.

Патерн записів для SLOG жорсткий: малі, переважно послідовні, чутливі до затримки записи, які повинні бути стійкими зараз.
Пристрій має виконувати flush-команди. Має бути захист від втрати живлення або еквівалентна гарантія надійності.
І він не повинен зависати під тривалим тиском fsync.

Жарт №1: Використовувати споживчий SATA SSD як SLOG — це як одягти подушку для подорожей як мотоциклетний шолом: м’яко, оптимістично і хибно на швидкості.

Чому SATA SSD як SLOG часто розчаровує або виходить з ладу

Промова про дешеву модернізацію спокуслива: «У мене є зайвий SATA SSD. Додаємо як log. Синхронні записи стануть швидшими.» Іноді ви отримуєте невеликий виграш.
Частіше — каша. Ось чому.

1) SATA SSD брешуть (або принаймні домовляються)

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

Багато споживчих SSD мають леткий DRAM-кеш і різну дисципліну в прошивці щодо команд flush. Дехто — чудовий. Дехто — «працює, поки не перестане».
Найгірший випадок — диск, який швидко повертає успіх, але втрачає останні секунди записів при відключенні живлення.
Для SLOG це катастрофа: ZFS після перезавантаження спробує програти ZIL, але якщо SLOG втратив підтверджені записи журналу, ви відкрили вікно для
тихого пошкодження або невідповідності на рівні застосунку.

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

Продуктивність синхронних записів визначається хвостовими затримками. SLOG, що демонструє 50 000 IOPS в бенчмарку, але іноді зависає
через garbage collection, обслуговування прошивки або виснаження SLC-кешу, перетворить «швидко» на «рвано».

Протокол SATA і його черги також обмежені у порівнянні з NVMe. Ви купуєте не лише пропускну здатність; ви купуєте кращу поведінку під паралельними
і flush-орієнтованими навантаженнями.

3) Ізнос і write amplification з’являються швидше, ніж ви думаєте

SLOG бачить постійний потік малих записів. ZFS записує журнальні записи, потім видаляє їх після коміту TXG.
Така текучість створює write amplification і поступовий знос.

Споживчі SATA-диски часто мають нижчі характеристики витривалості і слабшу стабільну продуктивність записи після вичерпання псевдо-SLC кешу.
Режим відмови не завжди «диск помер». Частіше: затримки погіршуються, потім з’являються тайм-аути в застосунках,
потім хтось вимикає sync, щоб «полагодити», і тепер ви працюєте без страховки.

4) «Один дешевий SLOG» — це єдина точка драм

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

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

5) Можливо, у вас взагалі немає проблем із sync

Багато болю з продуктивністю ZFS не пов’язано з ZIL. Це недостача ARC, невідповідний recordsize, фрагментовані HDD vdev,
забагато малих операцій вводу/виводу на RAIDZ, насичення CPU від чексамування/стискання або неправильно налаштований стек гіпервізора для sync.

Додавання SLOG до системи, яка вже обмежена IOPS в інших місцях, — класичний приклад «інструмент застосовано не до тієї рани».

Факти та історичний контекст, які варто знати

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

ZFS виник у Sun у середині 2000-х з явним фокусом на цілісність даних: end-to-end контрольні суми та copy-on-write не були опціональними.
ZIL існує навіть без SLOG; додавання лог-пристрою лише переміщує його. Люди, які «додають SLOG для швидших записів», часто неправильно це розуміють.
NFS традиційно багато операцій трактує як синхронні (або вимагає семантик стабільного зберігання), тому розмови про SLOG часто починаються у NFS-орієнтованих середовищах.
Ранні епохи SSD робили поведінку flush надзвичайно непослідовною; баги в прошивці навколо write barriers і FUA призвели до років «він у бенчмарку швидкий, але…»
Глибина черги та накладні витрати одного SATA обмежені у порівнянні з NVMe; це має значення при навантаженнях з частими flush та паралельних I/O.
Захист від втрати живлення (PLP) історично був функцією ентерпрайз, бо потребує апаратних елементів (конденсатори) та валідації; споживчі диски часто його не мають або реалізують частково.
TXG ZFS зазвичай комітиться кожні кілька секунд (можна налаштовувати), що визначає, як довго журнальні записи можуть жити перед видаленням — короткоживучі, з високою плинністю.
«Disable sync» став народним рецептом у віртуалізованих середовищах, бо це робить бенчмарки красивими; воно також робить відновлення після збою схожим на кримінальну сцену.

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

Відмова продуктивності: SLOG стає вузьким місцем

Коли ви додаєте SLOG, синхронні операції повинні потрапляти на цей журнал-пристрій. Якщо цей пристрій має вищу затримку, ніж найкращий шлях синхронного запису пулу
(наприклад, пул з пристойними SSD або навіть добре поводженим mirror з HDD з зрозумілою поведінкою кешу), ви можете зробити синхронні записи повільнішими.

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

Відмова правильності: підтвердження записів, які не були по-справжньому стійкими

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

Люди питають: «Хіба ZFS не захищає від цього?» ZFS захищає від багатьох речей. Він не може зробити брехливий пристрій чесним.

Відмова надійності: SLOG помирає і ви втрачаєте останні безпечні записи

Немірорований SLOG — це один пристрій між вами і втратою підтверджених синхронних записів під час вікна відмови цього пристрою.
Навіть якщо ви приймаєте ризик, операційна реальність гірша: коли SLOG починає відмовляти, часто це проявляється як зависання I/O,
що спричиняє шторм затримок по всій системі. Тепер ви розбираєтеся з проблемою в продакшені, а черги гіпервізора переповнюються.

Операційна відмова: хтось «вирішує» проблему, вимкнувши sync

Саме тут зазвичай і закінчується дешева модернізація. Команда додає SATA SLOG, бачить гіршу латентність, виставляє sync=disabled на dataset,
святкує і ненавмисно змінює семантику збереження для кожної ВМ або NFS-клієнта, що використовує цей dataset.

Парафраз цитати від Werner Vogels: «Все відмовляє, весь час — проєктуйте системи, виходячи з цієї реальності».

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

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

По-перше: доведіть, що у вас синхронне навантаження

Перевірте властивості dataset sync.
Перевірте поведінку аплікацій/протоколів (експорти NFS, налаштування гіпервізора, шаблони fsync у базах даних).
Запустіть контрольний тест синхронного запису і порівняйте з асинхронним.

По-друге: виміряйте затримку SLOG і ступінь його завантаженості

Використовуйте iostat, щоб побачити, чи лог-пристрій завантажений під час проблеми.
Шукайте сплески в await / часах обслуговування на SLOG.
Перевірте, чи SLOG — це SATA SSD з сумнівною поведінкою flush або без PLP.

По-третє: підтвердіть здоров’я пулу і поведінку TXG

Переконайтеся, що жоден vdev не деградований і немає resilver.
Перевірте, чи немає синхронного write amplification через малі блоки / невідповідний recordsize.
Спостерігайте часи коміту TXG і ліміти dirty data, якщо підозрюєте зависання.

По-четверте: вирішіть, видаляти, дзеркалити чи замінювати SLOG

Якщо SLOG повільніший за пул: видаліть його.
Якщо вам потрібен SLOG для семантики NFS/VM: замініть на PLP NVMe або ентерпрайз SATA з конденсаторами; дзеркальте його, якщо навантаження важливе.
Якщо вам не потрібне прискорення синхронних записів: не ставте SLOG «просто так».

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

Це реальні завдання, які ви можете виконати на Linux-хості з OpenZFS. Кожне містить пояснення, що означає вивід і яке рішення прийняти.
Використовуйте тестове вікно, якщо змінюєте властивості; команди нижче переважно тільки для читання, якщо не зазначено інше.

Завдання 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
          sdz                       ONLINE       0     0     0

errors: No known data errors

Значення: Є виділений лог-vdev (sdz). Це ваш SLOG.
Рішення: Якщо sdz — споживчий SATA SSD, ставтеся до нього з підозрою, поки не перевірите.

Завдання 2: Підтвердіть налаштування sync dataset (і знайдіть «корисні» переваження)

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

Значення: tank/nfs має sync=disabled, що змінює семантику цілісності.
Рішення: Якщо це зроблено для «покращення продуктивності», вважайте це ризиковим і заплануйте відкат з правильною SLOG або зміною навантаження.

Завдання 3: Визначте, чи лог-пристрій — SATA і яка це модель

cr0x@server:~$ lsblk -d -o NAME,ROTA,TRAN,MODEL,SIZE,SERIAL | grep -E 'sdz|nvme'
sdz     0 sata  CT500MX500SSD1   465.8G  2219E5A1B2C3

Значення: SLOG — SATA Crucial MX500 (поширений споживчий диск).
Рішення: Вважайте, що немає повного PLP. Плануйте перевірити поведінку flush та затримки під sync-навантаженням; настійно рекомендується замінити на пристрій з PLP.

Завдання 4: Перевірте, чи диск заявляє леткий write cache

cr0x@server:~$ sudo hdparm -W /dev/sdz
/dev/sdz:
 write-caching =  1 (on)

Значення: Write cache увімкнено. Це не обов’язково погано, якщо диск має PLP; це небезпечно, якщо немає.
Рішення: Якщо це споживчий SSD без PLP, не довіряйте йому як пристрою для гарантії стійкості синхронних підтверджень.

Завдання 5: Витягніть SMART-деталі і шукайте підказки про захист від втрати живлення

cr0x@server:~$ sudo smartctl -a /dev/sdz | sed -n '1,60p'
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.0] (local build)
=== START OF INFORMATION SECTION ===
Model Family:     Crucial/Micron MX500 SSDs
Device Model:     CT500MX500SSD1
Serial Number:    2219E5A1B2C3
Firmware Version: M3CR046
User Capacity:    500,107,862,016 bytes [500 GB]
ATA Version is:   ACS-3 T13/2161-D revision 5
SATA Version is:  SATA 3.1, 6.0 Gb/s
Local Time is:    Thu Dec 26 11:02:41 2025 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Значення: SMART ідентифікує споживчий SATA SSD. SMART рідко «підтверджує PLP» напряму на споживчих SATA.
Рішення: Відсутність явної підтримки PLP трактуйте як «без PLP». Для SLOG це штовхає вас до заміни або видалення.

Завдання 6: Перевірте знос і помилки носія на потенційному SLOG

cr0x@server:~$ sudo smartctl -a /dev/sdz | egrep -i 'Media_Wearout|Percent_Lifetime|Reallocated|Uncorrect|CRC|Wear|Errors'
SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)

cr0x@server:~$ sudo smartctl -a /dev/sdz | egrep -i 'Reallocated_Sector_Ct|Reported_Uncorrect|UDMA_CRC_Error_Count|Percent_Lifetime_Remain|Power_Loss'
Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Значення: Явних помилок носія не виявлено. Це не означає, що диск придатний для SLOG; лише те, що він поки не помирає гучно.
Рішення: Якщо бачите CRC-помилки, підозрюйте кабелі/бекплейн — виправте це перед тим, як звинувачувати ZFS.

Завдання 7: Спостерігайте затримки по дисках під час вікна інциденту

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

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz  avgqu-sz   await  r_await  w_await  svctm  %util
sda              2.0    18.0    64.0   980.0     98.0      1.20   22.3     8.1     24.0    1.8   36.0
sdz              0.0   420.0     0.0  2100.0     10.0     12.50   29.8     0.0     29.8    0.2   98.0

Значення: Лог-пристрій sdz майже завантажений малими записами (avgrq-sz ~10KB), і його await високий.
Рішення: Ваш SLOG — це вузьке місце. Замість налаштувань замініть його на низьколатентний PLP-пристрій, дзеркальте або видаліть, щоб повернутися до in-pool ZIL.

Завдання 8: Підтвердіть, що синхронні записи дійсно відбуваються

cr0x@server:~$ sudo zpool iostat -v tank 1
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        4.22T  6.58T    120    980  9.8M   44.1M
  raidz2-0  4.22T  6.58T    120    910  9.8M   40.7M
    sda         -      -     20    150  1.7M    6.8M
    sdb         -      -     20    150  1.6M    6.8M
    sdc         -      -     20    150  1.6M    6.8M
    sdd         -      -     20    150  1.6M    6.8M
    sde         -      -     20    155  1.7M    6.8M
    sdf         -      -     20    155  1.6M    6.7M
logs            -      -      0     70  0K     3.4M
  sdz           -      -      0     70  0K     3.4M

Значення: Log vdev активно отримує записи. Це сильно вказує на синхронну активність.
Рішення: Якщо ви очікували асинхронну роботу, знайдіть, хто (NFS, гіпервізор, аплікація) примушує sync. Виправте навантаження або забезпечте належний SLOG.

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

Запускайте це на тестовому dataset, не напряму в продакшені, якщо ви не впевнені.

cr0x@server:~$ sudo fio --name=syncwrite --directory=/tank/test --rw=write --bs=4k --iodepth=1 --numjobs=1 --size=512M --fsync=1 --direct=1
syncwrite: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
...
  write: IOPS=620, BW=2480KiB/s (2540kB/s)(512MiB/211498msec)
    lat (usec): min=450, max=85000, avg=1600.12, stdev=4100.55

Значення: Затримки синхронних записів мають неприємні хвостові сплески (max 85ms). Це те, що відчувають користувачі.
Рішення: Якщо максимальна затримка висока і корелює із завантаженням SLOG, замініть/видаліть SLOG замість налаштувань навколо нього.

Завдання 10: Перевірте, чи SLOG дзеркалений (він має бути, якщо важливий)

cr0x@server:~$ sudo zpool status tank | sed -n '1,40p'
  pool: tank
 state: ONLINE
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
        logs
          sdz                       ONLINE       0     0     0

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

Завдання 11: Перевірте, чи пул зараз виконує resilver/scrub (червоний прапор для продуктивності)

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Thu Dec 26 10:41:01 2025
        1.92T scanned at 1.34G/s, 512G issued at 356M/s, 4.22T total
        0B repaired, 12.13% done, 02:45:19 to go
config:
...

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

Завдання 12: З’ясуйте, чи dataset використовує малі блоки, які карають RAIDZ

cr0x@server:~$ sudo zfs get recordsize,volblocksize,compression tank/vmstore
NAME          PROPERTY      VALUE     SOURCE
tank/vmstore  recordsize    128K      local
tank/vmstore  volblocksize  -         -
tank/vmstore  compression   lz4       local

Значення: Якщо це dataset з образами VM, 128K може бути прийнятним, але часто для випадкового I/O бажано менші блоки.
Рішення: Якщо ваша проблема — випадкові синхронні записи на RAIDZ, розгляньте дзеркала для VM-навантаження або налаштуйте підхід до зберігання VM — не очікуйте, що SATA SLOG врятує вас від фізики RAIDZ.

Завдання 13: Перевірте, чи ваш SLOG фактично використовується (а не обійдений)

cr0x@server:~$ sudo zdb -C tank | sed -n '1,120p'
MOS Configuration:
        version: 5000
        name: 'tank'
        ...
        vdev_tree:
            type: 'root'
            id: 0
            guid: 12345678901234567890
            children[0]:
                type: 'raidz'
                ...
            children[1]:
                type: 'log'
                id: 1
                guid: 998877665544332211
                children[0]:
                    type: 'disk'
                    path: '/dev/disk/by-id/ata-CT500MX500SSD1_2219E5A1B2C3'

Значення: Конфіг пулу включає log vdev. ZFS використовуватиме його для синхронних записів, якщо на dataset не вимкнено використання або не існують інші обмеження.
Рішення: Якщо ви очікували дзеркальний журнал, але бачите тільки один child — це не налаштування, а архітектурна помилка.

Завдання 14: Видаліть проблемний SLOG (якщо вирішили, що він шкодить)

Це змінює поведінку. Заплануйте вікно, повідомте команду. І пам’ятайте: видалення SLOG не «вимикає» ZIL; він повертається назад у пул.

cr0x@server:~$ sudo zpool remove tank sdz

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

errors: No known data errors

Значення: Виділений журнал зник. Синхронні записи тепер йдуть у in-pool ZIL.
Рішення: Якщо латентність одразу покращилася, SATA SLOG був вашим вузьким місцем. Далі — або «без SLOG», або «правильний дзеркальний PLP SLOG».

Завдання 15: Якщо SLOG необхідний, додайте його як дзеркало, використовуючи стабільні ідентифікатори пристроїв

cr0x@server:~$ sudo zpool add tank log mirror /dev/disk/by-id/nvme-INTEL_SSDPE2KX010T8_PHBT1234001A1P0A /dev/disk/by-id/nvme-INTEL_SSDPE2KX010T8_PHBT1234001A1P0B

cr0x@server:~$ sudo zpool status -v tank | sed -n '1,80p'
  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
            nvme-INTEL_SSDPE2KX010T8_PHBT1234001A1P0A     ONLINE       0     0     0
            nvme-INTEL_SSDPE2KX010T8_PHBT1234001A1P0B     ONLINE       0     0     0

errors: No known data errors

Значення: Дзеркальний SLOG на NVMe-пристроях (приклад). Це правильна структурна схема для надійності.
Рішення: Якщо ви не можете дозволити собі два підходящі пристрої — ви не можете дозволити собі SLOG для важливих синхронних навантажень. Працюйте без нього.

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

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

Середня компанія консолідувала кілька старих NAS у блискучий ZFS-сервер. Вони використовували NFS для домашніх директорій і результатів збірки.
Хтось прочитав, що «SLOG прискорює записи», і додав запасний споживчий SATA SSD як лог-пристрій. Вони зробили швидкий тест копіювання файлів, не побачили проблем і пішли далі.
Всім подобаються швидкі рішення. Всім подобається галочка.

Через кілька тижнів коротка подія з живленням вдарила по стійці — перемикання UPS, не повний блек-аут. Сервер залишився увімкненим. SATA SSD — ні.
Він трохи випав із шини і повернувся. ZFS не панікував одразу; пул був онлайн. Команда видихнула.

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

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

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

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

Кластер віртуалізації хостив змішані навантаження: кілька чутливих до латентності баз даних і багато загальних ВМ. Команда зберігання бачила графіки з періодичними сплесками fsync.
Вони додали SATA SLOG до бекенду ZFS, очікуючи згладжити ці сплески.

Спочатку медіана латентності трохи покращилася. Команда святкувала. Потім настав кінець місяця, і патерн навантаження змінився: багато конкуруючих sync-операцій.
Диск SLOG досяг межі стабільного запису, псевдо-SLC кеш вичерпався, і латентність запису пішла від «більшість часу нормально» до «нерівномірно і іноді жахливо».

Віртуальні машини не просто сповільнилися; вони синхронізували своє страждання. Коли SLOG зависав, він затримував підтвердження для багатьох ВМ,
спричиняючи черги в гостевих ОС, тайм-аути в застосунках, повтори, що збільшували навантаження на запис. Шторми латентності мають талант самопідтримки.

Хтось запропонував класичне виправлення: вимкнути sync на zvol dataset, що відповідає за зберігання ВМ. Графіки стали чудовими.
Але це перетворило посилання про консистентність після збою у «удачі по життю». Через тиждень не пов’язаний панік хоста змусив перезавантаження.
Одна база даних повернулася з помилками відновлення, які дорого діагностувати і важко довести після факту.

Вони відкатили «оптимізацію», прибрали SATA SLOG і пізніше встановили дзеркальний PLP NVMe SLOG. Справжнє виправлення було не «швидший SSD», а стабільна латентність і правильні семантики,
плюс чітка політика: ніхто не вимикає sync без підписаного прийняття ризику.

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

Інша організація використовувала ZFS для NFS і iSCSI з мішаним набором HDD-дзеркал і SSD-дзеркал. У них був SLOG — але він був дзеркальним і з ентерпрайз-дисків з захистом від втрати живлення.
Виглядало це дорожче, ніж дешевий SATA SSD. Але так і було.

Різниця була не лише в апаратурі; це був процес. Вони ставилися до SLOG як до компонента надійності, а не іграшки для продуктивності.
Вели моніторинг SMART. Щомісяця проводили тренування з відмов у вікні обслуговування: відключити один SLOG-пристрій, підтвердити, що пул залишається здоровим, підтвердити продуктивність, замінити, виконати resilver — і повторити.

Якось баг у прошивці змусив один SLOG-пристрій почати кидати помилки. Моніторинг спрацював рано — до того, як користувачі почали скаржитися.
Вони акуратно вивели пристрій з ладу, замінили його і працювали на залишковому елементі дзеркала. Ніяких втрат даних. Мінімальний вплив на латентність. Тікет, заміна — і все.

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

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

1) Симптом: «Додавання SLOG зробило NFS повільнішим»

Корінь проблеми: SATA SLOG має гіршу fsync-латентність, ніж ваш in-pool ZIL, особливо під навантаженням або під час gc прошивки.

Виправлення: Видаліть SLOG і протестуйте знову; якщо потрібен SLOG — замініть на низьколатентний PLP-пристрій (бажано дзеркальний).

2) Симптом: «Затримки стрибають кожні кілька хвилин»

Корінь проблеми: Обслуговування прошивки SSD, виснаження SLC-кешу або бурсті TXG взаємодіють із завантаженим SLOG.

Виправлення: Дивіться iostat -x для %util і await SLOG. Якщо SLOG завантажений — замініть або видаліть його.

3) Симптом: «У бенчмарку швидко, але користувачі все одно скаржаться»

Корінь проблеми: Ви бенчмаркували пропускну здатність, але користувачі відчувають хвостову латентність. Sync-навантаження дбають про найповільніший 1%.

Виправлення: Використовуйте fio --fsync=1 з малим iodepth і відстежуйте максимальні затримки; вирішуйте хвостову латентність, а не пікову пропускну здатність.

4) Симптом: «Ми вимкнули sync і все стало краще»

Корінь проблеми: Ви прибрали вимогу робити записи стійкими перед підтвердженням. Продуктивність «покращилась», бо ви змінили контракт.

Виправлення: Увімкніть sync для dataset, які потребують правильності; розгорніть належний SLOG або переробіть навантаження (наприклад, локальний кеш, журнали на рівні аплікації).

5) Симптом: «Після події з живленням дані аплікації неконсистентні»

Корінь проблеми: Немає PLP в SLOG або диск брешe про flush. ZFS не може програти те, що ніколи не збереглося.

Виправлення: Припиніть використовувати споживчий SATA як SLOG. Використовуйте PLP-пристрої; дзеркальте SLOG; перегляньте UPS і політику write-cache.

6) Симптом: «Пул імпортується нормально, але останні транзакції відсутні»

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

Виправлення: Трактуйте це як інцидент цілісності. Аудитуйте історію властивості sync та апарат SLOG. Замініть на PLP-дзеркало, потім перевірте процедури відновлення.

7) Симптом: «Диск SLOG постійно відвалюється з SATA-шини»

Корінь проблеми: Кабелі/бекплейн, нестабільність живлення або прошивка споживчого SSD не витримує послідовних flush-патернів.

Виправлення: Виправте апаратний шлях (кабелі, прошивку HBA, живлення), а потім припиніть використовувати цю модель як лог-пристрій. Нестабільний SLOG гірший за відсутність SLOG.

8) Симптом: «Знос SLOG швидко росте»

Корінь проблеми: Високий рівень синхронних записів + write amplification; витривалості споживчого диска недостатньо.

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

Жарт №2: Вимкнути sync, щоб «вирішити» затримки SLOG — це як зняти пожежний датчик, бо він занадто гучний.

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

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

Перерахуйте споживачів dataset. NFS? Образи VM? Бази даних? Визначте, хто робить синхронні записи.
Перевірте властивості dataset. Якщо деінде є sync=disabled, позначте це як предмет ризику.
Виміряйте затримку синхронних записів без SLOG. Якщо вона вже прийнятна — не ускладнюйте інфраструктуру.
Якщо потрібен SLOG, визначте контракт. Ви прискорюєте синхронні записи для правильності чи маскуєте архітектурну проблему?

Покроково: якщо ви вже встановили SATA SSD як SLOG

Визначте пристрій і модель. Якщо споживча — вважайте «без PLP».
Перевірте, чи дзеркалений. Якщо ні — задокументуйте ризик і пріоритезуйте виправлення.
Спостерігайте під навантаженням. Слідкуйте за iostat -x і zpool iostat -v під sync-інтенсивними періодами.
Запустіть контрольний fio sync-тест. Відстежуйте максимальну затримку і джиттер, а не тільки IOPS.
Прийміть рішення: видалити його або замінити на дзеркальні PLP-пристрої.

Покроково: побудуйте правильну конфігурацію SLOG (яку ви не пошкодуєте)

Обирайте пристрої, призначені для стійких низьколатентних записів. PLP — ключова характеристика; прихована важлива — стабільна латентність.
Використовуйте два пристрої в дзеркалі. Якщо не можете — прийміть, що ви свідомо обираєте «ризик» як функцію.
Використовуйте стабільні шляхи до пристроїв. Віддавайте перевагу /dev/disk/by-id/..., а не /dev/sdX.
Протестуйте відмову. Отключіть один лог-пристрій у вікні обслуговування; підтвердьте, що пул залишається здоровим і латентність адекватна.
Моніторьте знос і помилки. Налаштуйте алерти для SMART-зносу, помилок носія і скидань шини.

Операційний чекліст: що задокументувати, щоб майбутній ви не страждав

Які dataset вимагають семантики sync і чому (експорти NFS, сховища VM, томи баз даних).
Очікувана поведінка при відмові SLOG (який ризик, які алерти спрацьовують, які кроки в runbook).
Як безпечно видалити/замінити SLOG.
Хто має право змінювати властивості sync і за яким погодженням.

Поширені питання (FAQ)

1) Чи прискорить SLOG усі записи в ZFS?

Ні. Він допомагає лише синхронним записам. Асинхронні записи обходять його і йдуть через звичайне буферування TXG і коміт.

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

Дивіться на великі записи на log vdev через zpool iostat -v. Підтвердіть налаштування dataset sync.
Для NFS та багатьох стеків VM припускайте значну кількість sync-операцій, поки не перевірите налаштування клієнтів/серверів.

3) Чи завжди неправильно використовувати споживчий SATA SSD як SLOG?

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

4) У чому різниця між ZIL і SLOG?

ZIL — це механізм. SLOG — це виділений пристрій, куди зберігаються записи ZIL. Без SLOG ZIL живе у пулі.

5) Чи має SLOG бути дзеркальним?

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

6) Якщо SLOG помирає, чи втрачу я весь пул?

Зазвичай ні; пул може продовжити роботу або імпортуватися без лог-пристрою залежно від часу відмови і конфігурації. Справжня небезпека — втрата останніх підтверджених синхронних записів.

7) Чому не просто виставити `sync=disabled` і забути?

Тому що ви змінюєте контракт зберігання. Бази даних, файлові системи гостьових ОС і NFS-клієнти можуть вважати дані безпечними, коли вони такими не є.
Саме так з’являється «все було гаразд», а потім після збою — неконсистентність.

8) Наскільки великим має бути SLOG?

Часто менший, ніж люди думають. Ви зберігаєте короткоживучі журнальні записи до коміту TXG. Розмір допомагає з оверпровізіонінгом і витривалістю,
але стабільність латентності та PLP важать більше за ємність.

9) Чи завжди NVMe кращий для SLOG?

NVMe зазвичай має кращі характеристики латентності та чергування, але «NVMe» не гарантує PLP або стабільної поведінки.
Все одно обирайте моделі з відомою стійкістю flush-команд і стабільною хвостовою латентністю.

10) Чи може моя проблема бути в ARC або оперативній пам’яті, а не в SLOG?

Так. Якщо читання thrash-ять і система страждає від нестачі пам’яті, усе гальмує і ви можете помилково звинуватити журнал.
Тому швидка діагностика починається з доведення, що це саме вузьке місце синхронного запису.

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

SATA SSD як SLOG привабливий, бо дешевий і простий. Саме тому він є надійним джерелом болю в продакшені:
змінює семантику збереження, концентрує синхронну латентність на одному пристрої і виставляє напоказ неприємні кути поведінки споживчих SSD.

Практичні кроки:

Пройдіть швидкий план діагностики. Підтвердіть, що у вас є проблема із sync, перед тим як купувати залізо або міняти властивості.
Якщо у вас уже є споживчий SATA SLOG — виміряйте його. Якщо він завантажений або стрибає — видаліть і протестуйте знову. Не гадяйте.
Якщо SLOG потрібен для коректності NFS/VM — робіть це правильно. Використовуйте пристрої з захистом від втрати живлення і дзеркальте їх.
Перестаньте ставитися до sync=disabled як до ручки налаштування. Розглядайте це як прийняття ризику, що вимагає дорослого схвалення.

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

Схожі статті

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