Помилки запису в ZFS: шаблон відмови, який передбачає відключення диска

Шаблон: чому помилки запису передбачають відключення

У світі ZFS помилки контрольної суми (checksum errors) привертають найбільше уваги. Вони звучать страшно і як «корупція даних».
Але коли ви намагаєтеся передбачити наступний інцидент—той, що вибиває пристрій із пулу—показовішими виявляються помилки запису.

Ось шаблон відмови, який повторюється знову і знову в продакшені:

1. Невеликі, періодичні помилки запису накопичуються на одному пристрої. Пул може лишатися ONLINE.
   Часто це однозначне число, яке не змінюється днями, а потім раптом стрибає.
2. Стрибки затримки корелюють зі скиданнями лінку (SATA/SAS), зависанням черги HBA або «допоміжною» поведінкою прошивки.
   Ваші застосунки відчувають це раніше за вас — якщо ви не графуєте саме потрібні метрики.
3. Ядро логів показує транспортну драму: таймаути, скидання, «device offline», «rejecting I/O».
   ZFS логить наслідок: write I/O, яке не завершилося успішно.
4. scrub не «виправляє» помилки запису. Scrub перевіряє і ремонтує дані за допомогою надмірності.
   Він не лікує шлях передачі або вмираючий канал запису.
5. Пристрій відключається під час навантаження: resilver, snapshot send, вікно бекапів або зайнятий понеділок.
   Пул деградує і інцидент починає коштувати вам грошей.

Ключове: помилки запису часто спочатку не є «поганими секторами». Вони часто бувають
не в носії, а на рівні шляху передачі — контролер, кабелі, expander, backplane, живлення або прошивка.
ZFS повідомляє: «я спробував записати, але стек нижче не доставив».

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

Одна цитата, яка досі діє в операціях: Сподівання — не стратегія — часто приписують Вінсу Ломбарді.

Жарт #1: Диски не «частково відмовляють», щоб бути ввічливими. Вони це роблять, щоб ваша відсутність вписувалася у запрошення на нараду.

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

• ZFS народився в Sun у середині 2000-х з наскрізним контролем контрольної суми як фундаментальною ідеєю, а не доповненням.
• Лічильники помилок ZFS — це статистика по vdev/пристрою, яку підтримує пул; вони зберігаються між перезавантаженнями в багатьох реалізаціях.
• Ранні SATA були грубими в ентерпрайз-енклозурах: таймаути, погана поведінка TLER і крихкі лінії передачі навчали покоління поважати помилки транспорту.
• SMART і ZFS бачать різні світи: SMART часто повідомляє про «здоров’я диска», тоді як ZFS повідомляє про «реальність I/O», і вони можуть розходитися тижнями.
• Помилки запису більш «видимі», ніж читання, тому що успішні читання можуть бути обслуговані з ARC/L2ARC, ховаючи проблеми до промаху кеша.
• Баги прошивок expander’ів і backplane спричиняли реальні відмови через скидання під навантаженням, що призводило до спалахів помилок запису і відключень пристроїв.
• scrub у ZFS — це не fsck: він перевіряє блоки і ремонтує за надмірністю, але не лікує нестабільні пристрої або хиткі HBA.
• Поведінка resilver еволюціонувала: «sequential resilver» та покращення в OpenZFS зменшили біль, але resilver все одно посилює слабкі зв’язки.
• Помилки ashift залишаються назавжди: невірна вирівнювання секторів не створює прямо помилок запису, але збільшує write amplification, доводячи граничне обладнання до краю.

Що насправді означають «write errors» у ZFS

Три лічильники: READ, WRITE, CKSUM

zpool status зазвичай показує три числа на пристрій: READ, WRITE і CKSUM.
Вони не взаємозамінні і не вказують на один і той же шар.

• READ помилки: пристрій/шлях не повернув дані при запиті.
  Це може бути проблема носія, транспортний таймаут або «device not ready».
• WRITE помилки: пристрій/шлях не зміг зберегти дані при запиті.
  Це зазвичай проблема транспорту або прошивки пристрою, іноді пов’язана з живленням.
• CKSUM помилки: дані повернулися, але не відповідали контрольній сумі.
  Це часто вказує на корупцію «в польоті» (кабель, контролер, RAM) або на те, що носій повернув неправильні дані.

Чому write помилки передбачають відключення

Пристрій, який не може надійно завершити запис, зазвичай першим викидається стеком ОС.
Більшість HBA та драйверів мають бюджет терпіння. Під навантаженням бюджет витрачається швидше.
Коли таймаути накопичуються, контролер скидає лінк. ZFS бачить відмову write I/O.
Достатньо таких випадків, і пристрій стає ненадійним навіть якщо він «повертається».

Чим write помилки не є

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

Вони не автоматично «життєвий кінець диска». Дивовижний відсоток write помилок у полі — це
кабелі, expanders, HBA, backplane або розподіл живлення. Диск часто просто кур’єр — і ми всі знаємо,
що організації роблять з кур’єрами.

Хореографія відключення (що ви побачите)

Класична послідовність для проблем на шляху SATA/SAS:
timeouts → link reset M:N → queued I/O aborted → ZFS logs write errors → пристрій позначено як FAULTED або REMOVED → починається resilver.

Чим більше ваша система «допомагає» відновлювати лінки (reset storms), тим хаотичніше стає затримка.
Застосунки не цікавить, що пристрій повернувся. Їх турбує, що 99-й процентиль затримки щойно переїхав в іншу країну.

Швидкий план діагностики (перші/другі/треті кроки)

Мета перших 15 хвилин — не читати філософський трактат про зберігання даних.
Це відповісти на три питання:
Чи дані зараз у безпеці? Який шар відмовляє? Яка наступна дія швидко зменшить ризик?

Перше: підтвердити стан пулу і радіус впливу

• Запустіть zpool status -v. Визначте точний vdev і шлях пристрою, що повідомляє про write помилки.
• Перевірте, чи збережена надмірність (mirror має іншу сторону ONLINE, RAIDZ має достатньо парності).
• Зверніть увагу на активний resilver або scrub. Вони підвищують ризик протягом наступних 30 хвилин.

Друге: корелюйте з системними логами транспорту

• Шукайте в dmesg / journalctl -k повідомлення про скидання, таймаути, «rejecting I/O», «device offline», SAS phy resets.
• Якщо логи кричать «link reset», припиніть дискусію. Розглядайте це як проблему шляху поки не доведено інше.

Третє: перевірте ідентифікацію пристрою та SMART, потім вирішіть заміну чи ремонт шляху

• Зіставте пристрій ZFS з вузлом /dev та фізичним слотом (використовуйте zpool status, ls -l /dev/disk/by-id, інструменти enclosure якщо є).
• Запустіть smartctl і шукайте reallocated/pending сектори, UDMA CRC errors, command timeouts та записи в SMART error log.
• Якщо SMART чистий, а в dmesg видно скидання: підозрюйте кабель/HBA/backplane/живлення перед тим, як міняти диск.

Правило прийняття рішень, що збереже вам роботу

Якщо write помилки зростають і ви бачите транспортні скидання в тому ж вікні, віддавайте пріоритет стабілізації шляху.
Якщо швидко стабілізувати шлях не вдається — замініть компонент, який найімовірніше нестабільний (кабель/порт backplane),
а якщо платформа «таємнича», замініть і диск. Праця дорога; простій дорожчий.

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

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

Завдання 1: Отримайте правду з ZFS

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible.  Otherwise restore the entire pool from backup.
  scan: scrub repaired 0B in 02:41:10 with 0 errors on Tue Dec 24 03:10:11 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz1-0                  DEGRADED     0     0     0
            ata-WDC_WD80EFAX-68KNBN0  ONLINE      0     0     0
            ata-WDC_WD80EFAX-68KNBN0  ONLINE      0     7     0
            ata-WDC_WD80EFAX-68KNBN0  ONLINE      0     0     0
            ata-WDC_WD80EFAX-68KNBN0  ONLINE      0     0     0

errors: Permanent errors have been detected in the following files:
        tank/data/vmstore/vm-104.img

Значення: Один диск показує WRITE=7. Пул DEGRADED і ZFS повідомляє про файл з permanent errors.
Це не «можливо». Щось вже не вдалося записати коректно або не вдалося закомітити.

Рішення: Вважайте це активним інцидентом. Визначте, чи помилка ізольована і чи відновлюється за допомогою надмірності/бекапу.
Також одразу почніть розслідування транспорту; лічильник write — ранній індикатор падіння.

Завдання 2: Підтвердіть точний шлях пристрою, який використовує ZFS

cr0x@server:~$ sudo zpool status -P tank
  pool: tank
 state: DEGRADED
config:

        NAME                                      STATE  READ WRITE CKSUM
        tank                                      DEGRADED 0    0     0
          raidz1-0                                DEGRADED 0    0     0
            /dev/disk/by-id/ata-WDC_WD80EFAX_A1   ONLINE  0    0     0
            /dev/disk/by-id/ata-WDC_WD80EFAX_B2   ONLINE  0    7     0
            /dev/disk/by-id/ata-WDC_WD80EFAX_C3   ONLINE  0    0     0
            /dev/disk/by-id/ata-WDC_WD80EFAX_D4   ONLINE  0    0     0

Значення: Тепер у вас є стабільні ідентифікатори. Якщо ваш пул використовує /dev/sdX імена, виправте це пізніше.

Рішення: Використовуйте шлях by-id для SMART і для знаходження фізичного диска. Не довіряйте порядку /dev/sdX після скидань.

Завдання 3: Перевірте, чи помилки продовжують зростати

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
config:

        NAME                        STATE  READ WRITE CKSUM
        tank                        DEGRADED 0    0     0
          raidz1-0                  DEGRADED 0    0     0
            ata-WDC_WD80EFAX_A1     ONLINE  0    0     0
            ata-WDC_WD80EFAX_B2     ONLINE  0    9     0
            ata-WDC_WD80EFAX_C3     ONLINE  0    0     0
            ata-WDC_WD80EFAX_D4     ONLINE  0    0     0

Значення: WRITE змінився з 7 до 9. Проблема триває.

Рішення: Припиніть «дивитися і чекати». Або зменшіть навантаження, перемістіть робочі навантаження або рухайтеся до заміни/ремонту шляху зараз.

Завдання 4: Витягніть системні логи на предмет скидань/таймаутів транспорту

cr0x@server:~$ sudo journalctl -k --since "30 min ago" | egrep -i "ata|sas|scsi|reset|timeout|offline|aborted" | tail -n 20
Dec 25 01:43:11 server kernel: ata8.00: failed command: WRITE FPDMA QUEUED
Dec 25 01:43:11 server kernel: ata8.00: cmd 61/00:08:10:3c:2a/04:00:00:00:00/40 tag 1 ncq dma 524288 out
Dec 25 01:43:11 server kernel: ata8.00: status: { DRDY ERR }
Dec 25 01:43:11 server kernel: ata8.00: error: { ICRC ABRT }
Dec 25 01:43:12 server kernel: ata8: hard resetting link
Dec 25 01:43:17 server kernel: ata8: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 25 01:43:17 server kernel: ata8.00: configured for UDMA/133

Значення: ICRC помилки і скидання лінку — класичні ознаки проблем з кабелем/backplane/роз’ємом (або зрідка контролера).
Це не «ZFS причіплюється». Транспорт флякує.

Рішення: Розглядайте як проблему шляху. Перезатисніть/замініть кабель, перевірте порт backplane, інспектуйте живлення, розгляньте прошивку/драйвер HBA.
Якщо це hot-swap відсік, перемістіть диск в інший слот, якщо можливо.

Завдання 5: Зіставте пристрій з вузлом ядра і перевірте стабільність

cr0x@server:~$ ls -l /dev/disk/by-id/ata-WDC_WD80EFAX_B2
lrwxrwxrwx 1 root root 9 Dec 25 01:10 /dev/disk/by-id/ata-WDC_WD80EFAX_B2 -> ../../sdg

Значення: Диск наразі /dev/sdg. Після скидань він може стати sdf або sdh.

Рішення: Використовуйте /dev/disk/by-id/... для всіх дій, а не /dev/sdg.

Завдання 6: Отримайте SMART-статус і журнал помилок

cr0x@server:~$ sudo smartctl -a /dev/sdg | egrep -i "Model|Serial|Power_On_Hours|Reallocated|Pending|Offline_Uncorrectable|UDMA_CRC|Error|SMART overall"
Model Family:     Western Digital Red
Device Model:     WDC WD80EFAX-68KNBN0
Serial Number:    XXXXXXXXXXXX
SMART overall-health self-assessment test result: PASSED
Power_On_Hours:   23144
Reallocated_Sector_Ct: 0
Current_Pending_Sector: 0
Offline_Uncorrectable: 0
UDMA_CRC_Error_Count: 27
SMART Error Log Version: 1
ATA Error Count: 14

Значення: Носій виглядає чистим (немає reallocations/pending), але CRC помилки є. CRC помилки сильно корелюють з проблемами кабелю/backplane.

Рішення: Замініть/пересадіть SATA/SAS шлях. Якщо CRC продовжить зростати після цього — замініть диск або HBA.

Завдання 7: Перевірте, чи ZFS вважає це тимчасовою I/O проблемою чи permanent corruption

cr0x@server:~$ sudo zpool status -v tank | sed -n '1,120p'
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
config:
...
errors: Permanent errors have been detected in the following files:
        tank/data/vmstore/vm-104.img

Значення: «Permanent errors» означає, що ZFS не зміг само-відновити цей блок з надмірності у момент виявлення.
Це могло статися під час запису, коли парність не вдалося оновити безпечно, або надмірність була недостатньою/компрометованою.

Рішення: Відновіть цей файл/об’єкт з відомого доброго джерела. Для образів VM це зазвичай відновлення з backup або репліки.
Не вірте, що scrub воскресить відсутні хороші дані.

Завдання 8: Визначте, чи scrub або resilver запущено (і наскільки болісно це проходить)

cr0x@server:~$ sudo zpool status tank | egrep -i "scan|resilver|scrub|repaired|errors"
  scan: resilver in progress since Wed Dec 25 01:21:34 2025
        1.18T scanned at 802M/s, 312G issued at 210M/s, 8.34T total
        78.1G resilvered, 3.65% done, 10:44:12 to go
errors: No known data errors

Значення: Виконується resilver. Це високоінтенсивний I/O і чудовий спосіб спровокувати маргінальні лінії передачі.

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

Завдання 9: Підтвердіть ashift і розклад vdev (щоб зрозуміти навантаження і поводження при відновленні)

cr0x@server:~$ sudo zdb -C tank | egrep -i "ashift|raidz|mirror|vdev" | head -n 30
            raidz
                ashift: 12
                nparity: 1
                children[0]:
                children[1]:
                children[2]:
                children[3]:

Значення: ashift 12 — це 4K сектора. Добре. Якщо ви бачите ashift 9 на сучасних дисках, ви збільшуєте write amplification.

Рішення: Якщо ashift невірний, плануйте перебудову/міграцію. Не «налаштовуйте» структурну помилку в той час, як женетеся за write помилками.

Завдання 10: Перевірте тиск на ARC та помилки пам’яті (бо погана RAM може імітувати проблеми диска)

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep "size|c_max|memory_throttle_count|arc_no_grow" | head
size                            4    8589934592
c_max                           4    17179869184
memory_throttle_count           4    0
arc_no_grow                     4    0

Значення: ARC не обмежується через тиск пам’яті. Це не виключає проблем з RAM, але відсікає поширений сценарій «система вмирає».

Рішення: Якщо ви підозрюєте пам’ять, перевірте журнали ECC (mcelog/rasdaemon) і заплануйте тестування.
Не міняйте диски, щоб виправити корупцію в RAM.

Завдання 11: Перегляньте статистику I/O на рівні блоку

cr0x@server:~$ iostat -x 1 5 /dev/sdg
Linux 6.5.0 (server)  12/25/2025  _x86_64_ (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.10    0.00    1.20   12.40    0.00   83.30

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sdg              0.10  220.00     1.2  28160.0  85.40   4.10  90.20

Значення: Високий await з великою завантаженістю може бути «нормальним під resilver», або це можуть бути повторні повторні спроби через транспортні проблеми.
Потрібно корелювати з логами ядра.

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

Завдання 12: Підтвердіть клас драйвера/прошивки HBA і поведінку черг

cr0x@server:~$ lspci -nn | egrep -i "SAS|RAID|HBA"
03:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0097]

cr0x@server:~$ modinfo mpt3sas | egrep -i "version|firmware|srcversion" | head -n 10
version:        47.00.00.00
srcversion:     9F6C3D0F5E4D2C3A2E3A1B2

Значення: Ви на LSI/Broadcom SAS3 HBA стеку. Зазвичай стабільно, іноді вибагливо щодо прошивки.

Рішення: Якщо багато дисків показують періодичні write помилки, підозрюйте HBA/expander/прошивку. Лише один диск? Підозрюйте конкретну лінію/кабель/порт/диск.

Завдання 13: Перевірте широкий вплив — помилки на кількох пристроях

cr0x@server:~$ sudo zpool status tank | awk 'BEGIN{p=0} /config:/{p=1} p && $1 ~ /(ata-|scsi-|nvme|\/dev\/disk)/ {print}'
tank                        DEGRADED 0 0 0
raidz1-0                    DEGRADED 0 0 0
ata-WDC_WD80EFAX_A1         ONLINE  0 0 0
ata-WDC_WD80EFAX_B2         ONLINE  0 9 0
ata-WDC_WD80EFAX_C3         ONLINE  0 0 0
ata-WDC_WD80EFAX_D4         ONLINE  0 0 0

Значення: Лише один пристрій накопичує write помилки. Це знижує підозру на глобальні компоненти — але не виключає їх.
Один поганий порт на backplane все ще може бути «глобальним компонентом» у масці.

Рішення: Сфокусуйте фізичний огляд на тому слоті/кабелі/шляху першим. Якщо кілька пристроїв мають WRITE/READ помилки, розширюйте перевірку до HBA/expander/живлення.

Завдання 14: Примусовий контрольований SMART self-test під час обслуговування (не в піку I/O)

cr0x@server:~$ sudo smartctl -t short /dev/sdg
Sending command: "Execute SMART Short self-test routine immediately in off-line mode".
Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 2 minutes for test to complete.

cr0x@server:~$ sudo smartctl -a /dev/sdg | egrep -i "Self-test execution status|# 1|Completed"
Self-test execution status:      (  0) The previous self-test routine completed without error.
# 1  Short offline       Completed without error       00%     23145         -

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

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

Завдання 15: Правильне очищення лічильників (тільки після виправлення причини)

cr0x@server:~$ sudo zpool clear tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
config:

        NAME                        STATE  READ WRITE CKSUM
        tank                        DEGRADED 0 0 0
          raidz1-0                  DEGRADED 0 0 0
            ata-WDC_WD80EFAX_A1     ONLINE  0 0 0
            ata-WDC_WD80EFAX_B2     ONLINE  0 0 0
            ata-WDC_WD80EFAX_C3     ONLINE  0 0 0
            ata-WDC_WD80EFAX_D4     ONLINE  0 0 0

Значення: Лічильники очищено. Це нічого не виправляє; просто дає чисту відправну точку, щоб побачити повторення.

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

Завдання 16: Контрольований тест запису на непружньому резерві (ніколи не на живому vdev)

cr0x@server:~$ sudo fio --name=writecheck --filename=/mnt/testdisk/fio.dat --rw=write --bs=1M --iodepth=16 --numjobs=1 --size=8G --direct=1 --runtime=120 --time_based=1
writecheck: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=16
fio-3.33
writecheck: (groupid=0, jobs=1): err= 0: pid=25191: Wed Dec 25 01:58:23 2025
  write: IOPS=210, BW=210MiB/s (220MB/s)(25.2GiB/123000msec)
    clat (usec): min=950, max=420000, avg=7700.12, stdev=9500.10

Значення: Це базовий тест тривалого запису. Він може виявити скидання транспорту при спостереженні логів.

Рішення: Якщо в логах ядра з’являються скидання під час простого fio, ви відтворили проблему в контрольованих умовах.
Виправляйте шлях. Не звинувачуйте ZFS за те, що він повідомляє про проблему.

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

1) Інцидент через хибне припущення: «SMART passed, тож диск в порядку»

Середня SaaS компанія мала ZFS-backed VM кластер. Один хост почав повідомляти про кілька write помилок на одному диску.
On-call інженер зробив класичний хід: smartctl показував «PASSED», без reallocations, без pending секторів.
Він очистив помилки пулу і пішов далі.

Через два дні під час вікна бекапу той самий диск відключився. Пул деградував, почався resilver, і
затримки хоста перетворилися з «нормальних» у «апокаліпсис служби підтримки». On-call побачив SATA link resets в логах,
але припустив, що це побічний ефект resilver, а не причина.

Старший SRE нарешті подивився SMART атрибути знову — зокрема лічильники інтерфейсу.
UDMA CRC errors підбиралися поступово. Диск не відмовляв у зберіганні даних; він відмовляв у надійному спілкуванні.
«Passed» у загальному висновку був технічно вірним і операційно марним.

Виправлення було соромно простим, як часто буває: заміна одного SATA кабелю і переведення диска в інший порт backplane.
Помилки зникли. Resilver завершився. Більше відключень не сталося.

Хибне припущення було не в тому, що SMART бреше. Припущення полягало в тому, що SMART — це первинна істина.
В інцидентах ZFS первинна істина — «які I/O система не змогла завершити», і ZFS ближчий до цієї істини, ніж маркетингове зведення диска.

2) Оптимізація, що повернулася боком: «Більше пропускної здатності» через агресивний тюнінг

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

Вони підняли recordsize не розуміючи профілю I/O, поміняли sync налаштування заради пропускної здатності,
і збільшили queue depths в стеку контролера, щоб «утримувати диски зайнятими». Бенчмарки покращилися. Слайди були зроблені.
Продакшн, як завжди, вчинив по-своєму.

Під піковим навантаженням система почала накопичувати write помилки на двох дисках за одним expander.
Логи ядра показали таймаути і скидання. Тюнінг збільшив тривалість і вибуховість записів, розтягнув толерантність expander’а і підсилював дрібні проблеми цілісності сигналу.
Система не впала відразу; вона впадала періодично, що найгірше, бо це марнує час усіх.

Вони відкочували більшість тюнінгу і замінили проблемний модуль expander/backplane.
Пропускна здатність трохи впала, tail latency значно покращився, і write помилки зникли.
Команда вивчила урок, який ніхто не бажає вивчати: швидший шлях до відмови — все одно шлях до відмови.

Жарт #2: «Ми налаштували для продуктивності» іноді просто красивий спосіб сказати «ми підготували майбутній інцидент більш ефективно».

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

Фінансова організація запускала OpenZFS на Linux для внутрішніх файлових сервісів. Не гламурно, але вони ставилися як до справжньої системи:
стабільні by-id імена пристроїв у пулах, мічені салазки, документовані карти слотів, і сувора політика: ніхто не hot-swap без другої людини, що перевіряє серійник.

Одного дня з’явилися write помилки на одному члені vdev. On-call запустив zpool status -P,
підтвердив шлях by-id, зіставив його з фізичним слотом і перевірив логи: періодичні скидання на одній phy.
Вони відкрили заявку в facilities для планового вікна і підготували заміну кабелю та запасний диск.

Під час вікна вони перемістили диск в новий слот і замінили кабель. Очистили помилки і запустили scrub.
Ніякого повторення. Навіть запасний диск не знадобився, але його наявність уникнула пастки «замовимо і чекатимемо».

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

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

1) «WRITE помилки на одному диску, SMART каже PASSED»

Симптом: ZFS показує write помилки; SMART overall-health — «PASSED», атрибути носія виглядають чистими.

Корінь: Нестабільність шляху передачі (CRC, link resets), порт backplane, кабель, lane expander або глюки HBA.

Виправлення: Перевірте логи ядра на предмет скидань; інспектуйте/замініть кабель; перемістіть диск в інший слот; оновіть прошивку HBA/expander; і лише потім міняйте диск.

2) «Scrub пройшов чисто, але write помилки продовжують рости»

Симптом: Scrub повідомляє 0 помилок, але лічильник WRITE інкрементується.

Корінь: Scrub читає; ваша проблема на записі (або скидання під час записів). Scrub не валідовує шлях запису під вашим робочим навантаженням.

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

3) «Декілька дисків раптово показують WRITE помилки»

Симптом: Кілька членів vdev отримують write помилки за хвилини/години.

Корінь: Відмова спільного компонента (HBA, expander, живлення backplane, PCIe AER, баг у прошивці).

Виправлення: Припиніть ритуальну заміну дисків. Інспектуйте спільне обладнання, перевірте PCIe AER логи, розгляньте нещодавні зміни прошивки/ядра і подумайте про відкат.

4) «Пристрій постійно відкидається і повертається; пул флапає»

Симптом: Диск стає FAULTED/REMOVED, потім повертається ONLINE після скидань.

Корінь: Нестабільність лінку або періодичне живлення, іноді маргінальна рейка PSU до backplane.

Виправлення: Розглядайте flapping як термінову проблему. Замініть кабель/слот/backplane; перевірте конектори живлення; підтвердіть стан PSU і постачання живлення backplane.

5) «WRITE помилки після зміни sync налаштувань»

Симптом: Після тюнінгу продуктивності з’явилися write помилки під піковим навантаженням.

Корінь: Тюнінг збільшив вибуховість записів/глибину черг, виявивши слабини контролера/expander’а.

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

6) «Permanent errors у файлах навіть при надмірності»

Симптом: ZFS повідомляє permanent errors для конкретних файлів.

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

Виправлення: Відновіть з backup/репліки; потім дослідіть, чому надмірність не врятувала (другий пристрій відмовив, нестабільний шлях або конфігурація).

7) «Resilver ніколи не завершується; помилки продовжуються»

Симптом: Resilver сповільнюється або перезапускається; write/read помилки тривають.

Корінь: Навантаження від rebuild повторно тригерить відмову. Це часто з кабелями, expander’ами або перегрітими HBA.

Виправлення: Зменште навантаження, покращіть охолодження, замініть підозрілий компонент шляху, і лише потім повторіть resilver.

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

Негайна ізоляція (0–30 хвилин)

1. Запустіть zpool status -v і зафіксуйте вивід у нотатках інциденту.
2. Визначте, чи збережена надмірність. Якщо ні — перейдіть у режим захисту даних: зупиніть записи, зробіть снапшоти, підготуйте відновлення.
3. Перевірте, чи активний scrub/resilver. Якщо resilver запущено, очікуйте крихкість системи.
4. Витягніть логи ядра на предмет скидань/таймаутів. Помилки транспорту змінюють пріоритет з «здоров’я диска» на «стабільність шляху».
5. Зіставте пристрій з by-id та фізичним розташуванням. Не торкайтеся заліза, поки не знаєте точно, що витягаєте.

Виділення кореня проблеми (цей же день)

1. Порівняйте лічильники ZFS по всіх пристроях. Один пристрій: ймовірно локальна проблема. Багато пристроїв: ймовірно спільний компонент.
2. Перевірте SMART атрибути, що вказують на проблеми шляху (CRC, command timeouts), а не тільки reallocated сектори.
3. Огляньте/перезатисніть/замініть кабель; перемістіть диск в інший слот, якщо шасі це дозволяє.
4. Перегляньте прошивки HBA/expander і останні оновлення ядра; регресії бувають насправді.
5. Очищайте ZFS помилки лише після ремедіації, щоб підтвердити, чи повторюється проблема.

Відновлення і валідація (після апаратних робіт)

1. Якщо диск замінено, дайте resilver завершитися під моніторингом. Не святкуйте при 3%.
2. Запустіть scrub після resilver, щоб валідувати надмірність і виявити латентні помилки читання.
3. Перевірте цілісність даних застосунку для файлів, які ZFS позначив як permanent errors.
4. Налаштуйте оповіщення: write errors > 0 повинні викликати пейдж під час бізнес-годин, а не чекати деградації пулу.

Укріплення (частина, що запобігає повторенням)

1. Використовуйте by-id іменування пристроїв у всіх пулах. Якщо ви успадкували пул з /dev/sdX, плануйте контрольовану міграцію.
2. Стандартизовуйте HBA в IT-режимі і тримайте прошивки уніфікованими по флоту.
3. Маркуйте салазки серійними номерами і ведіть карту слотів. Це запобігає інцидентам «замінили не той диск».
4. Моніторьте повідомлення про скидання ядра і SMART CRC лічильники разом з лічильниками помилок ZFS.
5. Проводьте періодичні, заплановані scrub і відстежуйте тренди, а не тільки пройшов/не пройшов.

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

1) Чи означають помилки запису ZFS завжди, що диск відмовляє?

Ні. Вони часто означають, що write I/O не завершилося успішно, що може бути проблемою прошивки диска, але дуже часто це
кабель, backplane, expander, HBA або живлення. Перевірте логи транспорту перш ніж замовляти палету дисків.

2) У чому різниця між write помилками і checksum помилками в ZFS?

Write помилки означають, що ZFS не зміг успішно записати дані на пристрій/шлях. Checksum помилки означають, що дані були прочитані, але не відповідали контрольній сумі —
корупція або неправильна доставка. Обидва випадки погані; вони вказують на різні шари.

3) Якщо я запускаю scrub і він повідомляє 0 помилок, чи я в безпеці?

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

4) Чи варто очищати ZFS помилки за допомогою zpool clear?

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

5) Чому write помилки часто з’являються під час resilver?

Resilver — це тривала, інтенсивна операція запису плюс читання по vdev. Вона перетворює маргінальні проблеми шляху в очевидні відмови.
Думайте про resilver як про стрес-тест, який ви не планували.

6) Мій пул в mirror. Якщо одна сторона має write помилки, чи ZFS все ще зможе завершити операцію?

Часто так. Але mirror захистує лише якщо інша сторона здорова і система може завершити транзакції безпечно.
Флапаючий пристрій все одно може спричиняти затримки і операційний ризик.

7) Чи потрібна мені ECC RAM, щоб уникнути write помилок?

ECC категорично рекомендується для ZFS, але write помилки зазвичай — це відмови завершення I/O, а не корупція пам’яті.
ECC допомагає запобігти checksum помилкам і тихій корупції. Вона не виправить погані кабелі.

8) Чи може HBA спричиняти write помилки без видимих проблем SMART дисків?

Абсолютно. Якщо HBA або expander скидає лінки, погано обробляє черги, перегрівається або має баг у прошивці, ZFS побачить відмови write I/O.
SMART може виглядати ідеально, бо диск просто не отримав нормальної можливості виконати роботу.

9) Який поріг оповіщення слід використовувати для write помилок?

Для більшості продакшн систем: будь-які непорожні write errors на інакше здоровому пристрої мають викликати розслідування.
Якщо вони зростають з часом — ескалюйте. Тренди важливіші за одне число, але перша write помилка — це найраніший сигнал.

10) Якщо ZFS повідомляє «permanent errors», чи це означає повну втрату даних?

Не повну, але це означає, що ZFS не зміг відновити певні блоки з надмірності. Постраждалі файли/об’єкти потрібно відновити з backup або реплік.
Потім потрібно з’ясувати, чому надмірність не врятувала у той момент.

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

Помилки запису в ZFS — це не тривіальна статистика. Це шаблон відмови. Вони передбачають відключення, тому що часто є першим видимим знаком,
що шлях запису — диск, лінк, контролер, enclosure — не може надійно завершувати I/O під навантаженням.

Зробіть три речі наступного разу, коли побачите WRITE > 0:

1. Негайно корелюйте: лічильники ZFS + логи ядра + SMART інтерфейсні помилки. Знайдіть шар, що відмовляє.
2. Стабілізуйте шлях: перезатисніть/замініть кабелі, перемістіть слоти, перевірте HBA і прошивки, і не дозволяйте resilver працювати на нестабільному обладнанні.
3. Доведіть фікс: очищайте лічильники після ремедіації і спостерігайте за повторенням. Якщо показник знову зростає — перестаньте торгуватися і міняйте компоненти.

Надійність зберігання — це в основному відмова бути здивованим тією ж відмовою вдруге.
ZFS дає вам прогноз. Користуйтеся ним.