Помилки контрольної суми ZFS: що вони означають і що робити насамперед

Що насправді означають помилки контрольної суми (і чого вони не означають)

Коли ZFS записує блок, він обчислює контрольну суму і зберігає її в метаданих (не поруч з блоком даних, щоб один збій не зміг одночасно пошкодити і дані, і їхню суму). Пізніше, коли ZFS читає цей блок, він знову обчислює контрольну суму і порівнює її з очікуваною.

Помилка контрольної суми означає: байти, які повернувся шлях зберігання, відрізняються від того, що ZFS раніше записав. ZFS успішно щось прочитав — просто не те, що треба.

Помилка контрольної суми не автоматично означає: «диск поганий». Це означає «дані пошкоджені десь між пластинами/NAND і ZFS». Це «десь» включає:

• Носій диска або контролер (класичний випадок)
• SATA/SAS-кабель, конектор, backplane, експандер (розчаровуюче часто)
• Проблеми з прошивкою/драйвером HBA (особливо під час ресетів і таймаутів)
• Проблеми з живленням (просадки, ненадійні БП, незатягнуті живильні роз’єми)
• Пошкодження ОЗП (ECC допомагає; без ECC історія стає… пікантнішою)
• Нестабільність CPU/IMC через розгін або недовольтність (так, і сервери цьому піддаються)

Якщо є надмірність (mirror/RAIDZ) і ZFS може отримати коректну копію з іншого пристрою, він виправить пошкоджені дані під час scrub або читання. Це те, за що багато хто любить ZFS. Частина, яку ігнорують: якщо ви продовжуєте бачити помилки контрольної суми, система постійно отримує корупцію. Ремонт — це пластир, а не ліки.

І ще: не плутайте ці три лічильники:

• READ errors: пристрій не зміг прочитати дані (I/O error). Зазвичай це диск, кабель або HBA.
• WRITE errors: ZFS не вдалося записати (I/O error) або пристрій відкинув запис. Також часто апаратна проблема.
• CKSUM errors: дані повернулися, але були неправильні. Тут «поганий диск» конкурує з «поганим шляхом».

Ось моя принципова порада: ставтеся до помилок контрольної суми як до інциденту продакшну, поки не доведете, що вони безпечні. Часто починається з «кількох». Рідко закінчується так само.

Жарт №1 (коротко, по темі): помилки контрольної суми ZFS — це як пожежна сигналізація, яка ще й підкаже, яка кімната горить. Але не варто ігнорувати її, бо кухня «виглядає нормально».

Чому ZFS помічає те, що інші файлові системи пропускають

ZFS має end-to-end перевірку контрольними сумами. Цей вираз часто вживають, але операційний наслідок простий: ZFS за замовчуванням недовіряє вашому апаратному забезпеченню. Більшість стеків історично довіряли дискам: або диск повертає правильні дані, або повертає помилку. Насправді пристрої іноді повертають неправильні дані, не видаючи I/O помилку. Це — «тиха корупція», і саме через неї існують помилки контрольної суми як клас.

ZFS також знає, як виправити те, що виявив — якщо ви дали йому надмірність. Mirror може прочитати з іншого боку. RAIDZ може реконструювати за паритетом. Без надмірності ZFS може лише сказати «цей блок невірний», і тоді ви отримуєте найменш приємну помилку: чесну.

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

Ще одна практична нотатка: помилки контрольної суми можуть з’явитися задовго після початкової корупції. Пошкоджені дані могли сидіти непоміченими тижнями. Потім scrub (або завдання резервного копіювання) доторкнеться до них і ZFS нарешті поскаржиться. Помилка реальна; час її появи просто невдалий.

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

Перший: визначте обсяг і чи може ZFS самостійно відновитись

• Чи пул DEGRADED чи лише повідомляє помилки?
• Помилки зростають зараз чи це історія?
• Чи вони обмежені одним пристроєм, одним vdev або розсіяні?
• Чи є надмірність (mirror/RAIDZ), яка може відновити?

Другий: класифікуйте режим відмови за патерном

• Один диск, CKSUM зростає повільно, при чистій історії кабелів/backplane: підозрюємо диск або його слот.
• Декілька дисків на одному HBA/backplane показують CKSUM: підозрюємо кабель/backplane/експандер/HBA.
• CKSUM без READ/WRITE плюс дивна нестабільність системи: підозрюємо ОЗП/CPU/прошивку.
• Помилки лише під час scrub/resilver: підозрюємо маргінальне обладнання під тривалим навантаженням (диск, кабель, експандер, HBA, живлення).

Третій: зберіть докази перед тим, як «виправляти» щось

• Захопіть zpool status -v, zpool events -v та системні логи навколо таймштампів.
• Занотуйте ідентифікатори пристроїв: відповідність /dev/disk/by-id важливіша за sdX.
• Витягніть SMART / NVMe health і журнали помилок.
• Якщо кілька пристроїв показують помилки, зіставте їх з фізичним ланцюгом (HBA port → експандер → слот backplane).

Тільки потім починайте заміну деталей або перестановку кабелів. Інакше ви зітрете сліди і залишите таємницю для наступного on-call.

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

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

Завдання 1: Отримайте поточну картину від ZFS

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
  scan: scrub repaired 128K in 0 days 00:12:31 with 0 errors on Tue Dec 24 01:10:18 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0  ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0  ONLINE       0     0    14

errors: No known data errors

Значення: Один пристрій показує 14 помилок контрольної суми, але під час scrub ZFS відновив дані і є «No known data errors». Це означає, що надмірність спрацювала.

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

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

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

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0  ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0  ONLINE       0     0    14

Значення: Те ж число, що й раніше. Це добре: вказує на історичну подію, а не на потік корупції.

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

Завдання 3: Отримайте ідентифікацію пристрою і уникайте пастки sdX

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep 'WDC_WD80EFAX|ata-WDC'
lrwxrwxrwx 1 root root  9 Dec 25 01:22 ata-WDC_WD80EFAX-68LHPN0_VKJ9KABC -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 25 01:22 ata-WDC_WD80EFAX-68LHPN0_VKJ9KXYZ -> ../../sdc

Значення: У вас є стабільні ідентифікатори, що відображаються в kernel device names sdb/sdc. Імена ядра можуть змінитись після перезавантаження; by-id зазвичай не змінюються.

Рішення: Використовуйте шляхи by-id при заміні й у документації. Якщо ви витягнете не той диск, ZFS запам’ятає його.

Завдання 4: Перевірте події ZFS для таймлайну

cr0x@server:~$ zpool events -v | tail -n 20
Dec 24 01:06:12.900760000 sysevent.fs.zfs.checksum
  pool = tank
  vdev_path = /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ9KXYZ
  vdev_guid = 1234567890123456789
  vdev_state = 0
  vdev_read_errors = 0
  vdev_write_errors = 0
  vdev_checksum_errors = 14
Dec 24 01:10:18.112233000 sysevent.fs.zfs.scrub_finish
  pool = tank
  scrub_repaired = 131072
  scrub_errors = 0

Значення: Подія контрольної суми сталася під час scrub. Було відновлено 128K і завершено без невиправлених помилок.

Рішення: Розберіться, що змінилося в той час: роботи з кабелями, оновлення прошивки, події живлення, сильне I/O або ресет контролера.

Завдання 5: Шукайте ресети контролера і помилки лінку в системних логах

cr0x@server:~$ sudo journalctl -k --since "2025-12-24 00:45" --until "2025-12-24 01:30" | egrep -i "ata|sas|scsi|reset|link|error" | tail -n 20
Dec 24 01:05:44 server kernel: ata7.00: exception Emask 0x10 SAct 0x0 SErr 0x400100 action 0x6 frozen
Dec 24 01:05:44 server kernel: ata7.00: irq_stat 0x08000000, interface fatal error
Dec 24 01:05:44 server kernel: ata7: SError: { UnrecovData Handshk }
Dec 24 01:05:45 server kernel: ata7: hard resetting link
Dec 24 01:05:50 server kernel: ata7: link is slow to respond, please be patient (ready=0)
Dec 24 01:05:51 server kernel: ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 24 01:05:51 server kernel: sd 6:0:0:0: [sdc] tag#19 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=7s

Значення: Ядро виявило помилку SATA link і зробило ресет. Це червоний прапорець для кабелів/backplane/інтерфейсу диска — особливо якщо повторюється.

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

Завдання 6: Перевірте здоров’я SMART (SATA/SAS через smartctl)

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep -i "Reallocated_Sector_Ct|Reported_Uncorrect|UDMA_CRC_Error_Count|Current_Pending_Sector|Offline_Uncorrectable|SMART overall"
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       23

Значення: CRC-помилки (UDMA_CRC_Error_Count) вказують на корупцію під час передачі даних — кабель/backplane, а не дефект носія. Reallocated/pending сектори нульові, що послаблює діагноз «вмираюча платівка».

Рішення: Спочатку виправляйте транспорт: кабель/backplane/слот. Якщо CRC продовжить зростати після фізичного втручання — тоді розглядайте диск або контролер.

Завдання 7: Запустіть короткий SMART self-test і прочитайте результати

cr0x@server:~$ sudo smartctl -t short /dev/sdc
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/sdc | egrep -i "Self-test execution status|SMART Self-test log" -A5
Self-test execution status:      (  0) The previous self-test routine completed without error.
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%      9123         -

Значення: Диск пройшов власний тест. Це не виправдовує диск повністю, але зміщує підозру на кабель/backplane/контролер, якщо помилки контрольної суми тривають.

Рішення: Якщо помилки ZFS продовжують накопичуватись, а SMART чистий окрім CRC — припиніть звинувачувати диск і почніть міняти кабелі/слоти.

Завдання 8: Для NVMe перевіряйте SMART і журнали помилок (nvme-cli)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 41 C
available_spare                     : 100%
available_spare_threshold           : 10%
percentage_used                     : 3%
media_errors                        : 0
num_err_log_entries                 : 2

Значення: NVMe повідомляє media_errors і записи в журналі помилок. Media errors серйозні; невелика кількість записів журналу може бути безпечною залежно від типу, але це доказ.

Рішення: Якщо media_errors > 0 або журнал помилок показує повторювані проблеми цілісності даних, плануйте заміну. NVMe зазвичай «падає швидко» і без сентиментів.

Завдання 9: Визначте тип vdev, з яким маєте справу (впливає на терміновість)

cr0x@server:~$ zpool list -v tank
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank       14.5T  9.12T  5.38T        -         -    21%    62%  1.00x  ONLINE  -
  mirror-0  7.25T  4.56T  2.69T        -         -    19%    62%      -  ONLINE
  mirror-1  7.25T  4.56T  2.69T        -         -    23%    62%      -  ONLINE

Значення: Mirrors: добре для самовідновлення і швидких resilver-ів. RAIDZ: інша поведінка, довші вікна відновлення, інший профіль ризику.

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

Завдання 10: Scrub робіть навмисно, а не рефлективно

cr0x@server:~$ sudo zpool scrub tank

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Wed Dec 25 01:40:02 2025
        1.27T scanned at 3.10G/s, 912G issued at 2.23G/s, 9.12T total
        0B repaired, 9.76% done, 0:59:31 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EFAX-...     ONLINE       0     0     0
            ata-WDC_WD80EFAX-...     ONLINE       0     0    14

errors: No known data errors

Значення: Scrub навантажує весь шлях. Якщо помилки зростають під час scrub, ви відтворюєте проблему (добре для діагностики, погано для крихкого обладнання).

Рішення: Запускайте scrubs, коли можете спостерігати і захоплювати логи. Не запускайте scrub і йдіть спати, якщо вам не подобаються несподівані оповіщення.

Завдання 11: Очищайте помилки тільки після ремедіації

cr0x@server:~$ sudo zpool clear tank

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

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EFAX-...     ONLINE       0     0     0
            ata-WDC_WD80EFAX-...     ONLINE       0     0     0

errors: No known data errors

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

Рішення: Очищайте після того, як ви переставили кабелі, поміняли слоти, замінили диск, оновили прошивку або інакше змінили конфігурацію. Потім дивіться, чи помилки повернуться.

Завдання 12: Замініть диск «по-правильному» в ZFS (приклад mirror)

cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80EFAX-68LHPN0_VKJ9KXYZ /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_NEWDRIVE

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: resilver in progress since Wed Dec 25 02:05:11 2025
        612G scanned at 1.45G/s, 210G issued at 512M/s, 9.12T total
        210G resilvered, 2.25% done, 4:58:40 to go
config:

        NAME                                              STATE     READ WRITE CKSUM
        tank                                              ONLINE       0     0     0
          mirror-0                                        ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ9KABC             ONLINE       0     0     0
            replacing-1                                   ONLINE       0     0     0
              ata-WDC_WD80EFAX-68LHPN0_VKJ9KXYZ           ONLINE       0     0     0
              ata-WDC_WD80EFAX-68LHPN0_NEWDRIVE           ONLINE       0     0     0

errors: No known data errors

Значення: ZFS проводить resilver. Якщо під час resilver виникають помилки контрольної суми, це діагностично: ваш шлях нестабільний під тривалим I/O.

Рішення: Моніторьте journalctl -k паралельно. Якщо з’являються ресети лінку або помилки транспорту — призупиніть і виправте кабелі/HBA перед завершенням заміни.

Завдання 13: Використовуйте zdb лише коли готові до точного аналізу

cr0x@server:~$ sudo zdb -bbbbbb tank 2>/dev/null | head -n 20
Dataset tank [ZPL], ID 50, cr_txg 4, 1.62G, 1021 objects, rootbp DVA[0]=<0:1c3f4a8000:200> ...

Значення: zdb — інструмент для глибокої криміналістики, не для випадкового ковыряння. Він допомагає ідентифікувати уражені блоки, коли у вас є «known data errors».

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

Завдання 14: Перевірте сигнали здоров’я пам’яті (ECC та звіти ядра)

cr0x@server:~$ sudo journalctl -k | egrep -i "mce|edac|ecc|machine check" | tail -n 20
Dec 25 00:12:08 server kernel: EDAC MC0: 1 CE memory error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0 (channel:1 slot:0 page:0x12345 offset:0x0 grain:32 syndrome:0x0)

Значення: Corrected ECC errors (CE) означають, що пам’ять поводиться ненадійно, але помилки коригуються. Це все одно може корелювати з помилками контрольної суми й нестабільністю.

Рішення: Ставтеся до повторюваних ECC-подій як до апаратного інциденту. Плануйте заміну DIMM і перестановку, і припиніть звинувачувати диски за те, що відбувається upstream у пам’яті.

Завдання 15: Подивіться властивості ZFS, що впливають на виявлення корупції

cr0x@server:~$ zfs get checksum,compression,recordsize,atime tank
NAME  PROPERTY     VALUE     SOURCE
tank  checksum     on        default
tank  compression  lz4       local
tank  recordsize   128K      local
tank  atime        off       local

Значення: Checksumming увімкнено (добре). Compression не спричиняє помилок контрольної суми, але змінює I/O-патерни і може виявити слабке обладнання під важкими читаннями/записами.

Рішення: Не «лікуйте» помилки контрольної суми зміною властивостей dataset. Виправляйте апаратний шлях. ZFS — свідок, а не злодій.

Завдання 16: Замапте фізичну топологію (приклад SAS), щоб знайти спільні компоненти

cr0x@server:~$ sudo sas2ircu 0 DISPLAY | egrep -i "Enclosure|Slot|Device is a Hard disk|SAS Address|State" -A2
Enclosure#                             : 1
  Slot#                                : 4
    Device is a Hard disk
    State                              : Optimal
  Slot#                                : 5
    Device is a Hard disk
    State                              : Optimal

Значення: Коли кілька уражених дисків пов’язані з одним enclosure/backplane/expander, мапування топології перетворює «випадкові помилки» на «єдина точка відмови».

Рішення: Якщо помилки корелюються по enclosure/порту, пріоритезуйте спільний компонент (кабель, експандер, backplane, HBA) перед заміною дисків.

Інтерпретація патернів: диск проти кабелю проти ОЗП проти прошивки

Патерн A: Один пристрій, CKSUM зростає повільно, SMART показує reallocated/pending сектори

Ймовірний винуватець: диск. Якщо кількість reallocated секторів збільшується або з’являються pending сектора — носій виходить з ладу або диск не може надійно читати старі дані.

Що робити: замінити диск. Не торгуйтеся. У mirror-vdev у вас є запас часу; у RAIDZ — тільки математика, а не милосердя.

Патерн B: Один пристрій, CKSUM + SMART UDMA CRC помилки

Ймовірний винуватець: шар транспорту. CRC-помилки часто означають кабель/backplane/конектор. З SAS-експандерами це може бути маргінальна лінія.

Що робити: пересісти і замінити кабель; перемістити диск в інший відсік; якщо використовується SATA в backplane сервера — перевірити посадку і напруження кабелю. Потім очистити помилки і спостерігати.

Патерн C: Декілька дисків на одному HBA/backplane показують CKSUM

Ймовірний винуватець: спільний компонент: HBA, експандер, backplane, живлення або баг прошивки. ZFS каже, що корупція системна, а не локальна трагедія одного диска.

Що робити: зіставте уражені диски з конкретним ланцюгом портів. Замініть SAS-кабель. Оновіть прошивку HBA до відомої стабільної версії. Перевірте шини живлення і посадку backplane.

Патерн D: CKSUM із відсутністю помилок на рівні диска, плюс kernel MCE/EDAC звіти

Ймовірний винуватець: нестабільність пам’яті/платформи CPU. ZFS захищає цілісність на диску, але погана ОЗП може пошкодити дані до того, як їх просумували, або після читання в пам’ять.

Що робити: розглядайте це як апаратну проблему платформи. Перевірте, що ECC увімкнено. Запустіть тест пам’яті в режимі обслуговування. Припиніть розгін. Замініть DIMM при повторних скоригованих помилках.

Патерн E: Помилки з’явились після оновлень прошивки або ядра

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

Що робити: відкотіть, якщо можливо, або переходьте на виправлену версію. Зберігайте докази (events, логи). Не «виправляйте» це придушенням помилок.

Цитата на завершення, бо операції — переважно про скромність: «Надія — не стратегія.» — General Gordon R. Sullivan

Жарт №2 (коротко, по темі): очищати помилки ZFS без усунення причини — це як вимкнути лампочку «check-engine», висмикнувши саму лампочку. Дашборд стане тихіше.

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

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

Команда успадкувала ноду сховища, яка «місяцями мала кілька помилок контрольної суми». Попередній адміністратор написав, що це «відомий поганий диск» і «не терміново, бо RAIDZ». Звучало правдоподібно, тож це відправили в низ пріоритету разом з іншими правдоподібними речами.

Потім почався плановий scrub в неділю вранці. На півдорозі помилки контрольної суми почали зростати на двох різних дисках у тому самому vdev. On-call замінив «відомий поганий диск» першим, очікуючи, що помилки припиняться. Вони не припинилися. Під час resilver ще один диск почав логувати ресети транспорту. Тепер пул був DEGRADED і бурхливий.

Неправильне припущення було тонким: вони вважали, що помилки контрольної суми ведуть себе як перерозподілені сектори SMART — прив’язані до диска. Але помилки контрольної суми ZFS часто бувають шлях-специфічними. Після години перестановок хтось нарешті глянув в kernel журнали і помітив повторювані ресети лінку на тому ж SAS-порті.

Корінь виявився у маргінальному SAS-breakout-кабелі, який був зігнутий так, що виглядав гарно на фото, але погано з точки зору фізики. Кабель працював під легким навантаженням і відмовляв під тривалим scrub/resilver. Після заміни «поганий диск» перестав бути поганим. Команда зробила висновок: помилка контрольної суми — доказ корупції, а не вирок конкретному диску.

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

Інша компанія мала ініціативу продуктивності: скоротити час scrub і вікна бекапів. Вони підвищили паралелізм у завданнях резервного копіювання і налаштували стек сховища під пропускну здатність. Scrub завершувались швидше, дашборди виглядали краще, і всі аплодували хітовим графікам.

Місяць потому під час scrub почали з’являтися помилки контрольної суми по кількох пулах — переважно на системах зі старішими експандерами. Читання стали більш агресивними та конкурентними. Експандери почали показувати свій вік: випадкові флапи лінку, повтори та тонкі події корупції, які ZFS помічав як невідповідності контрольних сум.

Оптимізація не «створила» корупцію з нічого. Вона перетворила маргінальну систему на відтворювану відмову. Раніше середовище ніколи не витримувало такий I/O-патерн довго для проявлення слабкостей. Тепер воно робило це за розкладом, на піку робочого дня.

Виправлення не полягало в постійному зниженні продуктивності. Вони перенесли scrubs у тихіший час, зменшили конкурентність під час scrub, оновили прошивку експандера там, де безпечно, і замінили найгірше обладнання. Але головне — культура змінилася: тюнінг продуктивності тепер вимагав план перевірки на надійність, а не лише діаграму пропускної здатності.

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

В одному підприємстві команда зберігання мала звичку, яка здавалася бюрократичною: щоквартально вони запускали scrub, експортували останній звіт scrub і архівували zpool status -v разом з kernel логами з того вікна. Вони також маркували відсіки дисків серіями by-id. Це було нудно. Але саме те, що потрібно під час реального інциденту.

Однієї ночі помилки контрольної суми різко зросли на члені mirror. Оскільки у них були базові артефакти, вони одразу знали дві речі: диск раніше ніколи не показував CRC-помилок, і відсік мав історію ресетів лінку два роки тому з іншим диском. Той самий відсік. Інший диск. Та сама сімейство симптомів.

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

Короткий звіт для менеджменту був теж нудний: «Ми виправили несправний інтерконект і підтвердили цілісність». Без драми, без героїзму, просто система, яка виконала обіцянки. Оце і є робота.

Поширені помилки: симптом → корінна причина → виправлення

1) «Помилки контрольної суми зростають, отже негайно заміняємо диск»

Симптом: CKSUM інкрементується, але SMART показує зростання UDMA CRC помилок і немає перерозподілених секторів.

Корінна причина: корупція на рівні кабелю/backplane/конектора, а не відмова носія.

Виправлення: замініть/пересадіть кабелі, перемістіть диск в інший відсік, перевірте контакти backplane; потім scrub і спостереження.

2) «Ми очистили помилки — і вони зникли, отже все виправлено»

Симптом: Хтось виконав zpool clear; дашборд тихий тиждень.

Корінна причина: лічильники скинуті; підлягаюча причина лишається. Ви втратили трендові дані.

Виправлення: ставте zpool clear як крок пост-ремедіації з подальшими scrub і моніторингом.

3) «Помилки з’явилися після scrub, отже scrub спричинив корупцію»

Симптом: Вперше помітили помилки під час scrub.

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

Виправлення: продовжуйте scrubs; змініть час/спосіб scrub; виправте слабке обладнання і перевірте контрольними scrubs.

4) «Пул ONLINE, отже дані в порядку»

Симптом: Пул показує ONLINE, але лічильники CKSUM ненульові.

Корінна причина: надмірність маскує корупцію, але корупція все одно сталася.

Виправлення: дослідіть, виправте і підтвердіть відсутність нових помилок під навантаженням. ONLINE — не підпис про повне здоров’я.

5) «Багато дисків мають помилки контрольної суми, отже у нас множинні відмови дисків»

Симптом: Кілька дисків у тій самій шафі показують інкременти CKSUM в ту саму годину.

Корінна причина: спільний компонент (HBA, експандер, backplane, PSU) працює збоїть.

Виправлення: мапуйте топологію; націлюйтеся на спільну точку; перевіряйте логи на ресети; міняйте кабелі і тестуйте.

6) «ZFS занадто чутливий; вимкнемо checksums»

Симптом: Хтось пропонує відключити перевірку контрольними сумами або ігнорувати події.

Корінна причина: непорозуміння: ZFS виявляє реальну корупцію, яку ваш стек раніше пропускав.

Виправлення: залишайте checksumming; виправляйте апаратний шлях; покращуйте моніторинг і вікна обслуговування.

7) «ECC скориговані помилки нешкідливі»

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

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

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

8) «Ми можемо тримати degraded пул днями під час розслідування»

Симптом: RAIDZ vdev деградований і хтось хоче чекати на постачання.

Корінна причина: тривале експонування: ще одна відмова — і ви відновлюєте з бекапу.

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

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

Покроковий триаж (робіть у цьому порядку)

1. Захопіть стан: збережіть вивід zpool status -v і позначте час. Поки нічого не очищайте.
2. Перевірте, чи помилки виправні: шукайте «errors: No known data errors» проти вказаних шляхів/об’єктів.
3. Перевірте тренд: виконайте zpool status ще раз після навантаження або через 10–30 хв. Чи CKSUM зростає?
4. Перевірте події: zpool events -v, щоб прив’язати помилки до scrub/resilver/звичайних читань.
5. Перегляньте логи ядра: шукайте ресети, помилки лінку, таймаути в той самий інтервал.
6. Перевірте SMART/NVMe health: зосередьтесь на CRC, reallocated/pending, media errors, журналах помилок.
7. Замапте топологію: чи уражені диски ділять порт/backplane/експандер? Якщо так — підозрюйте спільний компонент.
8. Фізична ремедіація: переставте/замініть кабель, перемістіть дискові слоти, поміняйте порт HBA, перевірте живлення.
9. Очистіть помилки: тільки після зміни, потім запустіть контрольований scrub або робоче навантаження з моніторингом.
10. Замініть обладнання при потребі: диск, кабель, експандер, HBA, DIMM — згідно з доказами.
11. Підтвердіть: завершіть scrub без нових помилок; переконайтесь, що логи чисті; моніторьте лічильники тиждень.
12. Документуйте: що змінили, які докази це підтримували і як виглядає «норма» тепер.

Коли замінювати диск (мої жорсткі критерії)

• SMART показує зростання reallocated секторів, pending секторів або offline uncorrectables.
• NVMe повідомляє ненульові media_errors або повторювані записи журналу цілісності.
• Помилки контрольної суми продовжують зростати на тому ж диску після того, як ви поміняли кабелі/порти і перевірили логи.
• Диск — аутсайдер у mirror (інша сторона чиста) і патерн помилок слідує за диском при переміщенні в інший відсік.

Коли спочатку підозрювати кабелі/backplane/експандер

• Зростають SMART UDMA CRC помилки.
• Логи ядра показують ресети лінку, PHY ресети або помилки транспорту.
• Кілька дисків в одному enclosure/ланцюгу портів показують проблеми.
• Помилки виникають під час тривалих послідовних читань (scrub/resilver) більше, ніж під випадковим навантаженням.

Коли підозрювати ОЗП/CPU/платформну стабільність

• EDAC/MCE логи показують скориговані або некориговані помилки пам’яті.
• Помилки контрольної суми з’являються по всіх пристроях без послідовної фізичної топології.
• Ви бачите незрозумілі краші, паніки або проблеми з даними поза ZFS також.
• Система використовує non-ECC ОЗП для важливих навантажень.

Цікаві факти та історичний контекст (те, що вчишся лише після опіків)

• Факт 1: ZFS виник в Sun Microsystems на початку 2000-х з явною метою end-to-end цілісності даних, а не тільки «швидка файлова система».
• Факт 2: Традиційні стекі зберігання часто покладалися на диск для виявлення поганого читання за допомогою секторного ECC; тиха корупція може обійти це і все одно повернути «success».
• Факт 3: ZFS зберігає контрольні суми в метаданих, а не поряд з блоком даних, зменшуючи шанс, що один поганий запис пошкодить і дані, і їхню суму.
• Факт 4: Scrubs — це не «театр обслуговування». Це систематичне читання пулу, щоб виявити латентні помилки до того, як ваш бекап це зробить.
• Факт 5: Зростання дуже великих дисків зробило довгі вікна rebuild/resilver нормою, що підвищило важливість раннього виявлення й ремонту тихої корупції.
• Факт 6: SATA CRC помилки вже давно є класичною підказкою «це не диск», вони звинувачують цілісність сигналу і конектори більше, ніж носій.
• Факт 7: Деякі з найгірших інцидентів з помилками контрольної суми пов’язані з експандерами/backplane, бо вони створюють корельовані відмови на багатьох дисках одночасно.
• Факт 8: ZFS може прозоро відновлювати пошкоджені дані на надмірних vdev, але лічильники помилок все одно інкрементуються — бо ви маєте знати, що це сталося.
• Факт 9: Стан пулу «ONLINE» може співіснувати з серйозними прихованими проблемами; ZFS віддає пріоритет доступності, при цьому повідомляючи про проблеми цілісності, щоб ви могли діяти.

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

1) Чи означають помилки контрольної суми завжди втрату даних?

Ні. Якщо у вас є надмірність і ZFS показує «No known data errors», ZFS, ймовірно, відновив пошкоджені блоки. Це все одно ознака корупції десь, але не обов’язково втрачених даних додатка.

2) У чому різниця між READ errors і CKSUM errors у zpool status?

READ errors означають, що пристрій не зміг доставити дані (I/O failure). CKSUM errors означають, що дані були доставлені, але не відповідали очікуваній контрольній сумі. READ кричить «не читається». CKSUM шепоче «я прочитав щось, але воно неправильне».

3) Чи слід одразу запускати scrub при виявленні помилок контрольної суми?

Зазвичай так — якщо ви можете за цим спостерігати. Scrub може і відновити, і відтворити проблему під навантаженням, що корисно для діагностики. Не запускайте його в сліпому режимі під час ризикового вікна.

4) Чи безпечно виконувати zpool clear?

Це безпечно в тому сенсі, що команда не видаляє дані. Небезпечно операційно, якщо ви використовуєте її, щоб приховати докази. Очищайте після ремедіації, щоб виявити рецидиви.

5) У мене помилки контрольної суми на одному диску mirror. Чи можна їх ігнорувати?

Можна відкласти заміну, якщо показник стабільний і докази вказують на разову подію (наприклад, транзientний ресет лінку). Але не ігноруйте рекурентне зростання. Mirrors прощають, але не творять дива.

6) Чи може погана пам’ять спричиняти помилки контрольної суми ZFS?

Так. Погана ОЗП може пошкодити дані в пам’яті до запису (тому ZFS чесно проставить контрольну суму для пошкоджених даних) або після читання. ECC зменшує ризик і дає докази через EDAC/MCE логи.

7) Чому помилки контрольної суми часто з’являються під час scrub/resilver?

Тому що ці операції читають багато даних і навантажують весь I/O-шлях безперервно. Маргінальні кабелі, експандери і диски не люблять тривалі послідовні навантаження.

8) Якщо SMART каже «PASSED», чому ZFS повідомляє помилки?

SMART «PASSED» — не повний висновок про здоров’я; це мінімальна перевірка. ZFS вимірює фактичні результати цілісності. Довіряйте системі, яка перевіряє дані end-to-end.

9) Що робити, якщо zpool status -v показує файли з помилками?

Це означає, що ZFS має known data errors, які не вдалося виправити. Ваше дерево рішень змінюється: ідентифікуйте уражені dataset-и, відновіть з бекапу/снепшоту де можливо і негайно вирішіть апаратне питання.

10) Чи означають помилки контрольної суми, що HBA поганий?

Іноді. Якщо помилки корелюються між кількома дисками, підключеними до того ж HBA порту, або з’являються ресети/таймаути контролера в логах, HBA (або його прошивка/драйвер) швидко стає підозрюваним.

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

Помилки контрольної суми — це ZFS, що виконує свою роботу: виявляє корупцію, яку інший стек із задоволенням віддав би вашим додаткам. Ваше завдання — перетворити «CKSUM=14» на конкретне виправлення.

1. Спочатку зберіть докази: zpool status -v, zpool events -v і логи ядра навколо часу помилок.
2. Класифікуйте патерн: одиночний пристрій проти множинних, тільки scrub проти будь-коли, CRC проти reallocated, кореляція топології.
3. Виправляйте ймовірну корінну причину (найчастіше — кабелі/backplane) перш ніж сліпо міняти диски.
4. Очищайте помилки тільки після зміни, потім запускайте контрольований scrub під наглядом логів.
5. Якщо помилки повторюються, замініть компонент, на який вказують докази — диск, кабель, експандер, HBA або DIMM — і перевірте чистим scrub.

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