SATA-сетеві скидання в Debian 13: доведіть, що винен кабель або бекплейн, а не Linux

October 14, 2025 • February 3, 2026 • Читання: 6 хв • Views: 7

Було корисно?

Деякі відмови починаються не з вибуху, а з невеличкого «завмирання» диска: один ataX: link is slow to respond, а потім повільний крах — відновлення RAID, resilver ZFS, монтування файлової системи в режимі лише для читання і сварки в команді про те, чи винне «нове ядро Debian».

Якщо ви експлуатуєте Debian 13 на реальних серверах із реальними SATA-лініями — бекплейни, експандероподібні штуки, дешеві breakout-кабелі та повітряний потік, що справний, поки раптом ні — SATA link resets виглядають як софтверна проблема, поки ви не доведете, що це апаратний збій. Ось як це довести.

Що таке SATA link reset насправді (і чого це не означає)

«SATA link reset» — це спроба контролера відновити фізичне та протокольне з’єднання з диском. Linux повідомляє про це через libata (підсистема ядра, що обробляє ATA/SATA). Ви можете побачити фрази типу:

link is slow to respond
COMRESET failed
hard resetting link
SATA link up 6.0 Gbps (після відновлення)
ataX: device reported invalid CHS (часто шум)
I/O error, dev sdX (видимий для застосунків радіус наслідків)

Важлива відмінність: link reset — це не те ж саме, що помилка носія.

Помилка носія: диск не може надійно прочитати сектор. Зазвичай це збільшує SMART-атрибути, такі як «Reallocated_Sector_Ct», або фіксує помилки читання.
Помилка лінку: контролер і диск не можуть чисто спілкуватися. Часто це збільшує SMART-атрибут «UDMA_CRC_Error_Count» і проявляється як скидання/тайм‑аути. Платівки можуть бути в порядку; розмова не проходить.

Linux не «створює» погіршення електричного сигналу. Але Linux безумовно буде повідомлювати про це і отримає звинувачення. Ваше завдання — відокремити: (1) регресію ядра, (2) проблему контролера/прошивки, (3) диск, що виходить з ладу, (4) кабель/бекплейн/шлях живлення, який не може утримати стабільний лінк.

Ось операційна реальність: якщо ви бачите повторні link resets і CRC-помилки на одному відсіку/порті, заміна диска часто «виправляє» проблему лише тому, що ви перевпорядкували кабель або змінили вібраційний патерн. Це не виправлення; це виграш у рулетці.

Одна цитата, що збереже вас від ілюзій: «Hope is not a strategy.» — Ген. Gordon R. Sullivan

Жарт №1: SATA-кабель як запрошення на зустріч — усе здається в порядку, поки пакети не почнуть падати й усі не звинуватять календар.

Факти та контекст: чому SATA відмовляє саме так

Короткі, конкретні факти, що допоможуть інтерпретувати логи Debian 13. Це не тривіальні відомості заради самого факту; вони пояснюють режими відмов.

SATA — це послідовний інтерфейс, але на краях він усе ще аналоговий. Біти передаються по електричному лінку, чутливому до імпедансу, екранування, зносу роз’ємів і перекручувань сигналу — особливо в щільних бекплейнах.
COMRESET — реальний електричний рукопотиск. Коли ви бачите «COMRESET failed», хост намагається скинути PHY‑рівень і не отримує чистої відповіді. Часто це кабель/бекплейн, іноді живлення, зрідка контролер.
SMART CRC-помилки були вигадані, щоби ловити проблеми кабелю. «UDMA_CRC_Error_Count» інкрементується, коли диск виявляє помилки передачі між диском і хостом. Помилки носія такого лічильника не збільшують.
NCQ зробив SATA швидшим і налагодження складнішим. Native Command Queuing дозволяє багато одночасних команд. Коли лінк поганий, відмови виглядають як тайм‑аути в черзі, а не як чиста «помилка читання сектора».
Споживчі SATA‑роз’єми не розраховані на нескінченну кількість вставлень. Бекплейн, що бачив роки замін дисків, має знос: пружинна напруга змінюється, окислення, пластик деформується від тепла.
Багато «SATA бекплейнів» насправді пасивні, поки раптом ні. Деякі мають мультиплексори, ретаймери, індикатори або дешеві роз’єми, що працюють нормально на 1.5 Gbps, але створюють хаос на 6.0 Gbps.
libata у Linux агресивно відновлює помилки за дизайном. Він пробує жорсткі скиди, м’які скиди, пониження швидкості та перевірку. Це добре для доступності і погано для пошуку винних.
Пониження швидкості лінку — індикатор із димом. Порт, що веде переговори до 3.0 або 1.5 Gbps замість 6.0 під навантаженням, часто свідчить про проблеми якості сигналу, а не баг файлової системи.
Вібрація та тепло важать більше, ніж визнають. Ледь маргінальне з’єднання може відмовляти лише під піковим I/O (більше EMI, більше тепла) або при зміні профілю обдуву вентиляторів.

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

Ви на виклику. Масив деградовано. Застосунок тайм-аутить. Потрібен найшвидший шлях до відповіді «що міняти і до чого торкатися?». Ось він.

Перший крок: підтвердити, що це нестабільність лінку, а не просто відмова диска

Проскануйте journalctl/dmesg на предмет hard resetting link, COMRESET, failed command: READ FPDMA QUEUED, link up/down.
Перевірте SMART UDMA_CRC_Error_Count (або журнал PHY‑помилок SATA, якщо доступний). Якщо він зростає — підозрюйте кабель/бекплейн як першу гіпотезу.
Перевірте, чи помилки прив’язані до відсіку/порту, а не до серійного номера диска.

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

Виконайте мапування /dev/sdX → ataX → порт контролера → фізичний відсік.
Шукайте зміни швидкості лінку і повторні скидання на тому самому ataX.
Запустіть контрольований тест читання лише на цьому диску й спостерігайте логи в режимі реального часу.

Третій крок: ізолюйте домен несправності шляхом замін, які дають знання

Перш ніж міняти ОС або «налаштовувати ядро», замініть кабель/шлях бекплейна. Перемістіть диск в інший відсік; якщо помилки лишаються з відсіком, у вас є підозра.
Замініть на відомо‑робочий кабель (або інший роз’єм бекплейна) і знову прогайтуйте тест під навантаженням.
Лише після виключення кабелів/бекплейна/живлення витрачайте час на прошивки, драйвери контролера або регресії ядра.

Такий порядок — не ідеологія, а математика: кабельні та бекплейн‑помилки часті, швидко тестуються і не з’являться у вашому CI.

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

Якщо ви хочете припинити цикл «винен Linux», потрібен відтворюваний ланцюжок доказів:

Хронологія: точні часові позначки скидань і помилок I/O.
Ідентифікація: який диск (WWN та серійний номер), який ataX, який порт HBA, який відсік.
Тип сигналу: CRC/лінк/рукопотиск проти переназначення секторів або баги контролера.
Відтворення: тест, що викликає помилку (або не викликає) в контрольованих умовах.
Результат заміни: помилка слідує за відсіком/кабелем/бекплейном (апаратний шлях) або за диском (пристрій).

Оновлення ядра може змінити таймінги й виявити маргінальний лінк. Це не означає, що ядро «зламало SATA». Це означає, що ядро перестало обходити вашу ненадійну фізичну прошарок.

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

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

Task 1: Pull a focused SATA/libata error timeline from the journal

cr0x@server:~$ sudo journalctl -k --since "2 hours ago" | egrep -i "ata[0-9]+|sata|hard reset|link up|link down|comreset|i/o error|exception"
Dec 29 10:11:02 server kernel: ata7: exception Emask 0x10 SAct 0x0 SErr 0x4050000 action 0x6 frozen
Dec 29 10:11:02 server kernel: ata7: SError: { CommWake 10B8B DevExch }
Dec 29 10:11:02 server kernel: ata7: hard resetting link
Dec 29 10:11:03 server kernel: ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 29 10:11:03 server kernel: ata7.00: configured for UDMA/133
Dec 29 10:11:04 server kernel: blk_update_request: I/O error, dev sde, sector 124518400 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

Значення: Emask 0x10 і прапори SErr разом із hard reset сильно вказують на подію транспорту/лінку. I/O‑помилка — побічна шкода.

Рішення: Розглядайте це як нестабільність лінку, доки не доведено протилежне. Наступний крок: ідентифікувати, який фізичний диск — sde, і перевірити його SMART CRC‑лічильники.

Task 2: Confirm which disk is sde (serial, WWN, model)

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,WWN,HCTL /dev/sde
NAME SIZE MODEL            SERIAL         WWN                HCTL
sde  12T  ST12000NM0008-2A ZS2ABC12       0x5000c500cafe1234 3:0:6:0

Значення: Тепер у вас є стабільні ідентифікатори (серійник/WWN) і шлях HCTL.

Рішення: У зверненнях і постмортемах використовуйте WWN/серійний номер, а не /dev/sde. Імена пристроїв можуть змінюватися; WWN зазвичай — ні.

Task 3: Read SMART attributes; look specifically for CRC errors vs media errors

cr0x@server:~$ sudo smartctl -a /dev/sde | egrep -i "UDMA_CRC_Error_Count|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|SMART overall"
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
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   200   000    Old_age   Always       -       47

Значення: Носій виглядає чистим (без переназначень/очікуваних секторів). CRC‑помилки ненульові. CRC‑помилки майже завжди вказують на кабель/бекплейн/шлях контролера, а не на поверхню диска.

Рішення: Припиніть замінювати диски «бо він ламається». Сконцентруйтеся на лінку: кабель, роз’єм бекплейна, порт HBA і шлях живлення до цього відсіку.

Task 4: Check whether CRC errors are still increasing

cr0x@server:~$ sudo smartctl -A /dev/sde | awk '$1==199{print}'
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       47

cr0x@server:~$ sleep 60; sudo smartctl -A /dev/sde | awk '$1==199{print}'
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       49

Значення: Значення виросло з 47 до 49 за одну хвилину. Це активна проблема транспорту.

Рішення: Ескалюйте до фізичного втручання. Плануйте вікно обслуговування, якщо масив має резервування; інакше — розглядайте це як ризик неминучої відмови.

Task 5: Watch kernel messages live while you do a controlled read

cr0x@server:~$ sudo dmesg -Tw
[Sun Dec 29 10:21:17 2025] ata7: hard resetting link
[Sun Dec 29 10:21:18 2025] ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
[Sun Dec 29 10:21:18 2025] ata7.00: configured for UDMA/133

cr0x@server:~$ sudo dd if=/dev/sde of=/dev/null bs=4M status=progress iflag=direct
12582912000 bytes (13 GB, 12 GiB) copied, 7 s, 1.8 GB/s

Значення: Лінк відновився на 3.0 Gbps замість 6.0. Це пониження швидкості — класичний «маргінальна якість сигналу під навантаженням».

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

Task 6: Identify the libata “ata7” mapping in sysfs

cr0x@server:~$ readlink -f /sys/class/block/sde/device
/sys/devices/pci0000:00/0000:00:1f.2/ata7/host6/target6:0:6/6:0:6:0

Значення: Ви можете зв’язати блочний пристрій зі специфічним ATA‑портом (ata7) і хостом.

Рішення: Використовуйте цей шлях, щоб знайти PCI‑пристрій контролера і далі — слот/HBA/ланцюжок бекплейна.

Task 7: Confirm the controller PCI identity and driver

cr0x@server:~$ lspci -nnk | egrep -A3 -i "sata|ahci|scsi|sas"
00:1f.2 SATA controller [0106]: Intel Corporation 82801JI (ICH10 Family) SATA AHCI Controller [8086:3a22]
	Subsystem: Supermicro Computer Inc Device [15d9:0801]
	Kernel driver in use: ahci
	Kernel modules: ahci

Значення: У вас AHCI (поширений вбудований SATA). Якби це був HBA, ви побачили б mpt3sas, megaraid_sas тощо.

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

Task 8: Verify link speed and negotiated features (where available)

cr0x@server:~$ sudo grep -H . /sys/class/ata_link/link*/sata_spd 2>/dev/null | head
/sys/class/ata_link/link6/sata_spd: 3.0 Gbps
/sys/class/ata_link/link7/sata_spd: 6.0 Gbps

Значення: Принаймні один лінк працює на 3.0 Gbps. Якщо ваші диски й контролер підтримують 6.0, це може бути пониженням після помилок.

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

Task 9: Inspect per-disk error counters and kernel “timeout” patterns

cr0x@server:~$ sudo journalctl -k --since "2 hours ago" | egrep -i "failed command|READ FPDMA|WRITE FPDMA|cmd|timeout|resetting"
Dec 29 10:21:16 server kernel: ata7.00: failed command: READ FPDMA QUEUED
Dec 29 10:21:16 server kernel: ata7.00: cmd 60/08:00:00:10:6e/00:00:00:00:00/40 tag 0 ncq dma 4096 in
Dec 29 10:21:16 server kernel: ata7.00: status: { DRDY }
Dec 29 10:21:16 server kernel: ata7: softreset failed (1st FIS failed)
Dec 29 10:21:17 server kernel: ata7: hard resetting link

Значення: «FIS failed» і тайм‑аути команд із скиданнями відповідають проблемі транспорту, а не «файлова система злиться».

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

Task 10: Check if the drive is actually being power-cycled (power path/backplane)

cr0x@server:~$ sudo journalctl -k --since "2 hours ago" | egrep -i "rejecting i/o|device offline|Spinning|Start/Stop|Power-on|reset"
Dec 29 10:21:19 server kernel: sd 6:0:6:0: [sde] rejecting I/O to offline device
Dec 29 10:21:19 server kernel: sd 6:0:6:0: [sde] tag#12 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00

Значення: «offline device» може статися від втрати лінку, але якщо супроводжується повторними повідомленнями про «новий диск», підозрюйте перебої живлення або поведінку бекплейна щодо присутності диска.

Рішення: Якщо бачите цикли видалення/додавання, у пріоритеті перевірка живлення бекплейна і PSU; перевірте стабільність напруги на рейках. Втрата лінку плюс зникнення пристрою — сильніший тривожний сигнал.

Task 11: Verify drive identity is stable across resets (same WWN comes back)

cr0x@server:~$ udevadm info --query=all --name=/dev/sde | egrep "ID_WWN=|ID_SERIAL=|DEVPATH="
E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata7/host6/target6:0:6/6:0:6:0/block/sde
E: ID_SERIAL=ST12000NM0008-2A_ZS2ABC12
E: ID_WWN=0x5000c500cafe1234

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

Рішення: Стабільна ідентичність + зростаючі CRC‑помилки вказують на якість фізичного лінку, а не на дивну прошивку диска.

Task 12: If you run mdadm, confirm whether the array is dropping the same member repeatedly

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid10] [raid6] [raid5]
md0 : active raid10 sde1[2](F) sdb1[0] sdc1[1] sdd1[3]
      11718067200 blocks super 1.2 512K chunks 2 near-copies [4/3] [_UUU]

Значення: (F) означає відмовлений член масиву. Якщо той самий слот регулярно відмовляє, це рідко «Linux RAID нестабільний» — це зазвичай шар транспорту.

Рішення: Не додавайте один і той самий диск знову й знову без виправлення транспорту. Ви витратите цикли відновлення і підвищите ризик другої помилки.

Task 13: If you run ZFS, see whether errors are checksum or I/O-level, and which vdev

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: Replace the device using 'zpool replace'.
  scan: resilver in progress since Sun Dec 29 10:30:01 2025
config:

	NAME                        STATE     READ WRITE CKSUM
	tank                        DEGRADED     0     0     0
	  raidz2-0                  DEGRADED     0     0     0
	    wwn-0x5000c500cafe1234  DEGRADED     5     0     0  too many errors
	    wwn-0x5000c500beef5678  ONLINE       0     0     0
	    wwn-0x5000c500abcd9999  ONLINE       0     0     0
	    wwn-0x5000c5001234aaaa  ONLINE       0     0     0

Значення: ZFS показує READ‑помилки на конкретному WWN. Це узгоджується з тим, що link resets спричиняють I/O‑відмови (не обов’язково биті перевірки контрольних сум).

Рішення: Якщо CKSUM нульовий, а READ ненульовий разом із libata‑скиданнями, швидше за все це не прихована корупція — це невдачі читання через зникнення лінку. Спочатку виправте транспорт, потім чистьте/замінюйте пристрій.

Task 14: Check drive temperature and error log to rule out overheating-induced instability

cr0x@server:~$ sudo smartctl -a /dev/sde | egrep -i "Temperature|Error Log|ATA Error Count"
194 Temperature_Celsius     0x0022   037   045   000    Old_age   Always       -       63
SMART Error Log Version: 1
ATA Error Count: 0

Значення: 63°C — гаряче для багатьох enterprise SATA‑дисків. Воно може ще «працювати», але маржі сигналу звужуються з підвищенням температури, і бекплейн деформується сильніше.

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

Як зіставити /dev/sdX з фізичним портом без здогадок

Найшвидший спосіб втратити довіру — витягнути не той диск. Другий за швидкістю — «перевставити кабелі» без карти. Зробіть мапування.

Використовуйте стабільні ідентифікатори: WWN, серійник, HCTL і ataX

Починайте з WWN/серійного номера через lsblk або udevadm. Потім зіставте з:

HCTL (Host:Channel:Target:Lun) для SCSI‑стилю нумерації (поширено для HBA)
ataX для нумерації портів libata (поширено для AHCI і багатьох SATA‑шляхів)
PCI‑шлях щоб знайти фактичний контролер

На багатьох серверах бракуючий ланцюжок — маркування фізичних відсіків. Правильне рішення — не «племінні знання», а документація: мапа портів від HBA‑порту → роз’єм бекплейна → номери відсіків.

Практичний підхід до мапування, коли мапи немає

Ідентифікуйте проблемний диск по WWN/серійному номеру.
Знайдіть його DEVPATH і асоціацію з ataX.
Зіставте ataX з конектором материнської плати/HBA, перевіряючи діаграми кабелів, мануал шасі або фізично трасуючи під час вікна обслуговування.
Підтвердіть, перемістивши лише цей диск в інший відсік і перевіривши, чи йдуть помилки за ним.

Останній крок важливий, бо перетворює «припущення» на доказ.

Апаратні шаблони: як кабелі та бекплейни видають себе

Коли люди звинувачують Linux, вони зазвичай реагують на кореляцію: «ми оновили Debian, і диски почали скидуватися». Ця кореляція реальна. Вона просто не означає те, що вони думають.

Ось шаблони, що надійно відділяють домени несправностей.

Патерни несправностей кабелю

Підвищення CRC‑лічильників (SMART атрибут 199) при тому, що переназначені/очікувані сектори залишаються незмінними.
Помилки корелюють з вібрацією або рухом: поштовх шасі, розгін вентиляторів, рух пучка кабелів поруч.
Проблема слідує за кабелем/з’єднанням бекплейна: переміщення диска в інший відсік лагодить проблему без заміни диска.
Пониження швидкості лінку до 3.0/1.5 Gbps на цьому порті після скидань.

Що робити: замініть кабель на відомо‑добрий, бажано коротший і краще екранований; уникайте різких вигинів; прокладайте подалі від джерел струму. Якщо це Mini‑SAS→SATA breakout, вважайте його витратним матеріалом.

Патерни несправностей бекплейна

Проклятий лише один відсік, незалежно від моделі або серійного номера диска.
Присутність диска «флапається»: ОС логує зникнення й повторну появу диска.
Декілька дисків на тому ж сегменті бекплейна показують помилки після підвищення температури або вібрації.
Дивні індикатори LED/SGPIO: активність застрягає або індикатори неправильно миготять — може корелювати з проблемами сигналу чи заземлення на дешевих бекплейнах.

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

Патерни несправностей шляху живлення

Симультанні скидання на кількох портах, часто після стрибка навантаження (CPU‑спайки, ривок вентиляторів, запуск дисків).
Скидання дисків збігаються з тривогами PSU або провалами напруги, зафіксованими BMC.
Диски логують події, пов’язані з живленням (залежить від моделі; часто не явно).

Що робити: перевірте стан PSU, живлення бекплейна і чи налаштовано staggered spin‑up. Хороший PSU все одно може погано поводитися на транзієнтах.

Патерни несправностей контролера/прошивки

Помилки поширюються по багатьох портах без кореляції з одним відсіком.
Скидання викликаються певними патернами команд (TRIM, глибина NCQ, черги записів) і зникають після оновлення драйвера/прошивки.
Логи ядра показують скиди контролера, а не лише лінк‑скидання.

Що робити: перевірте версії прошивок; протестуйте з іншим HBA, якщо можливо. Але не використовуйте «можливо контролер» як виправдання ігнорувати CRC‑докази.

Патерни несправностей диска

Збільшення переназначених/очікуваних секторів, SMART‑health падає, самотести провалюються.
Помилки слідують за диском у відомо‑добрий відсік і кабель.
SMART Error Log показує помилки читання/запису без відповідного зростання CRC.

Що робити: замініть диск і не сперечайтеся з числами.

Жарт №2: Якщо ваше сховище «відмовляє лише під навантаженням», вітаю — ви створили систему, що ідеально надійна в режимі простою.

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

1) Інцидент, спричинений хибним припущенням: «Це нове ядро Debian»

Середовище було звичайним: пара Debian‑серверів з реплікованою базою даних, кожен із кількома SATA SSD у фронт‑шасі з hot‑swap. Рутинне оновлення принесло нове ядро, і протягом дня один вузол почав тикати ata скиданнями. Команда зробила те, що роблять команди: відкотила ядро.

Помилки зменшилися, але не зникли. Це був перший натяк. Другий натяк був неприємніший: інший вузол почав показувати рідкісні скидання. Наратив змінився на «можливо, прошивка SSD не любить Linux». Було відкрито квиток у вендора. Час витрачався на збір трас і логів, що фактично показували те, що вже було очевидно: лінк скидається.

Що зупинило петлю — дисциплінована кореляція. SRE порівняв UDMA_CRC_Error_Count для кожного диска в шасі. Зростання CRC спостерігалось лише в відсіках 5–8. Ці відсіки ділили один роз’єм бекплейна і один проклад блоку кабелів. Оновлення ядра не було причиною; воно лише стало моментом, коли система стала достатньо навантаженою, щоб виявити маргінальне з’єднання.

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

2) Оптимізація, що вдарила по руках: «Підвищимо глибину черги і заощадимо»

Флот аналітичних вузлів оптимізували для пропускної здатності. Хтось вирішив, що більша глибина черг і паралелізм покращать утилізацію. Збільшили конкуренцію I/O в застосунку і відрегулювали деякі налаштування блочного шару, щоб тримати диски завантаженими. Початкові бенчмарки були чудові. Всі потиснули один одному руки і перейшли далі.

Через два тижні підмножина хостів почала бачити спорадичні READ FPDMA QUEUED помилки і link resets. Помилки концентрувалися під час пакетних вікон. Команда сприйняла це як проблеми навантаження і рознесла задачі у часі, що допомогло. Отут і полягала пастка: система стала стабільною тільки тоді, коли вона стала менш корисною.

Корінь виявився апаратним. Шасі використовувало довгі SATA‑кабелі, прокладені поруч із високострумовими пучками живлення. За низького I/O маржі лінку вистачало. За великої глибини черги диски і контролер працювали більше, тепловий профіль змінився, а частота помилок лінку зросла — поки libata не почав скидати порти. Нічого містичного не сталося; вони перенесли систему з «працює в лабораторії» в «відмовляє в реальному навантаженні», натиснувши на тонкі маржі сигналу.

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

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

Інша організація мала змішане сховище: mdadm, ZFS і багато hot‑swap відсіків. У них була звичка, що здавалася старомодною: у кожного шасі в runbook була мапа портів. Вона містила номери портів HBA, номера деталей кабелів, маркування роз’ємів бекплейна і діапазон відсіків, які обслуговує той роз’єм. Також вони записували WWN дисків до інвентарю під час встановлення.

Одного дня хост почав логувати link resets на одному диску. На виклику виконали playbook: ідентифікували WWN, зіставили з портом HBA, зіставили з відсіком. Вони не тягнули випадкові диски. Не перезавантажували «щоб очистити». Не відкотили ядро. Перемістили диск у запасний відсік того самого хоста і повторили тест читання. Помилки лишилися в оригінальному відсіку.

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

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

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

Це те, що затягує інциденти довше, ніж треба.

1) Симптом: повторні `hard resetting link` + зростаючі CRC‑помилки

Корінь: маргінальний SATA‑шлях сигналу (кабель, роз’єм, бекплейн).
Виправлення: замінити кабель/бекплейн; перпрокласти; уникати різких вигинів; повторно протестувати під навантаженням; перевірити, що CRC перестав зростати.

2) Симптом: диск повністю відкидається і повертається як «новий»

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

3) Симптом: помилки «перемістилися» після вашої заміни

Корінь: ви пересілили або потривожили проблемний кабель/конектор, тимчасово покращивши контакт.
Виправлення: не оголошуйте проблему вирішеною; запустіть контрольований навантажувальний тест і спостерігайте CRC‑лічильники; все одно замініть підозрілий кабель.

4) Симптом: лінк після скидів веде переговори на 1.5/3.0 Gbps

Корінь: пониження через відновлення помилок через погану якість сигналу.
Виправлення: розглядайте як проблему фізичного рівня; замініть кабель/бекплейн; підтвердіть, що швидкість залишається 6.0 Gbps під тривалим навантаженням.

5) Симптом: «зміна планувальника I/O вирішила проблему»

Корінь: ви знизили інтенсивність I/O і тим самим сховали проблему.
Виправлення: зберігайте планувальник, якщо він допомагає, але все одно замініть маргінальний лінк. Приховані проблеми повернуться, коли вам знадобиться продуктивність.

6) Симптом: ZFS/mdadm перестановки постійно перезапускаються на тому самому диску

Корінь: нестабільний транспорт, що спричиняє транзитні I/O‑збої під час важких послідовних читань/записів.
Виправлення: спочатку виправте лінк; потім виконайте rebuild. Шторми відновлень перетворюють одну маргінальну несправність у повний відказ.

7) Симптом: оновлення ядра «спровокувало» проблему

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

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

Чекліст реагування на інцидент (поки система деградована)

Зберіть логи: journalctl -k навколо події. Збережіть їх у надійному місці.
Запишіть ідентифікацію диска: модель, серійник, WWN, HCTL і мапу ataX.
Перевірте SMART на предмет ознак носія vs CRC. Якщо CRC зростає — підніміть рівень уваги до кабелів/бекплейна.
Зменшіть радіус ураження: призупиніть непотрібні важкі задачі; уникайте повторних спроб відновлення.
Якщо є резервування, плануйте контрольовану ізоляційну заміну (перемістіть диск в інший відсік).
Після фізичної зміни запустіть той самий тест читання і спостерігайте логи в режимі реального часу.
Перевірте лічильники: CRC має перестати зростати; лінк має залишатися на очікуваній швидкості.

План на вікно технічного обслуговування (що міняти і в якому порядку)

Замініть SATA‑кабель/breakout, що обслуговує проблемний порт/групу відсіків.
Якщо проблеми тривають і слідують за відсіком — замініть/відремонтуйте сегмент бекплейна або припиніть використовувати цей слот.
Перевірте живлення: перепідключіть роз’єми живлення до бекплейна; перевірте стан PSU; впевніться у відсутності провалів під навантаженням.
Лише після цього розгляньте оновлення прошивки контролера або заміну HBA/материнської плати.
Після змін запустіть тривалий burn‑in читання/записів на уражених дисках.

Чекліст після інциденту (щоб не отримати повтор)

Створіть мапу портів: HBA‑порт → мітка кабелю → роз’єм бекплейна → номери відсіків.
Уніфікуйте використання WWN‑імен у конфігураціях ZFS/mdadm де можливо.
Трекуйте SMART CRC‑лічильники з плином часу; сповіщуйте про їх дельту, а не лише про абсолютні пороги.
Майте в запасі відомо‑добрі кабелі і (якщо можливо) запасний бекплейн.
Документуйте процедуру ізоляції, щоб наступний on‑call не імпровізував.

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

1) Чи означає SATA link reset завжди, що диск поганий?

Ні. Часто диск у порядку, а лінк — ні. Якщо SMART показує зростання UDMA_CRC_Error_Count при чистих атрибутах носія — підозрюйте кабель/бекплейн першочергово.

2) Якщо SMART overall‑health показує PASSED, чи може диск все одно бути проблемою?

Так. SMART «PASSED» — це не гарантія; це слабка перевірка порогу. Але у випадках link reset диск рідко винен — дискова дискримінація зазвичай відбувається через CRC проти переназначень/очікуваних секторів.

3) Чому це почалося одразу після оновлення до Debian 13?

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

4) Чи може погане живлення викликати CRC‑помилки?

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

5) Чи безпечно продовжувати роботу, якщо CRC‑помилки ненульові, але стабільні?

Якщо CRC‑лічильник старий і не зростає, можливо, це історична подія (наприклад, один раз зачепили кабель). Якщо він зростає — ви втрачаєте цілісність лінку і повинні виправити це швидко.

6) Як довести, що винен бекплейн, а не диск?

Перемістіть той самий диск (той самий WWN/серійник) в інший відсік/шлях кабелю. Якщо помилки зникають — винний старий відсік/шлях. Якщо помилки пішли за диском — диск винен.

7) Чому я бачу зниження швидкості лінку до 3.0 Gbps?

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

8) Чи варто змінювати параметри ядра або libata, щоб зменшити скидання?

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

9) Якщо кілька дисків у різних відсіках показують зростання CRC, що робити?

Підозрюйте спільний елемент: пакет кабелів, роз’єм бекплейна, групу портів HBA або живлення. Шукайте спільність, а не випадковість.

10) Чи потрібен SAS, щоб уникнути цього?

Не обов’язково, але роз’єми і кабелі SAS загалом більш надійні в серверному середовищі. SATA може бути надійним; він просто вимагає кращої дисципліни на фізичному рівні, ніж багато шасі забезпечують.

Висновок: наступні кроки, що реально зменшують ризик

Якщо Debian 13 логить SATA link resets — ставтеся до цього як до розслідування, а не дискусії. Linux говорить те, що бачить. Ваше завдання — визначити, чи проблема на поверхні диска, у контролері або в мідному та пластиковому шарі, який усі забувають.

Зробіть наступне, в порядку:

Зберіть щільну хронологію логів ядра і зафіксуйте докази.
Перевірте SMART: CRC проти атрибутів носія. Якщо CRC рухається — припиніть звинувачувати файлові системи.
Зіставте проблемний пристрій до ataX/HCTL і фізичного відсіку.
Запустіть контрольований тест читання, спостерігаючи dmesg в реальному часі.
Ізолюйте шлях заміною, що дає знання: перемістіть диск в інший відсік або замініть кабель.
Після виправлення перевірте: швидкість лінку стабільна, CRC перестав зростати, і немає скидань під навантаженням.

Якщо ви запам’ятаєте лише один операційний урок: запишіть мапу портів і відстежуйте дельти CRC. Це не гламурно, але перетворює моторошну «проблему з Linux‑сховищем» на просту заміну деталей з чеками.