Моніторинг SMART у ZFS: кореляція попереджень дисків із помилками ZFS

Ментальна модель: що знає ZFS проти того, що знає SMART

ZFS і SMART не є супротивниками. Це двоє свідків однієї події, що стоять на різних кутах вулиці.
Один бачив обличчя підозрюваного. Інший почув скрип шин. Жодна з історій не є повною самостійно.

ZFS: доказова, енд-ту-енд і безжально буквальна

ZFS дивиться на світ через операції вводу/виводу та контрольні суми. Коли ZFS читає блок, він перевіряє контрольну суму.
Якщо контрольна сума не співпадає, ZFS позначає це як checksum error. Якщо пристрій відмовляється читати
або писати, ZFS позначає це як I/O error. Якщо ZFS може виправити погані дані завдяки надлишковості (mirror/RAIDZ),
він інкрементує лічильники і продовжує роботу, часто поки ви спите.

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

SMART: прогнозний, залежний від вендора і іноді драматичний

SMART — набір самоопрацьованих лічильників і результатів тестів від прошивки диска. Він знає про рекомпоновані сектори,
pending sectors, read disturb, витривалість, CRC помилки на SATA-лінії та інше. Він може запускати самотести.
Він також може приховувати проблеми через «нормалізацію атрибутів», коли сирі значення важливі, але «VALUE/WORST/THRESH»
намагаються заспокоїти вас допоки вже не надто пізно.

SMART має велике «сліпе» місце: якщо проблема вище по ланцюжку (кабель, HBA, backplane, живлення), диск може виглядати здоровим,
в той час як ZFS тоне у I/O помилках. Або SMART може показувати UDMA CRC помилки, які кричать «кабель», поки лічильники ZFS ростуть,
і вам захочеться все одно відправити диск на RMA, бо це емоційно приємно.

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

Одна перефразована ідея Річарда Кука (resilience engineering): Успіх в операціях досягається завдяки постійному пристосуванню людей до складності під тиском.

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

• ZFS був спроєктований з урахуванням тихої корупції даних. End-to-end контрольні суми були реакцією на стек зберігання, що вважав диски «переважно правдивими».
• SMART передував сучасним механізмам цілісності файлових систем. Він з’явився тоді, коли ОС мала дуже обмежену видимість внутрішньої поведінки дисків.
• SMART-атрибути на практиці не стандартизовані. Назви виглядають послідовно; значення та масштаб часто різняться, особливо між вендорами та поколіннями SSD.
• «UDMA CRC error count» — один із найпрактичніших атрибутів. Він часто вказує на проблеми кабелю/backplane, а не на відмову медіа.
• ZFS scrub-операції спочатку були контроверсійними. Люди хвилювалися, що scrubs «зношують» диски; насправді scrubs допомагають виявити латентні помилки до того, як rebuild загострить проблему.
• Ранні SSD в SMART були надто оптимістичними. Деякі пристрої демонстрували майже ідеальне здоров’я до самої відмови; сучасна телеметрія NVMe краща, але теж не догма.
• Раніше RAID rebuild вважали «страшною частиною». З багатотерабайтними дисками невідновлювані помилки при ресилвері стали практичним ризиком; scrubs і контрольні суми ZFS допомагають виявляти ризики раніше.
• Лічильники помилок ZFS можуть зростати без видимого збою для користувача. Self-healing reads виправляють дані безшумно у редундантних vdev; «немає простою» не означає «немає проблеми».

Карта сигналів: попередження SMART ↔ помилки ZFS

Почніть з типів помилок ZFS (бо вони прив’язані до коректності даних)

• Checksum errors: дані, що повернув пристрій, не співпали з очікуваною контрольною сумою. Часто проблема медіа, інколи — контролер/кабель, іноді оперативна пам’ять (якщо без ECC і не пощастило).
• Read errors / write errors: пристрій провалив I/O. Часто скидання лінку, таймаути, живлення/кабель або пристрій, що здався.
• Device removal / faulted: ОС втратила пристрій. Думайте: хитке живлення SATA, скидання expander, проблеми HBA або сам диск, який робить жорсткий ресет.

Тепер SMART-атрибути, що справді заслуговують вашої уваги

«Найкращі» SMART-атрибути — ті, що мають чітке фізичне значення і гідну кореляцію з відмовою:
pending sectors, reallocated sectors, uncorrectable errors і interface CRC errors.
Температура також важлива, але здебільшого як фактор ризику.

• Reallocated_Sector_Ct: сектори, які диск перемапив. Ненульове значення не означає миттєву смерть, але зростання — тривожна траєкторія.
• Current_Pending_Sector: сектори, які не вдалося прочитати і які чекають перезапису для перемапування. Часто це атрибут «втрати даних скоро».
• Offline_Uncorrectable / UNC: невиправні помилки читання, знайдені під час офлайн-сканування або нормальної роботи.
• UDMA_CRC_Error_Count: корупція даних на лінії (SATA). Майже завжди проблема кабелю/backplane/конектора, а не медіа диска.
• SMART overall-health: корисний, коли він падає; ненадійний, коли проходить.
• NVMe Media and Data Integrity Errors: сильний сигнал для NVMe-пристроїв, якщо ненульовий і зростає.
• Power_On_Hours / Power_Cycle_Count: контекст. Часті цикли живлення корелюють із дивними відмовами та проблемами конекторів.

Шаблони кореляції, на які можна покластися у вихідні

Шаблон A: ZFS checksum errors + pending sectors (або offline uncorrectables)

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

Шаблон B: ZFS I/O errors + UDMA CRC errors (SATA)

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

Шаблон C: ZFS device faults/removals + чистий SMART

Думайте про живлення і транспорт. Диски можуть зникати при маргінальному живленні, скиданнях expander або проблемах прошивки HBA.
SMART не завжди зафіксує це, бо диск не зазнав внутрішньої відмови; його просто «вивели із реальності».

Шаблон D: SMART «PASSED» + ZFS checksum errors

SMART overall-health — грубий інструмент. Деякі диски не позначають відмову, поки ситуація вже не горить.
Ставте контрольні суми ZFS вищим пріоритетом для цілісності даних, а потім досліджуйте сирі SMART-атрибути і журнали транспорту.

Шаблон E: Немає помилок ZFS, але попередження SMART зростають

Тут люди розслабляються. ZFS ще не помітив некоректних даних поки що. SMART каже, що диск виконує додаткову роботу, щоб зберегти вигляд здоров’я.
Якщо SMART-атрибути — ті «реальні» (pending/uncorrectable), плануйте контрольовану заміну. Якщо ж це лише температурні сплески або одна перенаціоналізація роками тому, спостерігайте уважніше.

Жарт №1: SMART — як лампочка «check-engine»: іноді це катастрофа, іноді просто відчинена кришка бензобака, і в будь-якому разі ви запізнюєтесь на роботу.

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

Перший: з’ясуйте, на що саме скаржиться ZFS

1. Запустіть zpool status -xv і читайте його як контракт. Шукайте лічильники READ, WRITE, CKSUM та будь-які повідомлення про «too many errors».
2. Визначте точний пристрій і vdev (за persistent ID, а не рулеткою /dev/sdX).
3. Перевірте, чи лічильники все ще зростають (запустіть статус ще раз після деякого I/O або через хвилину). Статичні історичні помилки відрізняються від поточних.

Другий: вирішіть, чи пахне це медіа, транспортом чи хостом

1. Підозра на медіа: checksum errors на одному диску, SMART pending/uncorrectable/reallocated зростають, самотест провалюється.
2. Підозра на транспорт: I/O errors, скидання пристрою, CRC помилки, кілька дисків на тому самому backplane порту, журнали ядра показують link resets/таймаути.
3. Підозра на хост: помилки по багатьом vdev одночасно, скидання HBA, PCIe AER повідомлення, нестабільність пам’яті, баги прошивки.

Третій: оберіть безпечну дію, що швидко знижує ризик

1. Якщо надлишковість ціла: запустіть scrub, щоб спричинити читання; зберіть SMART; заплануйте заміну або роботу з кабелями в робочий час.
2. Якщо надлишковість скомпрометована (degraded RAIDZ/mirror вже втратив учасника): припиніть експерименти. Мінімізуйте навантаження, серйозно виконайте резервне копіювання/знімки і замініть найімовірнішого підозрюваного першим.
3. Якщо пристрій «флапає»: стабілізуйте транспорт (перепідключіть/замініть кабель, перемістіть порт) перед resilver. Resilver через хиткий лінк — просто перфоменс-арт.

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

Нижче наведені практичні кроки, які ви можете виконати на типовому Linux ZFS хості (OpenZFS). Кожне завдання містить: команду, реалістичний фрагмент виводу,
що це означає і яке рішення ухвалюється. Виконуйте їх у порядку, коли ви на виклику. Виконуйте їх повільно, коли не горить.

Завдання 1: Підтвердіть, чи якийсь пул незадоволений

cr0x@server:~$ zpool status -x
pool 'tank' is healthy
pool 'backup' has experienced errors

Значення: -x показує лише проблеми. «Healthy» не означає «ідеально», це означає, що немає відомих помилок, що вимагають дії.

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

Завдання 2: Отримайте детальний вигляд ZFS (ваше первинне джерело)

cr0x@server:~$ zpool status -xv backup
  pool: backup
 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 0B in 02:11:30 with 2 errors on Sun Dec 22 03:10:12 2025
config:

        NAME                                     STATE     READ WRITE CKSUM
        backup                                   ONLINE       0     0     0
          raidz1-0                               ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ7...     ONLINE       0     0     2
            ata-WDC_WD80EFAX-68LHPN0_VKJ8...     ONLINE       0     0     0
            ata-WDC_WD80EFAX-68LHPN0_VKJ9...     ONLINE       0     0     0

errors: No known data errors

Значення: Виникли дві checksum errors і були виправлені. «No known data errors» означає, що ZFS вважає, що він відновив або ізолював ушкодження.

Рішення: Ставте виправлені checksum errors як попереджувальний постріл. Не очищуйте лічильники ще; спочатку корелюйте з SMART та журналами транспорту.

Завдання 3: Зіставте ID пристрою ZFS з блоковим пристроєм ОС

cr0x@server:~$ ls -l /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ7*
lrwxrwxrwx 1 root root 9 Dec 26 01:12 /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ7XXXX -> ../../sdc

Значення: Персистентний ID вказує зараз на /dev/sdc. Завтра може не так бути.

Рішення: Використовуйте шляхи з /dev/disk/by-id для всіх операцій zpool replace. Запишіть відповідність слот/серійник, поки ви спокійні.

Завдання 4: Перевірте SMART overall-health (швидко, але не вирішально)

cr0x@server:~$ sudo smartctl -H /dev/sdc
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.0] (local build)
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Значення: Диск не визнає відмови. Це не те саме, що «диск у порядку».

Рішення: Перейдіть до атрибутів і журналів помилок. Не дозволяйте «PASSED» перебити контрольні суми ZFS.

Завдання 5: Отримайте SMART-атрибути, що корелюють з відмовою медіа

cr0x@server:~$ sudo smartctl -A /dev/sdc
=== START OF READ SMART DATA SECTION ===
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   200   200   000    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0010   200   200   000    Old_age   Offline      -       2
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Значення: Існують pending і uncorrectable сектори. Це диск, який не зміг надійно прочитати два сектори.

Рішення: Якщо цей диск у редундантному vdev: плануйте заміну. Якщо це single-disk пул: зробіть резервну копію зараз, потім замініть. Також запустіть long self-test для підтвердження, але не чекайте, поки воно «стане гірше».

Завдання 6: Прочитайте SMART error log (часто показує патерн)

cr0x@server:~$ sudo smartctl -l error /dev/sdc
=== START OF READ SMART DATA SECTION ===
SMART Error Log Version: 1
ATA Error Count: 3
  CR = Command Register [HEX]
  FR = Features Register [HEX]
  ...
Error 3 occurred at disk power-on lifetime: 42110 hours
  When the command that caused the error occurred, the device was active or idle.
  After command completion occurred, registers were:
  ER -- ST COUNT  LBA_48  ...
  40 -- 51 0008  00000000f3a1c2  ...  UNC

Значення: UNC вказує на невиправну помилку читання у конкретному LBA. Це збігається з pending/uncorrectable секторами та checksum-питаннями ZFS.

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

Завдання 7: Запустіть SMART long test (доказ, а не терапія)

cr0x@server:~$ sudo smartctl -t long /dev/sdc
=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 780 minutes for test to complete.

Значення: Диск просканує поверхню медіа. Це може виявити більше UNC помилок.

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

Завдання 8: Перегляньте результати SMART self-test

cr0x@server:~$ sudo smartctl -l selftest /dev/sdc
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       10%     42112         16062914
# 2  Short offline       Completed without error       00%     42001         -

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

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

Завдання 9: Шукай проблеми транспорту/зв’язку в журналах ядра

cr0x@server:~$ sudo dmesg -T | egrep -i 'ata[0-9]|sas|reset|link|I/O error|blk_update_request' | tail -n 20
[Tue Dec 24 02:12:11 2025] ata7: hard resetting link
[Tue Dec 24 02:12:12 2025] ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Tue Dec 24 02:12:12 2025] ata7.00: configured for UDMA/133
[Tue Dec 24 02:12:12 2025] blk_update_request: I/O error, dev sdc, sector 16062914 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Tue Dec 24 02:12:13 2025] ata7.00: failed command: READ FPDMA QUEUED

Значення: Скидання лінку + помилки читання. Може бути диск або кабель; поєднуйте з SMART для рішення. За наявності UNC/pending диск має достатньо доказів провини.

Рішення: Якщо CRC = 0, але присутні UNC, замініть диск. Якщо CRC зростає, виправляйте кабелі також; буває і комбіновано.

Завдання 10: Перевірте UDMA CRC спеціально (класичне «не RMA кабель»)

cr0x@server:~$ sudo smartctl -A /dev/sdd | egrep 'UDMA_CRC_Error_Count|CRC'
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       41

Значення: Виникали CRC помилки на SATA-лінку. Якщо це число зростає з часом, ваш шлях транспорту корумпує або втрачає кадри.

Рішення: Перепідключіть/замініть SATA-кабель, перевірте конектори backplane, огляньте power splitters і подумайте про переміщення диска на інший порт. Не міняйте диск лише через CRC, якщо інші докази не вказують на медіа.

Завдання 11: Визначте, в якому фізичному слоті диск знаходиться (припиніть гадати)

cr0x@server:~$ sudo udevadm info --query=all --name=/dev/sdc | egrep 'ID_SERIAL=|ID_SERIAL_SHORT=|ID_PATH=|DEVLINKS='
E: ID_SERIAL=WDC_WD80EFAX-68LHPN0_VKJ7XXXX
E: ID_SERIAL_SHORT=VKJ7XXXX
E: ID_PATH=pci-0000:3b:00.0-ata-7
E: DEVLINKS=/dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_VKJ7XXXX /dev/disk/by-path/pci-0000:3b:00.0-ata-7

Значення: Ви можете зіставити диск з портом контролера через by-path. У шасі з маркованими відсіками це врятує від витягування невірного диска.

Рішення: Документуйте відповідність (серійник → відсік). Якщо не можете надійно зіставити — ви не керуєте сховищем; ви граєте в азарт з обладнанням.

Завдання 12: Запустіть scrub (контрольоване з’ясування правди)

cr0x@server:~$ sudo zpool scrub backup
cr0x@server:~$ zpool status backup
  pool: backup
 state: ONLINE
  scan: scrub in progress since Thu Dec 26 01:20:05 2025
        1.12T scanned at 1.05G/s, 410G issued at 384M/s, 16.2T total
        0B repaired, 2.50% done, 11:42:16 to go

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

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

Завдання 13: Перевірте деталі помилок ZFS для уражених файлів (коли ZFS знає)

cr0x@server:~$ zpool status -v backup
  pool: backup
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.
...
errors: Permanent errors have been detected in the following files:

        backup/media@autosnap_2025-12-25:some/path/video.mp4

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

Рішення: Відновіть з резервної копії/знімка/репліки. Потім дослідіть апаратну частину. Також: припиніть очищувати помилки; вам потрібен аудит доти, поки корінь не виправлено.

Завдання 14: Правильно замініть несправний диск (користуйтеся by-id)

cr0x@server:~$ sudo zpool replace backup ata-WDC_WD80EFAX-68LHPN0_VKJ7XXXX ata-WDC_WD80EFAX-68LHPN0_VNEW1234
cr0x@server:~$ zpool status backup
  pool: backup
 state: ONLINE
  scan: resilver in progress since Thu Dec 26 02:01:44 2025
        1.84T scanned at 512M/s, 620G issued at 172M/s, 16.2T total
        610G resilvered, 3.74% done, 07:55:10 to go
config:

        NAME                                       STATE     READ WRITE CKSUM
        backup                                     ONLINE       0     0     0
          raidz1-0                                 ONLINE       0     0     0
            ata-WDC_WD80EFAX-...VKJ7XXXX           ONLINE       0     0     6  (resilvering)
            ata-WDC_WD80EFAX-...VKJ8YYYY           ONLINE       0     0     0
            ata-WDC_WD80EFAX-...VKJ9ZZZZ           ONLINE       0     0     0
            ata-WDC_WD80EFAX-...VNEW1234           ONLINE       0     0     0  (resilvering)

Значення: Resilver розпочався. ZFS зберігає старий пристрій до завершення, якщо це можливо. Checksum помилки на старому пристрої можуть продовжуватися під час його читання у процесі resilver.

Рішення: Слідкуйте за зростанням помилок на інших дисках. Якщо resilver сильно сповільнився або пристрої скидаються — призупиніть і виправте транспорт перед форсуванням процесу.

Завдання 15: Очищайте лічильники тільки після виправлення причини

cr0x@server:~$ sudo zpool clear backup
cr0x@server:~$ zpool status -xv backup
  pool 'backup' is healthy

Значення: Лічильники скинуто. Це не «вилікувано»; це «чистий аркуш».

Рішення: Очищайте лише після заміни/ремонту і після чистого scrub. Інакше ви видаляєте власні судові докази і запрошуєте повторні інциденти.

Завдання 16: SMART/health для NVMe (інша лексика, та сама робота)

cr0x@server:~$ sudo smartctl -a /dev/nvme0
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Critical Warning:                   0x00
Temperature:                        47 Celsius
Available Spare:                    100%
Percentage Used:                    6%
Media and Data Integrity Errors:    12
Error Information Log Entries:      44

Значення: Ненульові і що зростають media/data integrity errors — сильний предиктор проблем для NVMe.

Рішення: Корелюйте з checksum/I/O помилками ZFS і скиданнями NVMe в журналі ядра. Якщо помилки зростають — плануйте заміну; NVMe часто відмовляє «швидко», коли починає.

Жарт №2: Resilver через хиткий кабель — як намагатися витерти протікання, поки хтось продовжує відкривати кран — технічно можливо, але морально недобре.

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

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

Середня SaaS-компанія тримала об’єктне сховище на ZFS на парі storage-серверів. Моніторинг показував SMART «PASSED» по всій інфраструктурі.
ZFS повідомляв кілька checksum errors під час scrubs, завжди виправлених, завжди на одному і тому ж vdev. On-call обертання ставилось до цього як до нешкідливого фонового шуму.

Неправильне припущення було просте: «Якщо пул ONLINE і SMART каже PASSED, диск здоровий.» Це комфортна історія, бо дозволяє нічого не робити.
А нічого не робити — найпопулярніша операційна стратегія на Землі.

Через тижні один диск в тому vdev почав накопичувати Current_Pending_Sector і Offline_Uncorrectable лічильники. Ніхто не подивився, бо ніхто не мав дашбордів для сирих SMART-атрибутів,
лише overall-health. Потім другий диск у тій же RAIDZ групі дав таймаути під час інтенсивного інжесту.

ZFS робив, що міг, але RAIDZ не магія, коли кілька членів хворіють. Пул деградував, продуктивність впала, і scrub/resilver боролися з production I/O.
Інцидент не був миттєвою втратою даних — він був гірший у корпоративному сенсі: повільний, шумний простої з частковими помилками і купою «спробуйте пізніше».

Післяінцидентне виправлення було нудним: алерти на сирі атрибути, алерти на виправлені помилки ZFS і вимога прийняття людського рішення при будь-якому русі лічильників.
Команда не позбулася відмов дисків. Вони позбулися несподіванок.

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

Фінансова установа захотіла швидші scrubs. Вони читали, що збільшення пропускної здатності scrub допомагає виявити латентні помилки швидше.
Це правда. Вони також хотіли скоротити «вікна обслуговування», тому підвищили паралелізм, запланували scrubs у робочий час і налаштували систему пріоретизувати scrub I/O.

Перші scrubs були блискавичними. Всі себе хвалили. Потім вони наштовхнулися на vdev з маргінальним диском і граничною SAS backplane конекцією.
Агресивний scrub породив бурю: скидання лінків, таймаути команд, повтори. Лічильники ZFS зросли. Графіки латентності стали абстрактним мистецтвом.

Підсумок: оптимізація змінила режим відмови. Замiсть того, щоб акуратно виявляти кілька поганих секторів з часом, вони змусили систему працювати в режимі високого стресу,
що підсилило нестабільність транспорту і спричинило видимі клієнту сплески латентності. Гірше — їх моніторинг трактував «scrub in progress» як «шум обслуговування» і приглушив алерти.

Виправлення не було «ніколи не scrub». Було: scrub регулярно, але з контрольованим впливом; не приглушуйте неправильні алерти; трактуйте помилки транспорту під час scrub як топ-рівневий сигнал.
Вони також навчилися розподіляти scrubs по хостах і уникати синхронізованих I/O штормів.

В результаті вони отримали повільніші scrubs і менше інцидентів. Такий обмін вартий. Продуктивність — це фіча; передбачуваність — продукт.

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

Компанія тримала великий ZFS пул для зберігання VM. Ніщо героїчного. Вони робили три речі постійно:
щомісячні scrubs, щотижневий перегляд сирих SMART-атрибутів і суворе іменування пристроїв через /dev/disk/by-id з живою картою серійник→відсік.

Одної п’ятниці вдень ZFS повідомив кілька checksum errors на одному диску під час scrub. SMART показав UDMA_CRC_Error_Count в зростанні, але pending секторів не було.
Інженер на чергуванні не панікував. Вони не замовили екстрену доставку диска. Вони виконали чекліст.

Вони перепідключили диск, замінили SATA-кабель і перемістили порт на інший контролерний лейн. CRC помилки одразу припинили зростати.
Наступний scrub пройшов чисто. Лічильники ZFS залишилися стабільними.

«Порятунок» не був героїчною дебаг-сесією. Це була наявність базової інформації і мапінгу, що дозволила інженеру впевнено торкнутися одного кабеля і знати, що це правильний.
Звіт по інциденту був коротким. Так ви і знаєте, що день пройшов добре.

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

1) «ZFS checksum errors на одному диску, SMART каже PASSED»

Симптом: ZFS CKSUM інкрементує; SMART overall-health проходить.

Корінь: SMART overall-health не чутливий; сирі атрибути можуть показувати pending/uncorrectables. Або корупція в транспорті (кабель/контролер), а не в медіа.

Виправлення: Перевірте SMART сирі атрибути і журнал помилок; перевірте журнали ядра на скидання; якщо є pending/UNC — замініть диск. Якщо домінують CRC/скидання — виправте кабелі/HBA першими.

2) «Багато I/O помилок на кількох дисках в одному корпусі»

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

Корінь: Спільний компонент: backplane, expander, шина живлення, HBA, прошивка або хиткий mini-SAS кабель.

Виправлення: Перевірте шлях транспорту; замініть expander порт/кабель; перевірте розподіл живлення. Не міняйте кілька дисків поспіль, якщо SMART медіа-помилки не підкріплюють це.

3) «CRC помилки зростають, але ZFS у порядку»

Симптом: UDMA_CRC_Error_Count зростає; ZFS поки не показує помилок.

Корінь: Інтегритет лінку деградує; повтори маскують проблему.

Виправлення: Замініть/закріпіть кабелі, почистіть конектори, перевірте правильне посадження. Якщо CRC припиняє інкрементуватися, ви, ймовірно, запобігли майбутньому інциденту ZFS.

4) «Scrub repaired 0B, але повідомив про помилки»

Симптом: У виводі scrub видно помилки, але нуль байт відремонтовано.

Корінь: Помилки можуть бути таймаутами I/O або транзитними проблемами транспорту, а не корекційною корупцією контрольних сум.

Виправлення: Перегляньте zpool status -v і журнали ядра; перевірте SMART CRC помилки і скидання контролера. Виправте транспорт; перезапустіть scrub.

5) «Resilver повільний і постійно перезапускається»

Симптом: Прогрес resilver зупиняється; пристрої скидаються; пул між DEGRADED/ONLINE.

Корінь: Нестабільність транспорту або живлення. Під час rebuild навантаження маргінальні лінки часто відмовляють частіше.

Виправлення: Стабілізуйте кабелі/backplane/живлення перш ніж продовжувати. Розгляньте зниження навантаження, паузу ресурсомістких задач і уникайте повторних ресетів пристроїв.

6) «Очистили ZFS помилки і тепер не знаємо, що трапилось»

Симптом: Історичні лічильники зникли; періодичні помилки повертаються; немає хронології.

Корінь: Передчасне zpool clear стерло докази до виправлення кореня.

Виправлення: Зберігайте лічильники до після ремедіації і чистого scrub. Використовуйте нотатки в тікеті, щоб зафіксувати лічильники та SMART сирі значення до і після.

7) «Замiнили диск і помилки переслідували слот»

Симптом: Новий диск відразу показує помилки, той самий відсік/порт.

Корінь: Проблема в слоті backplane, кабелі або порту HBA.

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

8) «ZFS повідомляє permanent errors, але SMART виглядає чистим»

Симптом: zpool status -v перераховує файли з permanent errors.

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

Виправлення: Відновіть постраждалі дані з резервної копії/репліки; потім дослідіть транспорт і стабільність пам’яті. Розглядайте це як інцидент цілісності даних, а не просто заміну диска.

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

Чекліст A: Коли приходить SMART-сповіщення

1. Запустіть zpool status -xv. Якщо ZFS вже повідомляє помилки, в першу чергу пріоритет для сигналів ZFS.
2. Визначте пристрій через симлінк /dev/disk/by-id. Зафіксуйте серійник і by-path.
3. Зберіть SMART: smartctl -H, -A, -l error, -l selftest.
4. Класифікуйте SMART-сповіщення:
   • Pending/uncorrectable/reallocated зростають: плануйте заміну диска.
   • CRC помилки зростають: виправляйте кабелі/backplane/порт.
   • Висока температура: виправте охолодження/потік повітря і перевірте знову; тепло прискорює відмови.
5. Запустіть scrub, якщо є надлишковість і операційний вплив прийнятний.
6. Прийміть рішення: замінити диск зараз, запланувати заміну або усунути транспорт і моніторити.

Чекліст B: Коли ZFS повідомляє checksum або I/O помилки

1. Не очищуйте помилки. Збережіть вивід zpool status -xv в тікет.
2. Перевірте, чи помилки зростають з часом. Якщо так — трактуйте як активний інцидент.
3. Зіставте пристрій: ls -l /dev/disk/by-id/ та udevadm info.
4. Зберіть SMART сирі атрибути і журнали помилок.
5. Перегляньте журнали ядра на скидання/таймаути і на патерни спільних шляхів (кілька дисків).
6. Якщо є індикатори медіа: замініть диск через zpool replace використовуючи by-id.
7. Якщо домінують індикатори транспорту: виправте кабелі/HBA/backplane, потім знову scrub.
8. Після ремедіації: scrub має бути чистим, тоді zpool clear для скидання лічильників.

Чекліст C: Перш ніж оголосити перемогу

1. Перевірте стабільність пулу: zpool status -x має бути без повідомлень.
2. Переконайтеся, що лічильники не інкрементують під нормальним навантаженням.
3. Перевірте, що SMART CRC припинив зростати (якщо це була проблема транспорту).
4. Заплануйте follow-up scrub (або підтвердіть, що scrub завершився чисто після виправлення).
5. Оновіть документацію серійник→відсік, щоб наступного разу було швидше і менш креативно.

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

1) Кому довіряти більше: ZFS чи SMART?

Для коректності даних довіряйте більше ZFS. Для прогнозування диска, що ось-ось підведе, корисні сирі SMART-атрибути.
Загальний SMART «PASSED» не є вето проти checksum помилок ZFS.

2) Чи замінювати диск після однієї checksum помилки?

Не завжди. Одна виправлена checksum помилка може бути транзиторною. Дії: запустіть scrub, перевірте SMART сирі атрибути,
перевірте журнали транспорту. Якщо помилки повторюються або SMART показує pending/uncorrectables — замінюйте. Якщо CRC зростає — виправляйте кабелі.

3) У чому різниця між ZFS scrub і resilver для діагностики?

Scrub читає і перевіряє існуючі дані по всьому пулу; це періодичний аудит цілісності. Resilver реконструює дані на замінений пристрій.
Обидва навантажують диски, але resilver більш терміновий і ризикований при хиткому транспорті, бо відновлює стан під навантаженням.

4) Чому я бачу ZFS помилки, але «errors: No known data errors»?

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

5) Чи є UDMA CRC помилки підставою для RMA диска?

Здебільшого ні. CRC помилки вказують на SATA-лінію: кабель, конектор, backplane, EMI. Замініть кабель, перепідключіть, перемістіть порт.
Якщо CRC перестає зростати — ви вирішили проблему. Якщо диск також має pending/UNC — тоді так, диск може бути несправний.

6) Як уникнути заміни невірного диска?

Використовуйте персистентні імена і мапінг. Працюйте з /dev/disk/by-id. Підтверджуйте серійник через smartctl -i і зіставляйте з відсіком через by-path або інструменти шасі.
Ніколи не довіряйте /dev/sdX іменам для планованого обслуговування.

7) Чи запускати SMART long tests на продакшн-дисках?

Так, але з урахуванням. Long tests додають навантаження і латентність. Плануйте їх, розносіть у часі і не запускайте, коли пул degraded, якщо тільки не збираєте термінові докази.
Якщо у вас вже є сильні індикатори відмови — замініть замість «тестування до повнішого краху».

8) Що робити, якщо SMART показує pending sectors, але ZFS не має помилок?

Pending sectors означає, що диск не зміг прочитати деякі дані надійно. ZFS могло не звертатися до цих блоків останнім часом.
Запустіть scrub, щоб примусити читання. Якщо pending/uncorrectable зберігається або зростає — замініть диск поки надлишковість ціла.

9) Чи можуть погані модулі пам’яті спричинити checksum помилки ZFS, які виглядають як проблеми диска?

Так, хоча це рідше, ніж іноді стверджують люди, які хочуть уникнути заміни диска. Якщо checksum помилки з’являються на багатьох пристроях або «перескакують»,
розгляньте стабільність пам’яті/CPU/PCIe хоста. ECC допомагає; але не робить вас безсмертними.

10) Чому помилки сплескують під час scrub?

Scrub читає усе. Латентні медіа-помилки, яких ніколи не зачіпали під звичайним навантаженням, раптово опрацьовуються.
Також проявляються проблеми транспорту, бо стійкий високий трафік підвищує ймовірність скидань/таймаутів.
Scrub, що виявляє помилки, виконує свою роботу; помилкою є ігнорувати результати.

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

Корелювати попередження SMART з помилками ZFS — це не збір ще більшої кількості графіків. Це перетворення двох недосконалих джерел правди на рішення.
Ваші найкращі результати виглядатимуть нудно: планова заміна диска, замінений кабель, scrub, що завершився чисто, і тікет, що закрився без драми.

1. Стандартизувати ідентифікацію: працюйте з ZFS через /dev/disk/by-id і тримайте карту серійник→відсік.
2. Алертити про значущі SMART сирі атрибути: pending, uncorrectable, тенденції reallocated; CRC-помилки для транспорту.
3. Сприймайте виправлені ZFS помилки як дієві сигнали: не екстрені, але не фоновий шум.
4. Scrub регулярно і цілеспрямовано: розносьте scrubs, стежте за помилками під час scrub і не приглушуйте ті алерти, які справді потрібні.
5. Очищайте лічильники лише після виправлення: докази спочатку, косметика потім.

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