ZFS Scrub проти SMART Long Test: що який інструмент виявляє

Ментальна модель: хто що перевіряє

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

• SMART long test — диск перевіряє сам себе: поверхню медіа, внутрішнє коригування помилок, позиціонування головки, стабільність зчитування та все інше, що вважатиме важливим прошивка виробника. Це орієнтовано на пристрій.
• ZFS scrub — ZFS читає ваші дані і перевіряє їх за end-to-end контрольними сумами, збереженими в метаданих, і потім відновлює з надмірності, якщо можливо. Це орієнтовано на дані.

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

Операційно: SMART — це прогнозний сигнал. Scrub — гарантія коректності. Вам потрібні обидва, бо продакшен-системи ламаються в різних вимірах, часто одночасно.

Одна цитата, яка має бути тату на кожному runbook зі сховищ: «Hope is not a strategy.» — James Cameron. Сховище — це місце, куди надії йдуть помирати.

Що реально знаходить (і виправляє) ZFS scrub

Що саме робить scrub

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

• Наявності та здоров’я надмірності.
• Того, щоб пошкодження обмежувалося однією стороною надмірності (або не перевищувало паритет).
• Того, щоб корупція була виявляема (невідповідність контрольної суми), а не невидима (ви записали неправильні байти і перевірили їх сумою).

Збої, які scrubs добре виявляють

Scrub відмінно ловить тиху корупцію даних у захищеному ZFS шляху. Це включає:

• Bit rot / латентні помилки секторів: сектори, які стали непрочитаними або повертають неправильні дані з часом.
• Погані зчитування, які «виглядають успішними» для диска: диск повертає дані, але вони неправильні. ZFS виявляє це через невідповідність контрольної суми.
• Проблеми з кабелями/контролерами, які призводять до пошкоджених передавань (іноді проявляються як checksum errors, а не як помилки читання).
• Невиправні помилки читання під час scrub: ZFS їх логирує і може відновити за наявності надмірності.

Збої, які scrub не виявляє

Scrub — не «діагностика диска», і в нього є сліпі зони:

• Нерозподілений простір не читається. Scrub не перевірить сектори, які ZFS не виділяв.
• Збої на шляху запису можуть залишитися непоміченими, якщо були записані неправильні дані і контрольна сума їх визнала коректними (це рідше, але буває через баги, неправильно спрямовані записи та корупцію пам’яті без ECC).
• Механіка диска, наприклад повільні пошуки, проблемні головки чи збій кешу, може прогресувати, поки ваш поточний робочий набір ще читається нормально.
• Тимчасові таймаути можуть не проявитися під час scrub-таймінгу; або ж з’являться тільки під іншим IO-патерном.

Сухо-дотепна реальність: scrub схожий на аудит витрат компанії. Він знаходить шахрайство в поданих чеках, але не те, що ніхто не подав.

Що означає «scrub repaired X» насправді

Якщо zpool status каже, що scrub «відремонтував» байти, ви дізналися рівно одну річ: пул віддав принаймні одну погану копію блоку, і ZFS знайшов іншу коректну копію. Це перемога для коректності, але також червоний прапорець. Це доказ проблемного компонента або шляху. Ваше завдання — з’ясувати який, перш ніж це перетвориться на мультидисковий збій під час resilver.

Scrub vs resilver — бо люди плутають

Scrub читає і перевіряє виділені дані на місці. Resilver — це реконструкція після заміни або повторного приєднання пристрою, копіювання необхідних даних для відновлення надмірності. Обидва виконують інтенсивні читання і обидва можуть виявити латентні помилки секторів. Але намір відрізняється:

• Scrub: «підтвердити, що існуючі дані пулу коректні».
• Resilver: «відбудувати надмірність і заповнити пристрій».

Якщо ви дізнаєтеся про латентні помилки читання лише під час resilver — ви дізналися занадто пізно.

Що реально знаходить (і прогнозує) SMART long test

Що роблять SMART long tests

SMART self-test — це діагностика під керуванням прошивки. Long (extended) тест зазвичай читає більшу або всю поверхню пристрою (реалізація сильно відрізняється), навантажуючи здатність диска читати сектори та коригувати помилки внутрішніми механізмами ECC і ремапінгу. На відміну від ZFS scrub, він не перевіряє контрольну суму ваших даних. Він перевіряє власну здатність диска надійно отримувати сектори.

Що SMART добре виявляє

• Деградація поверхні медіа (pending sectors, reallocated sectors, uncorrectable errors).
• Нестабільність читання, яку диск ховає, поки вона не посилиться (зростання корекцій, повторні спроби, повільні читання).
• Термічні шаблони стресу, пов’язані з відмовами (історія температур, події over-temp).
• Помилки на рівні інтерфейсу (CRC-помилки часто вказують на проблеми з кабелем/backplane, а не медіа).

Чого SMART не вміє добре (особливо у 2025)

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

• Семантика атрибутів відрізняється між виробниками. Сире значення може бути «реальним» для одного диска і «вендорською арифметикою» для іншого.
• SMART «PASSED» — це хибне заспокоєння. Багато дисків вмирають, не піднімаючи загальний прапорець здоров’я.
• Long тести можуть не покривати всі LBA на деяких пристроях або можуть перериватися через енергозбереження.
• Поведіна SSD відрізняється: «погані сектора» стають питанням перекладу логічно-фізичної карти, і деякі відмови проявляються як раптова смерть, а не поступова деградація.

SMART long tests все одно варто запускати. Просто не використовуйте їх як картку «зникнення відповідальності», коли ZFS починає кричати.

Жарт #1: SMART «PASSED» — як менеджер, який каже «все виглядає нормально» за п’ять хвилин до зміни оргструктури.

Як результати SMART впливають на операційні рішення

SMART дає раннє попередження, але рішення не завжди «замінити негайно». Типові тригери:

• Будь-який ненульовий Offline_Uncorrectable або тренд зростання: плануйте заміну. Такий диск видає жорсткі помилки.
• Зростання Reallocated_Sector_Ct: замінити найближчим часом, особливо якщо супроводжується pending секторами.
• Current_Pending_Sector ненульовий: вважати терміновим; scrub/resilver ймовірно виявить їх і згенерує помилки читання.
• UDMA_CRC_Error_Count зростає: зазвичай спочатку замініть кабель/шлях backplane, а не диск.

Перетини, прогалини і чому потрібні обидва

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

Іноді все просто. Диск ламається, він викидає помилки читання, SMART показує pending сектори, а scrub повідомляє про помилки читання або checksum. Чудово. Ви замінюєте диск і рухаєтеся далі.

Прогалина #1: SMART чистий, ZFS повідомляє checksum errors

Це поширено і лякає людей. Але не повинно. Контрольні суми — end-to-end: вони можуть виявляти корупцію від RAM, контролерів, HBA, кабелів, сплітерів, backplane, прошивок та космічних причин. SMART знає лише те, що бачить диск всередині.

Якщо ZFS каже «checksum error», не припускайте автоматично, що диск «бреше». Припускайте, що шлях винен, поки не доведено протилежне. Проблеми з кабелями часто проявляються як CRC-помилки в SMART (особливо SATA), але не завжди встигнуть.

Прогалина #2: SMART виглядає погано, ZFS мовчить

Це сценарій «латентної відмови». Диск деградує в областях, які ZFS не читав останнім часом (холодні дані, рідко використовувані набори, нерозподілені блоки). ZFS мовчить, бо ніхто не просив ці сектори. Scrub, ймовірно, виявить це — якщо scrub пройде до того, як resilver змусить читання всього стрипу під навантаженням.

Прогалина #3: scrubs проходять, але ви все одно втрачаєте дані

Scrub перевіряє те, що існує і читається. Він не гарантує:

• Що ваші резервні копії валідні.
• Що ваші компоненти не вийдуть з ладу катастрофічно завтра.
• Що у вас є надмірність, яка відповідає вашому домену відмов (ті ж партії дисків, той самий backplane, та сама помилка прошивки).

Scrub зменшує ризик. Він не скасовує фізику.

Моє суб’єктивне правило

Якщо ви використовуєте ZFS у продакшені і не плануєте scrubs та SMART long tests, ви не «економите знос». Ви відкладаєте незнання на потім, з відсотками.

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

• ZFS поставлявся з end-to-end перевіркою контрольних сум з першого дня (ера Solaris), спеціально щоб вирішити проблему тихої корупції, яку традиційні файлові системи не могли виявити.
• Термін «scrub» став популярним у сховищах через RAID scrubbing: періодичні читання, щоб знайти латентні помилки секторів до часу відновлення, коли сюрпризи найменш бажані.
• SMART існує з 1990-х, з ранніми вендорськими реалізаціями до того, як ATA стандартизував базовий набір поведінок.
• Загальний прапорець «SMART overall-health PASSED» відомо консервативний; багато відмов відбуваються без його спрацьовування, тому SRE слідкують за атрибутами та трендами.
• ATA та SCSI/SAS звітування про стан розійшлися: SAS використовує log pages і механізми self-test, які схожі, але не тотожні ATA SMART атрибутам.
• Сучасні диски можуть невидимо повторювати спроби читання, перетворюючи «поганий сектор» на «повільний сектор», що спочатку проявляється як сплески латентності, а не миттєві помилки.
• ZFS scrub читає лише виділені блоки, тож майже-порожній пул може приховувати проблемні області, поки дані не виростуть або не перемістяться.
• Контролери SSD постійно ремаплять; «сектори» тут логічні, і відмови можуть бути раптовими (прошивка, корупція FTL метаданих), а не поступовим зношуванням.
• Поводження RAIDZ під час resilver історично вимагало більше читань, ніж зеркалювання; новіші можливості ZFS, як послідовне resilvering, допомагають, але відновлення все ще навантажує флот дисків.

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

Це послідовність «припиніть сперечатися в чаті і знайдіть вузьке місце». Використовуйте її, коли бачите checksum errors, помилки читання, повільний IO або scrub, що йде вічно.

Перше: чи пул наразі безпечний?

• Перевірте zpool status -v: чи є vdev-и деградовані, пристрої faulted, невідновні помилки?
• Якщо надмірність скомпрометована (деградований mirror, RAIDZ з мертвим диском), пріоритет — відновлення надмірності над оптимізацією продуктивності.

Друге: це диск, шлях чи хост?

• Диск: SMART показує збільшення pending/uncorrectable/reallocated; ZFS повідомляє помилки читання на тому пристрої.
• Шлях: SMART показує CRC-помилки; ZFS показує checksum errors на кількох дисках за тим самим HBA/backplane; dmesg показує скидання лінку/таймаути.
• Хост: помилки пам’яті, події ECC, попередження ядра або недавні оновлення драйверів/прошивки.

Третє: чи ви зараз обмежені по IO або по латентності?

• Використовуйте zpool iostat -v 1, щоб побачити, який vdev насичений.
• Використовуйте iostat -x, щоб знайти окремий пристрій з високим await/util.
• Під час scrub: очікуйте інтенсивних читань; якщо система падає, обмежте або перенесіть scrub.

Четверте: рішення — ремонтувати, замінювати чи перепрокласти

• Якщо це медіа: замініть диск, потім scrub після resilver.
• Якщо це шлях: спочатку виправте кабелі/backplane/HBA, потім scrub, щоб підтвердити, що лічильники помилок перестали зростати.
• Якщо це хост: перевірте RAM (логи ECC), перегляньте останні зміни та розгляньте ізоляцію вузла.

Жарт #2: Найшвидший спосіб «вирішити» checksum errors — перестати перевіряти; так ви також станете попереджувальною історією.

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

Всі приклади припускають Linux-хост з встановленими ZFS та smartmontools. Замініть імена пристроїв і пулів на свої. Головне — робочий процес: спостерігати → інтерпретувати → вирішувати.

Завдання 1: Перевірити статус scrub і чи помилки ще накопичуються

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.
action: Determine if the device needs to be replaced, and clear the errors
  see: zpool(8)
  scan: scrub repaired 128K in 02:13:44 with 0 errors on Tue Dec 24 03:11:09 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            ata-WDC_WD140EDFZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDFZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDFZ-...   ONLINE       2     0     0
            ata-WDC_WD140EDFZ-...   ONLINE       0     0     0

errors: No known data errors

Що це означає: scrub відремонтував дані, і один диск має помилки читання (READ=2). ZFS виправив це за рахунок паритету, тому відомих помилок даних немає. Це попереджувальний постріл.

Рішення: витягніть SMART для проблемного диска, перевірте кабелі/логі HBA і плануйте заміну, якщо SMART показує pending/uncorrectable або якщо помилки читання повторюються.

Завдання 2: Дізнатися, чи checksum помилки локалізовані чи розкидані по пристроях

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Wed Dec 25 01:00:03 2025
        2.11T scanned at 1.02G/s, 1.44T issued at 711M/s, 18.2T total
        0B repaired, 0.00% done, 06:59:12 to go
config:

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

Що це означає: CKSUM помилки на одній стороні mirror. Це вказує на цей пристрій або його шлях (кабель/backplane/HBA) більше, ніж на загальний корупційний стан пулу.

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

Завдання 3: Очищати ZFS помилки тільки після виправлення причини

cr0x@server:~$ zpool clear tank

Що це означає: лічильники скидаються. Це не виправлення; це спосіб підтвердити, що проблема повертається.

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

Завдання 4: Запустити scrub навмисно (і не робіть цього опівдні в день зарплати)

cr0x@server:~$ sudo zpool scrub tank

Що це означає: scrub поставлений у чергу/запущений. На навантажених пулах він конкуруватиме з робочими навантаженнями.

Рішення: якщо scrub викликає болісну латентність, налаштуйте розклад і розгляньте параметри zfs set (recordsize) окремо; не відключайте scrubs.

Завдання 5: Спостерігати прогрес scrub і ідентифікувати повільний vdev

cr0x@server:~$ zpool iostat -v tank 1
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        9.12T  8.97T    512     44   820M  23.1M
  raidz2-0                  9.12T  8.97T    512     44   820M  23.1M
    ata-WDC_WD140EDFZ-1     -      -        82      7   131M  5.8M
    ata-WDC_WD140EDFZ-2     -      -        85      6   138M  5.2M
    ata-WDC_WD140EDFZ-3     -      -        19      6    12M  5.4M
    ata-WDC_WD140EDFZ-4     -      -        86      6   139M  5.3M
--------------------------  -----  -----  -----  -----  -----  -----

Що це означає: один диск видає значно менше пропускної здатності на читання, ніж його побратими (WD140EDFZ-3). Це ймовірний вузький місце або той, що виконує багато повторних спроб.

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

Завдання 6: Запустити SMART long test на SATA-диску

cr0x@server:~$ sudo smartctl -t long /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.6.0] (local build)
=== 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 255 minutes for test to complete.
Test will complete after Wed Dec 25 06:14:02 2025

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

Рішення: плануйте long тести в непіковий час; на зайнятих масивах запускайте їх по черзі, щоб уникнути синхронних сплесків латентності.

Завдання 7: Прочитати результати self-test SMART і вирішити, чи замінювати негайно

cr0x@server:~$ sudo smartctl -a /dev/sda | sed -n '/Self-test execution status/,$p' | head -n 25
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever been run.
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       00%     18432         723451233
# 2  Extended offline    Completed without error       00%     18390         -

Що це означає: сталася помилка читання на певному LBA. Це не «стежити», це «цей диск не може надійно читати частину поверхні».

Рішення: замініть диск. Перед заміною можна примусово прогнати читання через ZFS (scrub), щоб побачити, чи надмірність перепише погані блоки, але не ставте на це весь продакшен.

Завдання 8: Перевірити ключові SMART атрибути (HDD) на сигнал латентної відмови

cr0x@server:~$ sudo smartctl -A /dev/sda | egrep 'Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|UDMA_CRC_Error_Count'
  5 Reallocated_Sector_Ct   0x0033   188   188   140    Pre-fail  Always       -       24
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       3
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       3
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Що це означає: є pending і uncorrectable сектори. Reallocated вже відбулися. CRC чистий, отже, ймовірно, це медіа, а не кабелі.

Рішення: замініть диск і запустіть scrub після resilver, щоб переконатися, що помилки не залишилися.

Завдання 9: Виявити проблему з кабелем/backplane через CRC-помилки

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

Що це означає: CRC-помилки — транспортного рівня. Дані були пошкоджені або відбувалися повторні спроби між диском і контролером. Диски часто залишаються «здоровими», поки лінк нестабільний.

Рішення: переставте/замініть кабель, огляньте коннектори backplane, поміняйте порт на HBA. Не замінюйте диск першим, якщо вам не подобається витрачати час даремно.

Завдання 10: Зкорелювати помилки пристрою ZFS з фізичними пристроями

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep WDC_WD140EDFZ | head
lrwxrwxrwx 1 root root  9 Dec 26 00:41 ata-WDC_WD140EDFZ-11A0VA0_V9J0ABCD -> ../../sdc
lrwxrwxrwx 1 root root  9 Dec 26 00:41 ata-WDC_WD140EDFZ-11A0VA0_V9J0EFGH -> ../../sdd

Що це означає: ви зіставляєте імена, які ZFS виводить, з пристроями ядра. Це важливо при заміні дисків; /dev/sdX нестабільний.

Рішення: завжди використовуйте /dev/disk/by-id у vdev-ах ZFS і в процедурі заміни.

Завдання 11: Перевірити логи ядра на скидання лінку і таймаути (проблеми шляху)

cr0x@server:~$ sudo dmesg -T | egrep -i 'ata[0-9]+|link is slow|hard resetting link|I/O error|blk_update_request' | tail -n 12
[Wed Dec 25 02:14:11 2025] ata7: hard resetting link
[Wed Dec 25 02:14:12 2025] ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Wed Dec 25 02:14:14 2025] blk_update_request: I/O error, dev sdc, sector 723451233 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[Wed Dec 25 02:14:14 2025] ata7.00: failed command: READ FPDMA QUEUED

Що це означає: скидання лінку + помилки читання. Може бути мертвий диск, може бути нестабільне підключення. Поєднайте з SMART CRC і pending секторами для рішення.

Рішення: якщо CRC зростає — вважайте шлях проблемним; якщо pending/uncorrectable зростає — вважайте медіа проблемним. Якщо обидва зростають — замініть і диск, і кабель/backplane, бо ви в зоні веселощів.

Завдання 12: Визначити, чи має ZFS постійні помилки даних (найстрашніший сценарій)

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.
action: Restore the file in question if possible.
  scan: scrub completed after 07:44:02 with 0 errors on Thu Dec 26 04:12:09 2025
config:

        NAME                      STATE     READ WRITE CKSUM
        tank                      ONLINE       0     0     0
          raidz1-0                ONLINE       0     0     0
            ata-ST8000DM-1        ONLINE       0     0     0
            ata-ST8000DM-2        ONLINE       0     0     0
            ata-ST8000DM-3        ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        tank/data/db/pg_wal/000000010000000A000000FE

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

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

Завдання 13: Побачити, які datasets забирають найбільше часу на scrub (непрямий метод)

cr0x@server:~$ sudo zfs list -o name,used,logicalused,recordsize,compression -S used | head -n 10
NAME                 USED  LUSED  RECSIZE  COMPRESS
tank/data            6.12T  6.70T  128K     lz4
tank/backups         2.44T  2.80T  1M       lz4
tank/vm              1.91T  2.10T  16K      lz4
tank/home            312G   330G   128K     lz4

Що це означає: найбільш використовувані datasets домінують у IO scrub. Малий recordsize (наприклад 16K для VM) може збільшити метадані і накладні IO.

Рішення: не «оптимізуйте» recordsize під час інциденту. Але зафіксуйте, які datasets можуть виправдати окремі пули або інші макети, якщо scrubs постійно болючі.

Завдання 14: Запустити SMART long test на NVMe (self-test/log відрізняється)

cr0x@server:~$ sudo smartctl -a /dev/nvme0
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.6.0] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       Samsung SSD 990 PRO 2TB
Serial Number:                      S7HBNX0T123456A
Firmware Version:                   5B2QJXD7
SMART overall-health self-assessment test result: PASSED
Critical Warning:                   0x00
Temperature:                        41 Celsius
Available Spare:                    100%
Percentage Used:                    2%
Data Units Read:                    12,384,921
Data Units Written:                 9,221,114
Media and Data Integrity Errors:     0
Error Information Log Entries:       0

Що це означає: здоров’я NVMe відрізняється: percentage used, media errors, critical warnings. Історії з pending секторами тут немає; відмови часто проявляються через media errors або раптові проблеми контролера.

Рішення: відстежуйте media/data integrity errors і entries журналу помилок NVMe з часом; замінюйте при зростаючому тренді, а не тільки коли «critical warning» спрацьовує.

Три короткі історії з корпоративного життя

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

У них була акуратна політика: «Якщо SMART каже PASSED, диск в порядку». Це було в вики, повторювалося при хендоверах і використовувалося як швидке закриття тікетів. Пул був ZFS mirror на SATA SSD у 2U шасі, що обслуговували внутрішні сервіси, які ніколи не вважали критичними — поки не стали.

Одного тижня ZFS почав повідомляти checksum errors на одній нозі mirror. Не помилки читання. Не помилки запису. Просто інкременти checksum під час нормальної роботи. SMART виглядав чистим. Команда чистила лічильники, запускала scrub, бачила «repaired 0B» і рухалася далі. Лічильник контрольної суми повільно зростав. Та сама схема: clear, shrug, defer.

Потім оновили прошивку HBA. Під навантаженням коробка почала логувати скидання лінку. Раптом нога mirror з checksum errors стала недоступною під піковим трафіком. Інша сторона тягла навантаження, але пул тепер був на крок від справжньої катастрофи.

Postmortem був прямим: неправильне припущення не в тому, що SMART корисний. Неправильне припущення — що SMART є правильним інструментом для валідації коректності даних. checksum errors були проблемою шляху — ймовірно маргінальні кабелі/backplane, що проявлялися лише під певним IO-патерном. SMART не бачив цього, бо сам диск не був ушкоджений. ZFS бачив це, бо дані, що приходили, не відповідали контрольній сумі. Виправлення було нудним: заміна кабелів, переоснащення конекторів backplane і перестати чистити лічильники, поки причина не з’ясована. Після цього checksum errors зупинилися.

Урок: SMART PASSED не переважає ZFS checksums. Коли вони не згодні — досліджуйте шину.

Міні-історія 2: Оптимізація, що відрізала

Інша компанія тримала великі ZFS RAIDZ2 пули для бекапів та об’єктного зберігання. Scrubs були налаштовані щомісяця, бо «це холодні дані», а SMART long tests були вимкнені, бо «вони гальмують I/O». Хтось вирішив «оптимізувати»: scrubs запускати раз на квартал, бо пули великі і scrubs дратують зацікавлені сторони.

Деякий час нічого не відбувалося. Це пастка. Латентні секторні помилки не посилають запрошення в календар. Потім один диск впав і почався resilver. Під час resilver інший диск почав кидати помилки читання в регіоні, який не чіпався місяцями. Пул пересувався крок за кроком, але resilver підірвався, бо диск робив повторні спроби читання. Зрештою ZFS виявив невідновні помилки в трьох бекап-об’єктах.

Це були «лише бекапи», поки ними не довелося користуватися. Коли зробили продакшен-відновлення пізніше, частина старих recovery point-ів виявилася пошкодженою. Команда додатку мусила обирати між відновленням за новішим snapshot (більша втрата даних) або ручним відновленням стану (більше болю). Вони зробили обидва, погано.

Оптимізація базувалася на непорозумінні: scrubs — не опціональне «обслуговування». Це спосіб ZFS перетворювати невідомі латентні відмови на відомі та виправлені блоки, доки надмірність ще існує і пул стабільний. Resilver — найгірший час для виявлення непрочитаних секторів.

Вони повернулися до щомісячних scrubs і рознесли SMART long tests по тижнях між пристроями. Scrubs все ще дратували, але менше, ніж втрата даних дратувала керівництво. Ось так пріоритети стали яснішими.

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

Команда, яка управляла мульти-тенантним віртуалізованим кластером, мала просту, нудну рутину: щотижневі SMART long tests, рознесені по хостах; щомісячні ZFS scrubs, рознесені по пулам; і дашборд, що відстежував дельти трьох SMART атрибутів: pending sectors, offline uncorrectable і CRC errors. Жодного машинного навчання. Просто тренди.

Одного понеділка дашборд показав невелике, але реальне зростання UDMA_CRC_Error_Count на двох дисках за тим самим backplane. Диски мали нуль pending і нуль reallocated. ZFS був чистий. Продуктивність — нормальна. Ніхто не пейджив. Це момент, коли команди або ігнорують, або виглядають параноїками.

Вони запланували коротке вікно технічного обслуговування, переосадили конектор backplane і замінили два SATA кабелі. CRC перестали інкрементуватися. Жодних інцидентів. Жодного простою поза вікном. Про це всі забули — що і є правильним результатом профілактики.

Три тижні потому інший хост у тому ж ряду показав схожу CRC-патерну. Знову поміняли кабелі і виявили серійну проблему з певною моделлю кабелів. Проактивно замінили їх по всьому флоту під час планових вікон. Жодних інцидентів.

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

Типові помилки (симптом → корінна причина → виправлення)

1) Симптом: зростають ZFS checksum errors, але SMART чистий

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

Виправлення: перевірте CRC-лічильники SMART, dmesg на предмет скидань лінку, переосадіть/замініть кабелі, переведіть диск на інший порт, розгляньте відкат прошивки/драйвера HBA.

2) Симптом: scrub «відремонтував» дані, і ви вважаєте це вирішеним

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

Виправлення: ідентифікуйте пристрій, що логував помилки читання/checksum; запустіть SMART long test; замініть підозрілий диск, якщо атрибути ненульові або помилки повторюються.

3) Симптом: scrubs займають вічність і вбивають латентність

Корінна причина: scrubs у піковий час; один повільний диск, що уповільнює RAIDZ vdev; SMR HDD в балансі; або диски роблять багато внутрішніх повторних спроб.

Виправлення: плануйте scrubs у непіковий час; розносіть їх по пулам; виявляйте повільні диски з zpool iostat -v; замініть відстаючого; уникайте SMR там, де потрібні стабільні читання під навантаженням.

4) Симптом: SMART показує pending сектори, але ZFS scrub чистий

Корінна причина: проблемні сектори у частинах, які ZFS не читав недавно (або взагалі).

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

5) Симптом: «Permanent errors» у zpool status

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

Виправлення: відновіть постраждалі файли з резервної копії/реплікації; підвищте дизайн надмірності (mirror/RAIDZ2/3) і перевірте цілісність пам’яті (ECC) та прошивку контролера.

6) Симптом: SMART long test неодноразово падає або переривається

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

Виправлення: запускайте SMART через правильний тип пристрою (-d sat, -d megaraid,N тощо); перевірте dmesg; замініть диск при реальних помилках читання.

7) Симптом: ви замінили «поганий» диск, але помилки продовжуються на новому

Корінна причина: проблема була в шляху (кабель/backplane/HBA), а не в диску.

Виправлення: дослідіть CRC-помилки і скидання лінку; поміняйте порт/HBA; перевірте живлення; не жертвуйте дисками богам кабелів.

8) Симптом: resilver зазнає помилок читання з виживших дисків

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

Виправлення: збільште частоту scrubs; раніше замінюйте сумнівні диски за трендами SMART; розгляньте вищу надмірність і менше ширини vdev для зниження ризику під час відновлення.

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

Базова політика (продакшен ZFS)

1. Увімкніть заплановані ZFS scrubs для кожного пулу (щомісяця — хороший дефолт; частіше для «гарячих» даних або великих HDD-пулів).
2. Заплануйте SMART long tests з рознесенням по дисках (щотижня або раз на два тижні; щоденні короткі тести для швидкого сигналу).
3. Налаштуйте алерти на ZFS помилки: будь-який ненульовий READ/WRITE/CKSUM на пристрій і будь-які «repaired» байти.
4. Алертуйте за трендами SMART: pending sectors, offline uncorrectable, зростання reallocated, зростання CRC, NVMe media/data integrity errors.
5. Документуйте процедуру заміни з використанням /dev/disk/by-id та включіть крок перевірки scrub/resilver після заміни.

Коли ZFS повідомляє checksum errors

1. Запустіть zpool status -v, ідентифікуйте пристрій(и) і чи деградована надмірність.
2. Перевірте dmesg на скидання лінку/таймаути у відповідний час.
3. Перевірте SMART атрибути, особливо CRC, pending, uncorrectable і reallocated.
4. Якщо CRC зростає: спочатку ремонтуйте кабелі/backplane/HBA.
5. Якщо pending/uncorrectable зростає: замініть диск.
6. Після виправлення: zpool clear, потім scrub, потім підтвердьте, що лічильники залишаються нульовими.

Коли SMART long test падає, але ZFS мовчить

1. Підтвердіть помилку в логах self-test SMART і в атрибутах.
2. Запустіть ZFS scrub, щоб примусово прочитати виділені дані; стежте за помилками читання/checksum.
3. Замініть диск навіть якщо ZFS ще не поскаржилась, якщо long test показав помилки читання або uncorrectable.
4. Після заміни/resilver: scrub знову, щоб підтвердити здоров’я пулу.

Поради по розкладу, щоб вас не ненавиділи

• Розносьте все: не запускайте всі scrubs о 01:00 в неділю і SMART long tests о 01:05. Ви створите власний інцидент.
• Надавайте перевагу «передбачуваній повільності» перед «випадковою повільністю»: запланований scrub дратує; незапланований resilver може зруйнувати кар’єру.
• Відстежуйте тенденцію тривалості: якщо час scrub подвоюється місяць у місяць, щось змінилося (ємність, навантаження, повільний диск або регресія прошивки).

FAQ

1) Якщо я регулярно запускаю ZFS scrubs, чи потрібні ще SMART long tests?

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

2) Якщо SMART long tests чисті, чи можу я ігнорувати ZFS checksum errors?

Ні. Контрольні суми — end-to-end. SMART може бути чистим, поки контролер, кабель, backplane або драйвер корумпують або роблять повторні спроби IO.

3) Чи «зношують» scrubs SSD?

Scrubs — здебільшого читання; читання мають мінімальний вплив на знос у порівнянні з записами. Більший ризик — вплив на продуктивність, а не на довговічність. Плануйте правильно.

4) Чому scrub відремонтував дані, але SMART не показує reallocated sectors?

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

5) Як часто мені робити scrub?

Щомісяця — добрий дефолт для HDD-пулів. Для дуже великих пулів або для критичних даних варто розглянути кожні 2–4 тижні. Якщо scrubs болючі — змініть архітектуру, а не календар.

6) Як часто запускати SMART long tests?

Щотижня або раз на два тижні — розумний графік при рознесенні дисків. Для ноутбуків або систем з низьким навантаженням — раз на місяць підійде. Для масивів — автоматизуйте і тримайте регулярність.

7) У чому різниця між READ помилками і CKSUM помилками в zpool status?

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

8) Чи варто замінювати диск з кількома reallocated sectors?

Одноразові ремапи, що стабілізувалися, можуть бути прийнятними, але в продакшені я заміняю за трендом: якщо лічильник зростає або з’являються pending/uncorrectable.

9) Чи можуть scrubs виявити корупцію в RAM або CPU?

Опосередковано. Якщо погана пам’ять корумпує дані під час передачі або запису, ZFS може пізніше виявити невідповідності. ECC пам’ять значно зменшує цей ризик; без ECC ви ризикуєте.

10) Якщо пул RAIDZ1 і я бачу repaired bytes — що робити?

Ставтеся серйозно. RAIDZ1 має менше запасу на випадок багатосекторних або мультидискових проблем під час rebuild. Розгляньте підвищення надмірності, якщо дані важливі.

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

Припиніть розглядати ZFS scrub і SMART long test як конкуренти. Це доповнювальні сенсори, спрямовані на різні частини системи: один валідує ваші дані, інший перевіряє пристрій.

1. Заплануйте щомісячні scrubs для кожного пулу і рознесіть їх по флоту.
2. Заплануйте SMART long tests щотижня/раз на два тижні, рознесіть по дисках, і алертуйте за атрибутами, що насправді прогнозують проблеми (pending, uncorrectable, reallocations, CRC).
3. Коли ZFS повідомляє checksum errors, спочатку досліджуйте шлях — кабелі, backplane, HBA, прошивку — потім диск.
4. Коли SMART повідомляє pending/uncorrectable, не чекайте, поки resilver це виявить. Замініть диск на своїх умовах.
5. Після будь-якого ремонту, очистіть лічильники, запустіть scrub і підтвердьте, що помилки зупинилися. Докази перемагають оптимізм.

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