Скидання SATA-з’єднання в ZFS: шаблон несправності контролера/кабеля

Як виглядає шаблон «контролер/кабель»

ZFS безжально відвертий щодо I/O. Він контролює контрольні суми, повторює операції, коли може, і позначить пристрій
як деградований або відмовлений, коли нижчий рівень системи не може надійно доставляти блоки. Скидання SATA-з’єднання живе під ZFS:
ядро каже «the link went away», потім «I reset it», потім «it came back», іноді повторюючи це, поки ZFS не відмовиться.

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

Польовий чекліст: ознаки, що це не диск

• Кілька дисків показують скидання лінку, але вони підключені до одного контролера/backplane/каналу живлення.
• SMART виглядає чистим (немає переназначених секторів, немає pending) але помічаються зростаючі UDMA CRC помилки.
• Помилки групуються навколо високого I/O, вібрації, коливань температури або коли кришку шасі хтось грюкнув.
• Заміна диска не допомагає. «Новий» диск поводиться так само на тому ж порті.
• Переміщення того самого диска на інший порт виправляє проблему. Це не магія — це ізоляція шляху.

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

Жарт №1: SATA — єдиний «швидкий послідовний шинний інтерфейс», який може зламатися через кабель, що виглядає цілком нормально. Це фактично мережа зі гвинтами.

Чому ZFS робить це помітнішим

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

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

1. UDMA CRC помилки були задумані як система раннього попередження. Вони часто вказують на проблеми кабелю/цілісності сигналу, а не на дефекти носія.
2. SATA успадкував культуру «ймовірно нормально» від десктопів. Професійні стояки вимагають жорсткіших допусків, ніж споживчі корпуси.
3. NCQ (Native Command Queuing) підвищив пропускну здатність, але збільшив зону ураження при збої лінку. Більше незавершених команд — більше таймаутів, коли шина гикає.
4. Backplane не є пасивною магією. Навіть «просто плата» може мати маргінальні сліди, зношені роз’єми або погане заземлення, що проявляється як CRC/повторювані спроби.
5. AHCI створювався для універсальності, а не для героїчних ситуацій. Багато вбудованих контролерів SATA поводяться гірше під навантаженням помилок у порівнянні з повноцінними HBA.
6. Готівкові (hot-swap) семантики на SATA складні. SAS проектувався для hot-plug; SATA має hot-plug, але реалізації дуже різні.
7. Функції управління живленням (HIPM/DIPM, ALPM) спричиняли реальні нестабільності. Агресивні зміни станів лінку можуть запускати скидання у маргінальних системах.
8. Звички кабелювання з раннього SATA 3Gb/s не завжди витримали 6Gb/s. «Працювало роками» може бути артефактом нижчої швидкості сигналу.
9. ZFS зробив помилки контрольних сум звично помітними в операціях. Традиційні стекі часто маскували тимчасову корупцію «повторюй, поки не вдасться»; ZFS каже вам правду.

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

Це план «мені потрібен напрямок за 10 хвилин». Не варто охоплювати все одразу. Визначте, чи маєте ви:
(a) один помираючий диск, (b) ненадійний лінк/шлях, або (c) контролер/backplane/живлення, що може вивести пул з ладу.

По-перше: підтвердьте, що ZFS думає

• Перевірте zpool status -v і зафіксуйте, які vdev(и) та пристрої показують помилки.
• Шукайте закономірності: ті ж порти HBA, той же шинний блок, той же backplane, той же канал живлення.

По-друге: читайте історію ядра, а не тільки зведення ZFS

• Витягніть dmesg -T та/або journalctl -k за час інциденту.
• Шукайте: link is slow to respond, hard resetting link, COMRESET failed, SError, failed command: READ FPDMA QUEUED.

По-третє: вирішіть «диск чи шлях» за допомогою SMART і лічильників

• smartctl -a для перевірки reallocated/pending/uncorrectable секторів (стан носія) та UDMA CRC помилок (стан лінку).
• Якщо CRC помилки зростають, а лічильники носія стабільні — сприймайте це як проблему кабелю/backplane/контролера, поки не доведено інше.

По-четверте: ізолюйте, змінивши одну змінну

• Перемістіть диск на інший порт/кабель/слот backplane (одна зміна за раз).
• Якщо проблема слідує за портом — це порт/шлях. Якщо слідує за диском — це диск.

По-п’яте: стабілізуйте й лише тоді scrub/resilver

• Виправте фізичну/шляхову проблему перш ніж запускати resilver. Резилвер через ненадійний лінк — це спосіб перетворити маленький інцидент у довгі вихідні.

Підписи в логах: диск vs лінія vs контролер

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

Класичне коло скидань лінку

Шукайте повторювані послідовності на кшталт: exception Emask → hard resetting link → SATA link up → повтор.
Коли це відбувається під навантаженням, ZFS бачить таймаути й I/O помилки; ваші додатки — піки затримки й «випадкові» збої.

CRC та транспортні помилки (кабель/backplane/шлях)

Індикатори включають підвищення UDMA_CRC_Error_Count, SError: { CommWake } і помилки, що зникають після скидання лінку.
Лічильники носія зазвичай залишаються стабільними. Диск каже: «Я можу зберігати біти; просто зараз я не в змозі нормально спілкуватися».

Таймаути команд з NCQ

Повідомлення на кшталт failed command: READ FPDMA QUEUED можуть вказувати або на проблему лінку, або на прошивку диска.
Ваш вирішальний фактор — повторюваність і кореляція: якщо кілька дисків показують те саме на одному контролері, звинувачуйте шлях.

Підпис помилки носія диска

Зазвичай це збільшення Reallocated_Sector_Ct, Current_Pending_Sector,
Offline_Uncorrectable і помилки контрольних сум ZFS, що концентруються на одному пристрої незалежно від порту.

Підпис помилки на рівні контролера

Коли винен HBA або вбудований контролер, часто бачите скидання кількох приєднаних дисків у вузькому проміжку часу.
ZFS може деградувати кілька vdev одночасно. Це не «невдалий збіг». Це спільна доля.

Одна операційна думка, яку часто перефразовують на честь Jim Gray: Несправності — нормальні; системи повинні припускати, що компоненти виходять з ладу і відновлюватися автоматично.
ZFS так і робить. Ваша SATA проводка — навряд чи.

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

Мета тут не в запам’ятовуванні команд. Мета — перетворити «диск випав» на структуроване рішення:
замінити диск, замінити кабель, замінити HBA, змінити живлення або підлаштувати налаштування ядра.
Кожне завдання нижче містить: команду, приклад виводу, що це означає й що робити далі.

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

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

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz2-0                  DEGRADED     0     0     0
            ata-WDC_WD80EFAX-68LHPN0  ONLINE      0     0     0
            ata-WDC_WD80EFAX-68LHPN0  ONLINE      0     0     0
            ata-ST8000VN004-2M2101   DEGRADED    12     0     0  too many errors
            ata-ST8000VN004-2M2101   ONLINE      0     0     0
errors: No known data errors

Що це означає: ZFS зафіксував помилки читання на одному пристрої (READ=12). Відсутність checksum-помилок означає, що читання зірвалося на рівні транспорту, а не «повернулося пошкоджене дане».

Рішення: Не поспішайте замінювати диск. Перейдіть до логів ядра та SMART. Помилки на транспортному шарі пахнуть скиданнями лінку.

Завдання 2: Зіставити імена пристроїв ZFS з фізичними шляхами

cr0x@server:~$ ls -l /dev/disk/by-id | grep ST8000VN004 | head
lrwxrwxrwx 1 root root  9 Dec 26 01:21 ata-ST8000VN004-2M2101_ZA1ABCDF -> ../../sdc
lrwxrwxrwx 1 root root 10 Dec 26 01:21 ata-ST8000VN004-2M2101_ZA1ABCDF-part1 -> ../../sdc1

Що це означає: Проблемний диск наразі — /dev/sdc.

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

Завдання 3: Витягти повідомлення ядра навколо події

cr0x@server:~$ sudo journalctl -k --since "2025-12-26 00:50" --until "2025-12-26 01:30" | egrep -i "ata[0-9]|reset|link|SError|I/O error" | tail -n 25
Dec 26 01:03:12 server kernel: ata7.00: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0x6 frozen
Dec 26 01:03:12 server kernel: ata7.00: irq_stat 0x08000000, interface fatal error
Dec 26 01:03:12 server kernel: ata7: SError: { RecovComm Persist PHYRdyChg CommWake DevExch }
Dec 26 01:03:13 server kernel: ata7: hard resetting link
Dec 26 01:03:18 server kernel: ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 26 01:03:18 server kernel: ata7.00: configured for UDMA/133
Dec 26 01:03:19 server kernel: sd 6:0:0:0: [sdc] tag#11 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Dec 26 01:03:19 server kernel: blk_update_request: I/O error, dev sdc, sector 912345678 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Dec 26 01:03:25 server kernel: ata7.00: failed command: READ FPDMA QUEUED
Dec 26 01:03:25 server kernel: ata7: hard resetting link

Що це означає: Це шторм скидань лінку. Ключові фрази: «interface fatal error», «hard resetting link» і SError прапори типу PHYRdyChg.

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

Завдання 4: Перевірити SMART на носійні vs транспортні індикатори

cr0x@server:~$ sudo smartctl -a /dev/sdc | egrep -i "Reallocated|Pending|Offline_Uncorrectable|UDMA_CRC|Power_On_Hours|Temperature"
  9 Power_On_Hours          0x0032   095   095   000    Old_age   Always       -       42110
194 Temperature_Celsius     0x0022   108   098   000    Old_age   Always       -       42
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   197   000    Old_age   Always       -       54

Що це означає: Pending/uncorrectable — нуль: носій виглядає добре. CRC помилки ненульові й часто зростають при маргінальному кабелю/backplane.

Рішення: Замініть кабель/слот backplane, переосадьте роз’єми, огляньте на гострі перегини та натяг. Відстежуйте, чи зростає лічильник CRC після змін.

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

cr0x@server:~$ sudo ls -l /sys/block/sdc/device | head -n 5
lrwxrwxrwx 1 root root 0 Dec 26 01:25 driver -> ../../../../bus/scsi/drivers/sd
lrwxrwxrwx 1 root root 0 Dec 26 01:25 scsi_device -> ../../../../bus/scsi/devices/6:0:0:0
lrwxrwxrwx 1 root root 0 Dec 26 01:25 subsystem -> ../../../../bus/scsi
lrwxrwxrwx 1 root root 0 Dec 26 01:25 target6:0:0 -> ../../../../bus/scsi/targets/6:0:0

Що це означає: Ми в зоні SCSI трансляції (нормально для SATA за libata). Далі зіставте з ata7 (з логів) та PCI-пристроєм.

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

Завдання 6: Знайти PCI-пристрій контролера SATA/AHCI

cr0x@server:~$ sudo lspci -nnk | egrep -A3 -i "sata|ahci"
00:17.0 SATA controller [0106]: Intel Corporation C620 Series Chipset Family SATA Controller [AHCI mode] [8086:a282]
        Subsystem: Supermicro Computer Inc Device [15d9:0888]
        Kernel driver in use: ahci
        Kernel modules: ahci

Що це означає: Вбудований Intel AHCI. Не обов’язково погано, але обробка помилок і ізоляція портів можуть бути гіршими у порівнянні з HBA в деяких комбінаціях шасі/backplane.

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

Завдання 7: Перевірити швидкість лінку та стан переговорів

cr0x@server:~$ sudo dmesg -T | egrep -i "ata7: SATA link|configured for UDMA" | tail -n 5
[Thu Dec 26 01:03:18 2025] ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Thu Dec 26 01:03:18 2025] ata7.00: configured for UDMA/133

Що це означає: Лінк узгоджується на 6.0 Gbps. Якщо ви бачите часті зниження швидкості (до 3.0 або 1.5), це великий натяк на проблеми сигналу.

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

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

cr0x@server:~$ sudo zpool status -v tank | sed -n '1,80p'
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible. Otherwise restore the entire pool from backup.
config:

        NAME                         STATE     READ WRITE CKSUM
        tank                         DEGRADED     0     0     0
          raidz2-0                   DEGRADED     0     0     0
            ata-WDC_WD80EFAX-...      ONLINE      0     0     0
            ata-WDC_WD80EFAX-...      ONLINE      0     0     0
            ata-ST8000VN004-...       DEGRADED    12     0     0  too many errors

Що це означає: Лише READ-помилки, без CKSUM. Якщо CKSUM почне рости, можливо, ви отримуєте пошкоджені дані (або невідповідні читання секторів), а не просто таймаути.

Рішення: Якщо помилки лише READ — фокусуйтеся на скиданнях лінку/таймаутах. Якщо CKSUM зростає — ризик цілісності даних; пришвидшіть реагування й розгляньте виведення пристрою з ладу, якщо він «отруює» читання.

Завдання 9: Очистити помилки після виправлення шляху (щоб побачити, чи повертаються)

cr0x@server:~$ sudo zpool clear tank ata-ST8000VN004-2M2101_ZA1ABCDF
cr0x@server:~$ sudo zpool status -v tank | egrep -A2 "ata-ST8000VN004|READ|WRITE|CKSUM"
            ata-ST8000VN004-2M2101_ZA1ABCDF  ONLINE       0     0     0

Що це означає: Лічильники скинуті. Тепер нові помилки — дійсно нові, а не старі.

Рішення: Моніторте. Якщо помилки повертаються швидко — ви не виправили корінну причину.

Завдання 10: Запустити цілеспрямований SMART self-test (після стабілізації)

cr0x@server:~$ sudo smartctl -t short /dev/sdc
Sending command: "Execute SMART Short self-test routine immediately in off-line mode".
Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 2 minutes for test to complete.
cr0x@server:~$ sudo smartctl -l selftest /dev/sdc | head -n 8
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%     42111         -

Що це означає: Внутрішня діагностика диска не виявила очевидних проблем з носієм.

Рішення: Підтверджує «проблему шляху». Якщо self-test виявить помилки читання — перегляньте питання диска.

Завдання 11: Scrub після усунення для підтвердження цілісності

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank | egrep -i "scan|scrub|errors"
  scan: scrub in progress since Thu Dec 26 02:10:01 2025
        1.23T scanned at 1.10G/s, 210G issued at 187M/s, 20.1T total
        0B repaired, 1.02% done, no estimated completion time
errors: No known data errors

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

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

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

cr0x@server:~$ sudo dmesg -wT | egrep -i "ata7|hard resetting link|I/O error|SError"
[Thu Dec 26 02:14:22 2025] ata7: hard resetting link
[Thu Dec 26 02:14:27 2025] ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

Що це означає: Проблема відбувається прямо зараз. Це добра новина: відтворювані баги піддаються виправленню.

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

Завдання 13: Перевірити, чи кілька дисків мають ті самі симптоми (підозра на контролер/backplane)

cr0x@server:~$ sudo journalctl -k -b | egrep -i "hard resetting link|COMRESET failed|SATA link down" | awk '{print $(NF-1),$NF}' | tail
link up
link
link up
link
link up

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

Рішення: Якщо кілька портів одночасно скидаються, припиніть звинувачувати окремі диски. Підозрюйте контролер, живлення, backplane, expander або EMI на рівні шасі.

Завдання 14: Перевірити, що ZFS бачить фізичні ID стабільно (щоб уникнути несподіваних перевидач)

cr0x@server:~$ sudo zpool status -P tank | sed -n '1,40p'
  pool: tank
 state: DEGRADED
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz2-0                  DEGRADED     0     0     0
            /dev/disk/by-id/ata-WDC_WD80EFAX-...  ONLINE  0 0 0
            /dev/disk/by-id/ata-ST8000VN004-...   DEGRADED 12 0 0

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

Рішення: Якщо ваш пул використовує сирі /dev/sdX імена, плануйте вікно техобслуговування для переходу на стабільні ідентифікатори (або хоча б забезпечте постійне іменування ОС).

Завдання 15: Правильно замінити пристрій, коли це дійсно диск

cr0x@server:~$ sudo zpool offline tank ata-ST8000VN004-2M2101_ZA1ABCDF
cr0x@server:~$ sudo zpool replace tank ata-ST8000VN004-2M2101_ZA1ABCDF /dev/disk/by-id/ata-ST8000VN004-2M2101_ZA9NEWID
cr0x@server:~$ sudo zpool status tank | egrep -i "resilver|scan|state"
 state: DEGRADED
  scan: resilver in progress since Thu Dec 26 03:01:10 2025

Що це означає: Правильний workflow заміни: offline → replace → моніторинг resilver.

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

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

Кореневі причини: звичні підозрювані детально

Кабелі: тихі лиходії

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

Що робити: Замініть на короткі, якісні кабелі; уникайте різких вигинів; переконайтеся, що роз’єми защіпаються; тримайте кабелі подалі від зон високої вібрації.
Якщо у вас є backplane, «кабель» включає роз’єм backplane і його цикли зчеплення. Переосадка — не забобон; це обслуговування.

Backplane: цілісність сигналу й зношені роз’єми

Backplane додає зручності та гарячої заміни, але також додає роз’єми, доріжки й іноді сумнівне заземлення.
Трохи окисований роз’єм може поводитися як генератор випадкових чисел при зміні температури.
Деякі backplane відмінні. Деякі «йдуть» до тих пір, поки ви не запустите їх на 6Gb/s з певними дисками та контролером.

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

Вбудовані AHCI контролери: підходять, поки ні

Багато систем роками працюють на вбудованих SATA. Проблема починається, коли щось іде не так.
Деякі контролери відновлюються від лінкових збоїв чисто; інші викликають шторми, блокують порти або скидають кілька лінків одразу.
Під ZFS таке поводження стає дорогою операційною проблемою: миттєвий збій перетворюється на vdev-помилки і деградацію пулу.

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

Живлення: категорія «це не живлення», яка часто виявляється живленням

Диски споживають значний струм при запуску і під час певних операцій. Маргінальні блоки живлення, перегружені розгалужувачі
або неплотно підключені конектори живлення можуть спричиняти короткочасні провали напруги. SATA скидання лінку — ввічливий симптом; неввічливий — зникнення диска.

Що робити: Усуньте розгалужувачі, використовуйте правильні харчування backplane, перевірте стан PSU і уникайте живлення занадто багатьох дисків від одного жгута.
Якщо скидання корелюють із запуском шпинделя або піковим I/O — поверніться до підозри на живлення.

Термініка й вібрація: середовище відповідає відсічкою

Зміни температури впливають на опір контактів і маржі сигналу. Вібрація впливає на посадку й якість контакту.
Шасі з високошвидкісними вентиляторами і купою натягнутих SATA-кабелів — фактично невеликий механічний стенд.

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

ALPM/HIPM/DIPM і «допоміжне» енергозбереження

Управління енергозбереженням лінку може спричиняти переходи, які маргінальне обладнання не витримує. Ви побачите дивні патерни: простою все нормально,
потім сплеск трафіку викликає скидання; або навпаки — активна робота ок, а простої спричиняють відключення.

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

Взаємодія прошивок: смерть через матрицю сумісності

Диски мають прошивкові особливості. Контролери мають свої. Backplane іноді має expander з прошивкою зі своїми нюансами.
Помістіть це все разом — і отримаєте поведінку, що виникає. Найдратівливіший баг — той, що зникає, коли ви змінюєте одну деталь.

Що робити: Стандартизируйте. Тримайте HBA в IT-режимі там, де це потрібно, підтримуйте консистентну прошивку і уникайте змішування занадто багатьох моделей дисків в одному шасі.
Коли знайдете стабільну комбінацію — документуйте її і не дозволяйте «ще одному іншому диску» зіпсувати рівновагу.

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

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

Середній SaaS запустив пару серверів з ZFS у дзеркальних vdev. Вони отримували періодичні сповіщення: диск вилітав,
повертався, а ZFS логував кілька помилок читання. Команда припустила: «диск помирає», бо це звична історія.
Вони міняли диск. Через два тижні інший диск у тому ж шасі повторив те саме.

Вони замінили й його. Після третьої «відмови диска» за місяць у справу втрутилася закупівля, відкрилися тікети постачальнику,
проводилися наради. Тим часом справжній сигнал тихо сидів у SMART атрибуті 199: UDMA CRC помилки зростали на кількох дисках,
але лише тих, що підключені до однієї половини backplane.

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

Виправлення було нудним: заміна відповідних SATA-кабелів і переосадка роз’ємів backplane під час вікна обслуговування.
«Витягнуті» диски? Більшість пройшли діагностику постачальника. Команда жорстко навчилась, що міняти частини без ізоляції змінної — це дорога вгадка при кращому освітленні.

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

Група аналітики даних хотіла знизити енергоспоживання і тепло в щільному стояку. Вони ввімкнули агресивне управління живленням SATA
і налаштували ОС, щоб дозволити дискам і лінкам частіше падати в нижчі стани. На папері це було розумно:
навантаження були імпульсними, простою було багато.

Через два місяці вікна scrub почали давати збої. Не постійно — але достатньо, щоб дратувати.
Scrub викликав хвилю hard resetting link на певних портах, і пул деградував. Перезавантаження «виправляло» проблему,
що полегшувало помилкову діагностику як софтверний глюк.

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

Вони відкотили агресивні налаштування, і скидання припинилися. Пізніше поліпшили кабелювання і замінили підозрілий backplane,
потім обережно повернули помірні режими енергозбереження. Урок не в «ніколи не оптимізувати», а в «не оптимізуйте систему, яку не зробили робочою».

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

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

Однієї ночі пул деградував під час важкого читального навантаження. Сповіщення включали скидання лінків і таймаути. Інженер на чергуванні виконав zpool status -P,
отримав by-id пристрій, потім перевірив документацію: «Bay 12, HBA port 2, backplane lane B». Вони не гадали, який диск витягти.
Вони витягли правильний слайд з першої спроби.

SMART показав CRC помилки, але чисті показники носія. Це підштовхнуло до діагнозу «проблема шляху».
Вони перемістили диск у запасний слот на іншому lane, очистили помилки і відновили операції. Пул відновився, інцидент припинився.
Вдень вони замінили lane backplane і підозрілий кабель.

Практика не була гламурною. Вона не підвищувала пропускну здатність. Вона покращила час повернення до нормального стану.
Коли ви в продакшені, «нудно і правильно» — це функція, а не вада характеру.

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

1) Симптом: ZFS показує READ помилки, але SMART reallocated/pending — нуль

Причина: Таймаути транспорту та скидання лінку, часто кабель/backplane/контролер.

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

2) Симптом: «hard resetting link» повторюється під час scrub/resilver

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

Виправлення: Зупиніть scrub/resilver; виправте фізичний рівень спочатку. Після усунення — повторіть scrub для перевірки стабільності.

3) Симптом: Кілька дисків відвалюються в один час

Причина: Скидання контролера, проблема живлення backplane, несправність expander/backplane або проблема PSU/жгута живлення.

Виправлення: Корелюйте за контролером і живленням; перевірте кабелю харчування; подумайте про міграцію на кращий HBA; перевірте стан backplane.

4) Симптом: CRC помилки поступово зростають, але продуктивність здається нормальною

Причина: Лінк «працює» через повтори. Ви платите податок на затримку і ризикуєте ескалацією відмов.

Виправлення: Проактивно замініть кабель/слот. CRC-лічильники не для декору.

5) Симптом: Після перезавантаження все «добре» деякий час

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

Виправлення: Не сприймайте перезавантаження як ремедіацію. Збирайте логи і SMART перед перезавантаженням; потім виправляйте фізичний компонент або контролер.

6) Симптом: Ви замінили диск, і новий диск «відпадає» в тому ж відсіку

Причина: Дефект lane backplane або кабеля/роз’єму.

Виправлення: Помініть відсік/слот; замініть кабель; огляньте роз’єм backplane; припиніть марнотратні RMA.

7) Симптом: Помилки контрольних сум ZFS з’являються разом зі скиданнями лінку

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

Виправлення: Підвищуйте пріоритет. Переконайтеся, що надлишковість недоторкана, проведіть scrub після стабілізації, і розгляньте заміну всього компоненту шляху (контролер/backplane) замість ганяння по одному кабелю.

8) Симптом: Помилки трапляються тільки коли торкаються шасі або під час обслуговування

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

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

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

Покроково: локалізуйте інцидент, не погіршуючи ситуацію

1. Зупиніть непотрібний важкий I/O (призупиніть scrubs/resilvers, якщо лінк активно скидається).
2. Зберіть докази: zpool status -v, вікно journalctl -k і smartctl -a для постраждалих пристроїв.
3. Визначте диск чи шлях за допомогою SMART (носій vs CRC) і логів ядра (скидання/таймаути).
4. Стабілізуйте шлях: переосаджуйте обидва кінці; замініть SATA-кабель; спробуйте інший слот backplane; переконайтеся в надійності коннектора живлення.
5. Очистіть помилки ZFS після ремедіації, щоб повторні випадки були очевидні.
6. Запустіть scrub після стабілізації, щоб підтвердити цілісність і виявити залишкові слабкі місця.
7. Лише потім замінюйте диски, що показують явні індикатори носія або провалені self-test.

Чистота апаратного забезпечення (зробіть це до того, як загориться сигнал тривоги)

• Використовуйте защіпні SATA-кабелі; уникайте «таємних кабелів» з випадкових коробок.
• Тримайте кабелі короткими і з запасом; без різких вигинів, без натягу на коннектор.
• Документуйте зіставлення відсіку до пристрою і мапінг портів контролера.
• Стандартизуйте HBA і прошивки; уникайте змішування контролерів у тому ж пулі, якщо можливо.
• Перевіряйте якість backplane для роботи на 6Gb/s; трактуйте зношені слоти як витратні матеріали.
• Не перевантажуйте жгути PSU; уникайте дешевих розгалужувачів у продакшені.
• Плануйте scrubs на часи, коли ви можете спостерігати їхній вплив; scrub — це діагностика, а не лише рутина.

Чекліст рішення: що саме замінити?

• Замінити диск, коли: індикатори носія ростуть, self-test провалюється, помилки слідують за диском по портах або ZFS показує постійні checksum-помилки, прив’язані до цього диска.
• Замінити кабель, коли: зростає UDMA CRC, відбуваються скидання лінку або проблема зникає після заміни/переміщення кабелю.
• Замінити/оновити контролер (HBA), коли: кілька портів скидаються разом, відновлення помилок погане, або стабільність покращується при переміщенні дисків на інший контролер.
• Замінити lane/backplane, коли: помилка приковується до слоту незалежно від диска, або кілька дисків на одній секції backplane мають корельовані проблеми.
• Виправити живлення, коли: відключення корелюють із запуском шпинделя/піковим навантаженням, кілька дисків зникають, або один жгут живить всі постраждалі диски.

FAQ

1) Чи завжди скидання SATA-з’єднання означає, що диск виходить з ладу?

Ні. Часто це проблема шляху: кабель, роз’єм backplane, порт контролера або живлення. Використайте SMART (CRC vs носій) і логи (петля скидань), щоб вирішити.

2) Який найкращий SMART-атрибут для підозри «поганого кабелю»?

UDMA_CRC_Error_Count (атрибут 199) — класичний індикатор. Це не ідеально, але зростання CRC при чистих лічильниках носія — сильна підказка.

3) Якщо CRC помилки ненульові, чи варто панікувати?

Ненульовий означає «щось сталося колись». Зростаючі значення означають «це відбувається зараз». Тренд має значення. Очистіть помилки ZFS, зафіксуйте SMART-значення, а потім слідкуйте за приростом.

4) Чому це частіше проявляється під час scrub/resilver, ніж у звичайних навантаженнях?

Scrub/resilver — це стійкий, широкий і наполегливий I/O. Він збільшує чергу команд і читає кожен блок. Маргінальні лінки відмовляють під тривалим стресом.

5) Чи можуть checksum-помилки ZFS спричинитися SATA-кабелем?

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

6) Чи варто вимикати NCQ, щоб «виправити» скидання лінку?

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

7) Чому помилки іноді зникають після перебазування кабелів?

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

8) Коли замінювати контролер/HBA замість ганяння кабелів?

Коли ви бачите корельовані скидання на кількох портах, погане відновлення помилок або нестабільність, що слідує за контролером, а не за окремим диском. Також коли ви покладаєтесь на вбудований AHCI для серйозних пулів і він поводиться як ворог.

9) Чи безпечно виконувати resilver при активних скиданнях лінку?

Ризиковано. Ви тільки продовжите інцидент, збільшите навантаження на пул і можете спровокувати додаткові відмови. Стабілізуйте лінк спочатку, потім робіть resilver.

10) Як довести, що це слот backplane?

Перемістіть відомо хороший диск у цей слот і переставте підозрілий диск в інший. Якщо помилка залишається за слотом — у вас проблема lane/backplane/роз’єму.

Наступні кроки, які можна зробити завтра

Якщо ви бачите скидання SATA-з’єднань в системі ZFS, ваша задача — зробити шлях вводу-виводу знову нудним. ZFS подбає про цілісність,
але він не вміє паяти роз’єми за вас.

1. Зберіть базові докази: зафіксуйте zpool status -v, логи ядра навколо скидання і smartctl -a для постраждалих дисків.
2. Класифікуйте: індикатори носія → диск; CRC/петлі скидань → шлях; корельовані багатодискові скидання → контролер/живлення/backplane.
3. Робіть одну зміну за раз: поміняйте кабель, замініть слот, перемістіть контролер. Підтвердіть, що проблема слідує за компонентом, який ви підозрюєте.
4. Очистіть і моніторьте: скиньте лічильники ZFS після ремедіації; відстежуйте, чи повертаються помилки під scrub.
5. Оновіть слабке місце: якщо ви тримаєте серйозне ZFS-зберігання на ненадійному вбудованому SATA — перейдіть на нормальний HBA і надійний backplane/кабелювання.

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