Помилки читання ZFS: коли винен диск, кабель або контролер

Ментальна модель: що ZFS може довести, а що лише припускати

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

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

Тож сприймайте помилки ZFS як докази на місці події:

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

Оперативно ви хочете швидко відповісти на три питання:

1. Чи під загрозою цілісність даних зараз (більше, ніж може витримати ваша надлишковість)?
2. Чи локалізовано помилку (один диск) чи це системна проблема (шлях/контролер/бекплейн/живлення)?
3. Яка найбезпечніша дія, що негайно підвищує шанси на відновлення?

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

READ проти CHECKSUM проти WRITE: на що вказує кожна помилка

READ помилки: пристрій не віддав запитані дані

READ помилка у zpool status — це повідомлення ZFS, що «я попросив блоковий пристрій віддати байти і отримав помилку».
Така помилка може бути від диска (помилка носія, внутрішній ресет), від ланцюга (CRC-помилки, що призводять до скасування команд),
від контролера/драйвера (таймаути, ресети) або від подій живлення. Це не так специфічно, як хотілося б.

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

CHECKSUM помилки: дані прийшли, але були хибні

CHECKSUM помилки — це візитна картка ZFS. Пристрій повернув дані успішно, але контрольна сума не співпала.
Якщо є надлишковість, ZFS спробує інші репліки/парність і виправить пошкоджену копію. Якщо ж ні — «успішне читання» фактично передало вам корупцію.

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

WRITE помилки: пристрій відмовився прийняти дані

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

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

Жарт №1: RAID — це не бекап, і «в нас ніколи не було проблем» — теж не бекап. Це просто бажання в обгортці Excel.

Цікаві факти та історичний контекст (що пояснює сучасні дивні випадки)

• ZFS створили в Sun, щоб покінчити з прихованою корупцією даних. Дизайн з контрольною сумою на кожному блоці був прямою відповіддю на стекі збереження, який «довіряв диску».
• Ранні SATA мали репутацію «просто працює», поки не перестали. Споживчі SATA кабелі і конектори не були призначені для щільних шасі з вібрацією.
• SAS розробляли для топологій з експандерами/бекплейнами. Ось чому лічильники помилок SAS і звіти посилань можуть бути детальнішими — якщо ваше ПО їх показує.
• Кеш контролерів RAID колись ховав проблеми дисків. Кеш із батарейною підпорою міг маскувати латентність і навіть змінювати симптоми відмов, що робило розбір інцидентів цікавим у найгіршому сенсі.
• HBAs в IT-режимі стали нормою для ZFS, бо ZFS хоче правди. ZFS очікує прямої семантики пристрою; прошивка RAID, яка приховує помилки, може саботувати діагностику.
• ATA звітування помилок непослідовне між вендорами. SMART корисний, але вендори по-різному реалізовують атрибути і іноді оптимістично.
• UDMA CRC помилки зазвичай — це помилки шляху, а не носія. Якщо цей лічильник росте, спочатку підозрюйте кабелі, бекплейн або електричний шум.
• Внутрішні повторні спроби диска можуть виглядати як «випадкова латентність» перед тим, як стати явними помилками. Коли ви бачите жорсткі помилки, диск міг боротися тижнями.
• Scrub у ZFS створили, щоб виявляти латентні помилки секторів. Мета — знайти погані сектори, поки є надлишковість, а не під час ресилверу, коли залишилося небагато.

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

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

Перше: встановіть радіус ураження та поточний ризик

1. Запустіть zpool status -xv. Шукаєте, які vdev деградувалися, чи зростають помилки і чи ZFS щось відновлював.
2. Перевірте, чи йде scrub/resilver і який ETA. Якщо ви вже деградувалися, ваша мета — уникнути додаткового навантаження або спровокувати ще відмови.
3. Визначте запас надлишковості. Mirror: можна втратити один диск. RAIDZ1: один диск загалом. RAIDZ2: два. Будьте жорстоко чесні.

Друге: скорелюйте з доказами на рівні ОС

1. Перегляньте dmesg / journald на предмет ресетів, таймаутів, помилок лінку. Якщо бачите «hard resetting link», «device offline» або «COMRESET failed», це ознака проблем шляху/контролера.
2. Отримайте SMART, особливо UDMA CRC і reallocated/pending сектора. Зростання CRC вказує на шлях; reallocated/pending — на диск.
3. Перевірте, чи кілька дисків на тому самому порту HBA або експандері показують симптоми. Спільна доля вказує на спільне обладнання.

Третє: дійте обережно і перевіряйте після кожної зміни

1. Якщо докази вказують на один диск: замініть його. Не «спостерігайте», якщо ви вже деградувалися і диск кидає помилки носія.
2. Якщо докази вказують на шлях: переукладіть/замініть найпростіший компонент спочатку. Почніть із кабелю, потім слот бекплейна, потім HBA — якщо логи не кричать інакше.
3. Після будь-якої апаратної зміни: очистіть помилки, зробіть scrub і стежте за лічильниками. «Виправлено» означає, що лічильники перестали зростати під навантаженням.

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

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

cr0x@server:~$ sudo zpool status -xv
  pool: tank
 state: DEGRADED
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:09 with 0 errors on Tue Dec 24 03:12:21 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz1-0                  DEGRADED     0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       3     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0

errors: No known data errors

Що це означає: Один диск накопичив READ помилки, але ZFS каже, що застосунки не постраждали і відомих помилок даних немає.
Це вказує, що ZFS мав надлишковість для відновлення.

Рішення: Ви ще не завершили роботу. Потрібно визначити, чи ці читання — проблема носія (media), чи проблема шляху (CRC/таймаути).
Не очищайте помилки поки що; вони — сліди.

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

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

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz1-0                  DEGRADED     0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       7     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0

Що це означає: Помилки зросли з 3 до 7. Щось досі не в порядку.

Рішення: Підвищуйте пріоритет. Негайно починайте кореляцію з логами ОС; плануйте обслуговування (заміна диска або виправлення шляху) сьогодні, а не «в наступному вікні».

Завдання 3: Зіставте пристрій ZFS з фізичним диском, який можна торкнутися

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep WDC_WD80 | head
lrwxrwxrwx 1 root root  9 Dec 25 02:10 ata-WDC_WD80...-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  9 Dec 25 02:10 ata-WDC_WD80...-part1 -> ../../sdc1
lrwxrwxrwx 1 root root  9 Dec 25 02:10 ata-WDC_WD80...-part1 -> ../../sdd1

Що це означає: Ви можете перевести ім’я by-id у /dev/sdX.
Не пропускайте цей крок: люди змінюють не той диск частіше, ніж визнають.

Рішення: Визначте підозрілий вузол пристрою (наприклад /dev/sdc) і використовуйте його послідовно для SMART та логів.

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

cr0x@server:~$ sudo dmesg -T | egrep -i 'sdc|ata[0-9]|reset|timeout|failed command|I/O error' | tail -n 20
[Wed Dec 25 01:44:02 2025] ata6.00: exception Emask 0x10 SAct 0x0 SErr 0x4050000 action 0xe frozen
[Wed Dec 25 01:44:02 2025] ata6.00: irq_stat 0x08000000, interface fatal error
[Wed Dec 25 01:44:02 2025] ata6: SError: { CommWake DevExch }
[Wed Dec 25 01:44:03 2025] ata6: hard resetting link
[Wed Dec 25 01:44:08 2025] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Wed Dec 25 01:44:08 2025] sd 5:0:0:0: [sdc] tag#15 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Wed Dec 25 01:44:08 2025] sd 5:0:0:0: [sdc] Sense Key : Medium Error [current]
[Wed Dec 25 01:44:08 2025] sd 5:0:0:0: [sdc] Add. Sense: Unrecovered read error

Що це означає: Ви маєте драму на рівні лінку (hard resetting link) і помилку носія (unrecovered read error).
Тут діагностика стає пікантною: поганий кабель може викликати ресети; поганий диск також може провокувати ресети.

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

Завдання 5: Перевірте зведення SMART і атрибути, що мають значення

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep -i 'SMART overall|Reallocated|Pending|Offline_Uncorrectable|UDMA_CRC|Power_On_Hours|Temperature' 
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       -       12
198 Offline_Uncorrectable   0x0010   200   200   000    Old_age   Offline      -       7
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   074   074   000    Old_age   Always       -       22816
194 Temperature_Celsius     0x0022   110   099   000    Old_age   Always       -       40

Що це означає: SMART «PASSED» — не виправдання. У вас 12 pending секторів і 7 offline uncorrectable.
Це не кабель; це диск, який не може прочитати частини носія.

Рішення: Замініть диск. Не витрачайте час на спочатку заміну кабелів, коли носій вже визнає поразку.

Завдання 6: Шукайте UDMA CRC помилки (класичний доказ проблем шляху)

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

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

Рішення: Переукладіть/замініть SATA/SAS кабель для відповідної корзини, перевірте роз’єми бекплейна і переконайтеся, що диск щільно вставлений.
Після змін перевіряйте, що лічильник CRC припинив зростання під навантаженням.

Завдання 7: Запустіть таргетований SMART self-test, щоб підтвердити підозру

cr0x@server:~$ sudo smartctl -t long /dev/sdc
Please wait 780 minutes for test to complete.
Test will complete after Wed Dec 25 15:10:22 2025

Що це означає: Довгий тест змушує диск пройти поверхню носія. Якщо він впаде — отримаєте конкретний доказ.

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

Завдання 8: Прочитайте результати SMART self-test (крок «покажи роботу»)

cr0x@server:~$ sudo smartctl -a /dev/sdc | sed -n '/SMART Self-test log/,$p' | head -n 20
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%     22820         3912456672
# 2  Short offline       Completed without error       00%     22816         -

Що це означає: «Completed: read failure» з LBA — курять-пістолет для проблеми носія.

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

Завдання 9: Визначте, чи помилки кластеризуються за контролером/експандером

cr0x@server:~$ lsscsi -t
[0:0:0:0]    disk    ata:WDC_WD80...  /dev/sdb  -  sata:ahci
[0:0:1:0]    disk    ata:WDC_WD80...  /dev/sdc  -  sata:ahci
[2:0:0:0]    disk    sas:SEAGATE...   /dev/sdd  -  sas:phy0
[2:0:1:0]    disk    sas:SEAGATE...   /dev/sde  -  sas:phy0

Що це означає: У вас пристрої за різними hosts/phys. Якщо всі диски з «sas:phy0» показують checksum помилки одночасно,
перестаньте звинувачувати «випадкові диски» і почніть звинувачувати спільну інфраструктуру.

Рішення: Групуйте помилки за хостом/портом. Якщо патерн співпадає з одним HBA/експандером — плануйте техобслуговування цього компонента.

Завдання 10: Перегляньте події HBA/драйвера (ресети — поганий знак)

cr0x@server:~$ sudo dmesg -T | egrep -i 'mpt2sas|mpt3sas|sas|reset|ioc|task abort' | tail -n 30
[Wed Dec 25 01:20:11 2025] mpt3sas_cm0: log_info(0x31120100): originator(PL), code(0x12), sub_code(0x0100)
[Wed Dec 25 01:20:12 2025] mpt3sas_cm0: sending diag reset !!
[Wed Dec 25 01:20:20 2025] mpt3sas_cm0: diag reset: SUCCESS
[Wed Dec 25 01:20:23 2025] sd 2:0:1:0: [sde] tag#91 FAILED Result: hostbyte=DID_RESET driverbyte=DRIVER_OK

Що це означає: Контролер зробив ресет, і диски зафіксували DID_RESET. ZFS може логувати read/checksum проблеми, бо I/O потік перервався.

Рішення: Розглядайте це як проблему контролера/прошивки/PCIe/живлення. Перевірте версії прошивок, помилки PCIe і тепловий режим.
Якщо ресети повторюються — плануйте заміну HBA замість «подивимось».

Завдання 11: Підтвердьте стан рівня PCIe (бо HBA сидять на PCIe, а не на атмосфері)

cr0x@server:~$ sudo journalctl -k | egrep -i 'pcie|aer|corrected|uncorrected|fatal' | tail -n 20
Dec 25 01:20:10 server kernel: pcieport 0000:3b:00.0: AER: Corrected error received: 0000:3b:00.0
Dec 25 01:20:10 server kernel: pcieport 0000:3b:00.0: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID)
Dec 25 01:20:10 server kernel: pcieport 0000:3b:00.0: AER:   device [8086:2030] error status/mask=00000040/00002000
Dec 25 01:20:10 server kernel: pcieport 0000:3b:00.0: AER:    [ 6] Bad TLP

Що це означає: PCIe AER «Bad TLP» — платформа визнає помилку на каналі передачі даних. Це може проявлятися як ресети HBA і помилки I/O.

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

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

cr0x@server:~$ sudo zpool clear tank
cr0x@server:~$ sudo zpool status -xv
all pools are healthy

Що це означає: Лічильники скинуті. Добре для видимості, погано — якщо ви зробили це до вирішення проблеми.

Рішення: Тепер застосуйте навантаження (звичне навантаження або scrub) і підтвердіть, що лічильники залишаються нульовими.
Якщо вони повертаються — ваше «виправлення» було театром.

Завдання 13: Запустіть scrub і інтерпретуйте результати

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Wed Dec 25 02:05:18 2025
        1.20T scanned at 1.45G/s, 220G issued at 270M/s, 8.00T total
        0B repaired, 2.75% done, 08:07:12 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz1-0                  ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0

Що це означає: Scrub чистий поки що і лічильники залишаються нульовими. Так виглядає «виправлено».

Рішення: Дайте scrub завершитися. Якщо він закінчиться з 0 помилок і лічильники стабільні під піковим навантаженням,
можна закривати інцидент з пристойною впевненістю.

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

cr0x@server:~$ sudo zpool offline tank ata-WDC_WD80...-part1
cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80...-part1 /dev/disk/by-id/ata-WDC_WD80_NEW_DISK-part1
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Wed Dec 25 02:12:44 2025
        620G scanned at 1.10G/s, 85.2G issued at 155M/s, 8.00T total
        85.2G resilvered, 1.04% done, 09:11:33 to go

Що це означає: Resilver триває. Деградація очікувана до завершення.

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

Завдання 15: Перевірте історію подій ZFS (корисно, коли лічильник вже скинули)

cr0x@server:~$ sudo zpool events -v | tail -n 25
Dec 25 2025 01:44:08.123456789 ereport.fs.zfs.io
        class = "ereport.fs.zfs.io"
        ena = 0x7f0b2c00000001
        detector = (embedded nvlist)
        (snip)
        vdev_path = "/dev/disk/by-id/ata-WDC_WD80...-part1"
        vdev_guid = 1234567890123456789
        io_error = 5

Що це означає: ZFS зафіксував I/O ereport-и, включно з тим, який vdev path був причетний. Добре для відтворення хронології подій.

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

Жарт №2: Якщо ваш «швидкий фікс» — перезавантажити сервер зберігання, це не діагностика — це ІТ-варіант гучнішого радіо.

Диск vs кабель vs контролер: патерн-матчинг, який працює

Коли це диск

Диски ламаються в передбачувані й бісову способи. Передбачувана частина: помилки носія проявляються як pending сектора,
uncorrectable, і провали SMART self-test-ів. Бісова частина: багато дисків «проходять» SMART до останнього моменту,
бо SMART — набір порогів, визначених вендором, а не гарантія.

Ознаки, що вказують на диск:

• Current_Pending_Sector або Offline_Uncorrectable ненульові і зростають.
• Логи ядра показують Medium Error, «Unrecovered read error» або подібне для того самого диска.
• SMART long test провалюється з read failure і LBA.
• Помилки ZFS залишаються локалізованими на одному листі vdev протягом часу і після ребутів.

Заміна диска — не моральний провал. Це робота. Єдина справжня помилка — вагатися, поки не вийде з ладу ще один компонент.

Коли це кабель або бекплейн

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

Ознаки, що вказують на кабель/бекплейн:

• UDMA_CRC_Error_Count зростає (особливо швидко), тоді як медіа-атрибути виглядають чистими.
• Логи ядра показують link resets, COMRESET failed, «SATA link down» або «device offlined» без явних medium errors.
• Помилки змінюють місце при переміщенні диска в інший слот або при заміні кабелю.
• Кілька дисків в одному ряді бекплейна/експандера мають помилки під час вібрацій/змін температури.

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

Коли це контролер (HBA, експандер, прошивка або PCIe)

Контролери ламаються по-особливому: вони ламаються системно і голосно в логах. Вони також ламаються так, що виглядає ніби диск зламався,
бо диск — кур’єр, якого підстрелили.

Ознаки, що вказують на контролер:

• Логи ядра показують mpt2sas/mpt3sas resets, task aborts, IOC ресети або повторювані bus resets.
• Помилки з’являються на кількох дисках за одним HBA/експандером, особливо в одному часовому вікні.
• PCIe AER помилки корелюють із перериваннями I/O.
• Зміни прошивки/драйвера змінюють патерн симптомів (іноді на краще, іноді на «цікаво нове»).

Суб’єктивна порада: якщо ви використовуєте ZFS, ваш HBA має бути в IT-режимі, на стабільній версії прошивки, яку можна відтворити,
і ви маєте знати, які диски відвішуються до яких портів. Якщо ні — ви працюєте в темряві.

Гарячий середній випадок: змішані сигнали і вторинні пошкодження

Реальні інциденти часто включають більше одного фактора:

• Непевний кабель викликає переривчасті ресети лінку.
• Ці ресети змушують диски частіше входити в recovery.
• Диск із слабкими секторами тепер має повторювані читання під стресом, і з’являються pending сектора.

Тому не зупиняйтесь на «це диск», якщо CRC помилки стрімко зростають, і не зупиняйтесь на «це кабель», якщо SMART показує uncorrectables.
Іноді правильна відповідь: замінити диск і кабель, а потім стежити за контролерними ресетами, що почали ланцюг.

Три міні-історії з корпоративного світу (анонімізовані, болісно правдоподібні)

1) Інцидент через хибне припущення

Середня компанія тримала NFS-ферму на ZFS для артефактів збірок. Нічого екзотичного: кілька RAIDZ2 пулів, пристойні диски,
і звичка ігнорувати попередження, поки вони не стали сторінками. Одного ранку розробники поскаржилися, що збірки не можуть отримати артефакти.
Хост зберігання показував read помилки на одному диску в vdev.

Інженер on-call зробив класичне припущення: «READ помилки означають, що диск поганий». Вони оффлайннули диск, пішли до стояка
і витягли диск з відсіку, який вважали відповідним для /dev/sde. Замінити — запустили zpool replace,
і спостерігали початок resilver. Це здавалося компетентним. Насправді — ні.

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

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

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

2) Оптимізація, що відбилася боком

Інша організація мала аналітичну платформу з великою кількістю збереження. Вони пишалися пропускною здатністю і завжди хотіли більше.
Хтось помітив, що scrubs «марнують I/O» у робочі години, тому зменшили частоту scrub і підлаштували ZFS, щоб фонова робота була менш агресивною.
Дашборди стали гарнішими. Деякий час.

Через місяці один диск відмовив під час звичайного пікового навантаження. Заміна була простою, але resilver йшов повільно.
Під час resilver другий диск отримав unrecoverable read error на секторі, який давно не читався.
ZFS не зміг відновити блок, бо залишня парність не покривала комбінацію відмов.

Неприємна правда: другий сектор був поганий уже давно. Регулярний scrub знайшов би його, поки була надлишковість,
і ZFS переписав би поганий сектор із доброї копії. Оптимізувавши scrubs, вони оптимізували відсутність раннього попередження і самовідновлення.

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

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

3) Нудна, але правильна практика, що врятувала день

SaaS-компанія працювала ZFS на флоті нод зберігання. Конфіг був навмисно простий: дзеркальні vdev для hot tier,
RAIDZ2 для cold tier, ECC RAM скрізь і жорстке правило стандартизації HBA і прошивок.
Правило дратувало людей, бо уповільнювало «швидкі апгрейди».

На одному вузлі почали з’являтися періодичні checksum помилки на кількох дисках у тій же шафі.
On-call слідував runbook: зняли zpool status, зібрали SMART, зібрали логи ядра,
перевірили, чи помилки корелюють з певним портом HBA. Вони не очищували лічильники. Не перезавантажували.
Вони ставилися до системи як до місця події.

Логи показали повторювані ресети контролера у ті ж таймстемпи, що і спалахи checksum.
SMART дисків був чистий — без pending секторів, без uncorrectable, CRC стабільний. Вони замінили SAS кабель і переключили підключення шафи
на запасний порт HBA. Помилки зникли миттєво, і scrub завершився чисто.

Справжнє «врятування» сталося через тиждень. Інший вузол показав схожі симптоми, але цього разу CRC лічильники швидко росли.
Оскільки у них були базові метрики CRC і ресетів, відхилення стало очевидним за кілька хвилин.
Вони поміняли кабель до того, як будь-який пул деградував.

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

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

1) «ZFS показує помилки; я їх очистив і тепер все добре.»

Симптом: Помилки з’являються знову через дні, інколи гірші.

Корінь проблеми: Очищення лічильників прибрало докази, не виправивши апаратну/шляхову проблему.

Виправлення: Зафіксуйте zpool status -xv, логи і SMART спочатку. Очищайте тільки після ремедіації, потім валідируйте scrub/навантаженням.

2) CHECKSUM помилки звинуватили диск, не перевіривши CRC

Симптом: Кілька дисків показують checksum помилки, часто у сплесках.

Корінь проблеми: Корупція даних у транзиті (кабель/бекплейн/HBA), а не дефект носія.

Виправлення: Перевірте UDMA_CRC_Error_Count, dmesg на предмет ресетів лінку і чи помилки групуються за HBA/експандером. Замініть/відремонтуйте спільний компонент.

3) Поставили рівність SMART «PASSED» = «здоровий»

Симптом: SMART каже PASSED, але читання продовжуються і є pending сектора.

Корінь проблеми: Зведене здоров’я SMART — порогове і часто занадто поблажливе.

Виправлення: Дивіться конкретні атрибути (pending, uncorrectable, reallocated, CRC). За можливості запускайте довгі self-test-и.

4) Замінити неправильний диск

Симптом: Після заміни помилки лишаються; інколи пул деградує більше.

Корінь проблеми: Мапування пристрій→відсік було вгадане, а не перевірене. Кабелювання змінилося; нумерація змінилася.

Виправлення: Використовуйте /dev/disk/by-id, серійні номери і інструменти мапування енклоужера. Маркуйте відсіки. Вимагайте перевірки другою особою в продакшені.

5) Використовувати RAIDZ1 там, де ризик перезбирання неприпустимий

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

Корінь проблеми: Однопаритетні vdev-и крихкі під час відновлення, особливо з великими дисками і латентними помилками секторів.

Виправлення: Віддавайте перевагу дзеркалам (швидкий resilver, прості зони відмов) або RAIDZ2/3 для великих vdev-ів. Проводьте scrubs регулярно.

6) Ігнорувати ресети контролера як «шум»

Симптом: Переривчасті I/O, кілька дисків коротко фолають, помилки приходять хвилями.

Корінь проблеми: Нестабільність прошивки/драйвера HBA, проблеми PCIe, перегрів або події живлення.

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

7) Перевантажувати пул під час resilver

Симптом: Resilver тягнеться вічно; з’являються нові помилки; другий диск падає.

Корінь проблеми: Сильний випадковий I/O + стрес під час відновлення виводить на межу маргінальні компоненти.

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

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

Чекліст для негайної локалізації (перші 30 хвилин)

1. Запустіть zpool status -xv. Збережіть вивід у тікет.
2. Підтвердіть запас надлишковості (mirror/рівень RAIDZ) і чи який-небудь vdev вже деградував.
3. Перевірте, чи лічильники помилок зростають (запустіть zpool status двічі з інтервалом у кілька хвилин).
4. Збережіть логи ОС за вікно інциденту: dmesg -T і journalctl -k.
5. Отримайте SMART з підозрілих дисків (хоча б тих, що мають помилки ZFS; бажано — усіх у vdev).
6. Якщо деградували: зменште неважливе навантаження і уникайте дій, що додають стрес (наприклад оновлення прошивки), якщо це не необхідно.

Чекліст для рішення: диск чи шлях

• Замініть диск негайно, якщо pending/offline uncorrectable сектори ненульові або SMART long test провалюється.
• Виправте шлях спочатку, якщо CRC помилки зростають, логи заповнені ресетами лінку, а SMART медіа-показники чисті.
• Підозрюйте контролер/платформу, якщо кілька дисків за одним HBA мають проблеми і бачите ресети контролера або PCIe AER події.
• Зробіть і те, і інше, якщо диск показує проблеми медіа і шлях має CRC/ресети. Мішані відмови трапляються.

План ремедіації (змінюйте по одній речі)

1. Визначте точний фізичний компонент (серійник диска, відсік, кабель, порт HBA).
2. Замініть/відремонтуйте найімовірніший компонент з найменшим радіусом ураження:
   • Переукладання/заміна кабелю
   • Переміщення диска в інший відсік (якщо енклоужер дозволяє і ви зможете зберегти коректне мапування)
   • Заміна диска
   • Заміна HBA або переміщення в інший слот PCIe
3. Очищайте помилки ZFS тільки після ремедіації.
4. Запустіть scrub. Моніторьте помилки під час scrub.
5. Документуйте мапування і що було замінено (майбутнє ви буде втомленим і вдячним).

Чекліст валідації (фаза «доведі це»)

1. Scrub завершується з 0 помилок.
2. zpool status не показує зростання READ/WRITE/CKSUM лічильників під піковим навантаженням.
3. SMART CRC лічильники припинили зростати після ремедіації кабелю/бекплейна.
4. У логах немає ресетів контролера або PCIe AER помилок принаймні за один повний робочий цикл.

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

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

Ні. READ помилки означають, що блоковий шар повернув помилку. Це може бути носій, але також ресети шляху, таймаути контролера або живлення.
Використовуйте SMART медіа-атрибути і логи ОС, щоб відокремити диск від шляху.

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

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

3) Якщо ZFS каже «errors: No known data errors», чи можна це ігнорувати?

Ні. Це повідомлення означає, що ZFS вважає, що виправив або уникнув видимої користувачу корупції. Воно не означає, що апаратне забезпечення здорове.
Сприймайте це як раннє попередження — найдешевше.

4) Чи треба негайно запускати zpool clear?

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

5) Скільки UDMA CRC помилок — «занадто багато»?

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

6) Чи можуть проблеми з ECC пам’яттю проявлятися як CHECKSUM помилки?

Так, але це менш поширено, ніж кабель/бекплейн/HBA проблеми у грамотно зібраних системах. ECC зазвичай коригує одно- і двобітні помилки і логгуватиме їх.
Якщо підозрюєте пам’ять — перевірте логи ядра на ECC-події і розгляньте тест пам’яті у вікні обслуговування.

7) Чи безпечний RAIDZ1 з великими дисками?

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

8) Чому помилки часто виявляються під час scrub або resilver?

Бо scrub і resilver змушують повністю читати поверхню диска. Вони торкаються холодних даних, які не читалися місяцями.
Саме тоді відкриваються латентні секторні помилки, слабкі кабелі і маргінальні контролери.

9) Якщо я заміню кабель, як підтвердити, що проблема вирішена?

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

10) Чи може бекплейн спричиняти checksum помилки без відключення дисків?

Так. Маргінальний бекплейн може корумпувати трафік або викликати переривчасті повторні спроби без повного відключення диска.
Це часто проявляється як checksum помилки, іноді ресети лінку і повільне підповзання CRC-лічильників.

Наступні кроки (що робити після зупинки кровотечі)

Коли пул стабільний і scrub чистий, не витрачайте біль. Перетворіть біль на покращення:

• Стандартизуйте мапування дисків. Маркування, використання by-id і документована мапа відсіків зменшать людські помилки більше, ніж будь-який інструмент.
• Базуйте метрики SMART і логів. CRC-лічильники, pending сектора, ресети контролера і PCIe AER мають бути в графіках або принаймні періодично переглядатись.
• Плануйте scrubs по графіку. Налаштуйте вплив, але не пропускайте. Scrub — це ваша вправа на цілісність, а не необов’язкове хобі.
• Підтримуйте прошивку в стабільному стані. Стабільні комбінації прошивок HBA/драйверів краще за «останню» у продакшені, якщо тільки вам не потрібне конкретне виправлення.
• Дизайн для відновлень. Дзеркала або RAIDZ2/3 плюс реалістичні вікна відновлення перетворюють відмови дисків на планове обслуговування, а не інциденти.
• Тренуйтеся у заміні. Пройдіть процедуру заміни диска в лабораторії. Найгірший час вивчати нюанси шасі — під час деградованого vdev.

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