ZFS: таймаути SAS проти SATA — чому SAS «відчувається стабільнішим» під навантаженням

February 2, 2026 • February 3, 2026 • Читання: 8 хв • Views: 7

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

Ваш пул ZFS працює нормально. Поки не перестає. Ви запускаєте scrub або resilver, затримки змінюються з «нудних» на «гострі»,
і раптом dmesg починає описувати катастрофу: таймаути команд, скидання лінків і диски, які зникають на той час, що
псує вам день і впевненість.

Багато хто виходить із таких інцидентів з простою думкою: «SAS стабільний; SATA хитрий.» Це не зовсім неправда, але й не вся історія.
Справжня різниця — в семантиці таймаутів, поведінці відновлення помилок, шарах транспорту та в тому, як HBA реагують під стресом.
ZFS — лише вісник. Не стріляйте в нього.

Що насправді означає «стабільний» у світі ZFS

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

Диски не зникають з ОС під час scrub/resilver.
Обробка помилок обмежена: збої проявляються як помилки, а не як затримки на кілька хвилин.
Контролери відновлюються чисто без скидання всіх лінків або всієї шини.
Затримка залишається передбачуваною настільки, щоб ZFS міг підтримувати пул здоровим без паніки.

ZFS «алергічний» до тиші. Якщо vdev припиняє відповідати достатньо довго, ZFS вважає його втраченим і виводить з ладу.
Іноді диск «в порядку» в споживчому сенсі — жодних перерозподілених секторів, SMART каже OK — але він провів 45 секунд
на глибокому відновленні помилки. ZFS не переймається почуттями вашого диска; йому потрібне своєчасне завершення I/O.

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

Таймаути 101: помилка, яку ви бачите, проти реальної причини

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

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

На практиці SAS «перемагає» під навантаженням, бо його екосистема передбачає спільний бекплейн,
multipath, експандери, десятки дисків і людей, які замінять диск замість того, щоб благати його повторювати спроби дві хвилини.

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

Поведінка SAS та SATA, що має значення під навантаженням ZFS

Error recovery philosophy: bounded vs “let me cook”

Підхід відновлення помилок: обмежений проти «дай ще спробу»

Підприємницькі SAS-диски зазвичай налаштовані для RAID-середовищ: якщо читання сектора зазнає невдачі, не витрачайте вічність.
Поверніть помилку швидко, щоб шар надлишковості (RAID, ZFS mirror/RAIDZ) міг реконструювати та переписати.
Це не альтруїзм; це виживання. В масиві один завислий диск може зупинити багатьох.

Багато SATA-дисків — особливо десктопні/легкі NAS-моделі — дуже наполегливо намагаються відновити сектор внутрішньо.
Це може означати десятки секунд циклів повторних спроб. Протягом цього часу диск може не відповідати на інші команди.
З точки зору ОС пристрій «завис».

Підприємницька відповідь тут — TLER/ERC/CCTL (різні виробники, одна концепція): обмежити, скільки часу
диск витрачає на відновлення, перш ніж повернути помилку. SAS-диски часто поводяться так, ніби це завжди увімкнено.
SATA-диски можуть не підтримувати це, за замовчуванням мати вимкнене або поводитись непослідовно між прошивками.

Transport and command handling: SAS is SCSI-native; SATA is a translation party

Транспорт і обробка команд: SAS — рідний для SCSI; SATA — протокол ATA з трансляціями

SAS — це SCSI-транспорт. SATA — це ATA. Коли ви підключаєте SATA-диски за SAS HBA/бекплейном, зазвичай це через
SATA Tunneling Protocol (STP). Воно працює, але це не те саме, що end-to-end SAS:
деякі звіти про помилки менш експресивні, деякі шляхи відновлення менш акуратні, і під сильними помилками ви можете
бачити скидання лінків, що виглядають непропорційно для одного поганого сектора.

SAS також дає приємності, такі як dual-port (на багатьох дисках) і кращу інтеграцію з multipath.
Це важливо, коли мета — «продовжувати обслуговувати», а не «врешті-решт завершити читання».

Queuing and fairness: who gets to talk, and how long

Черги та справедливість: хто говорить і як довго

Під навантаженням стек зберігання — це система управління чергами. Інфраструктури SAS (HBA, експандери, прошивка)
зазвичай розраховані на глибші черги та кращу справедливість між багатьма пристроями. SATA може підтримувати NCQ,
але кінцево-до-кінцевої екосистема більш змінна — особливо при використанні multipliers портів, дешевих бекплейнів або
споживчих контролерів.

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

Reset blast radius: SAS tends to be surgical; SATA can be “reset the universe”

Радіус «вибуху» скидання: SAS зазвичай хірургічний; SATA може бути «скиньте всесвіт»

Коли SAS-пристрій поводиться некоректно, обробка помилок часто залишається в межах цього пристрою або конкретного phy.
З SATA за STP відновлення може вимагати скидання лінку, який також обслуговує інші диски на тому ж шляху бекплейна,
або принаймні тимчасово переривати трафік так, що виникають побічні таймаути.

Ось чому одне й те ж навантаження може створити «один поганий диск» на SAS і «три диски зникли на 10 секунд»
на SATA в одному шасі. Це не магія. Це розмір домену скидання.

SMART and telemetry: SAS tends to tell you more, sooner

SMART та телеметрія: SAS частіше каже вам більше і раніше

SAS-пристрої відкривають багатші SCSI log pages і частіше дають послідовні звіти про grown defects та лічильники помилок.
SATA SMART відомий виробничо-специфічними атрибутами і «все ОК, поки не стало дуже погано». Ви все ще можете
ефективно працювати на SATA, але доведеться компенсувати це кращим трендом та суворішими критеріями заміни.

Перший жарт (і лише щоб ви мали перерву): відновлення помилок SATA — як мікрохвильовка, яка не зупиняється, бо «майже готова». Ви все одно їсте холодну піцу о 2:00.

Як scrub/resilver ZFS підсилюють слабкі ланки

ZFS — система надійності, яка навмисно виконує багато I/O. Scrub читає все, щоб перевірити контрольні суми.
Resilver читає багато, щоб відновити надлишковість. Обидва — фонові завдання, які виглядають як бенчмарк,
коли пул достатньо великий.

Це створює два ефекти:

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

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

Операторською пасткою є інтерпретувати «ZFS faulted the disk» як «диск помер». Іноді це так. Іноді диск в порядку, але ваш транспорт поганий.
Іноді диск «в порядку» окремо, але невідповідний для масиву, бо занадто довго зависає.

Факти та історичний контекст (те, що ми постійно переучуємо)

Факт 1: SAS було спроектовано як послідовник паралельного SCSI з урахуванням мультидискових бекплейнів та експандерів; «багато дисків, один HBA» завжди був план.
Факт 2: Ранні цілі дизайну SATA — настільне/комодиті сховище; довгі внутрішні повторні спроби були прийнятні, якщо вони відновлять файл без участі користувача.
Факт 3: Концепція TLER/ERC/CCTL з’явилася через те, що апаратні RAID-масиви потребували, щоб диски швидко фейлили, щоб контролер міг відбудовувати з паритету/дзеркал.
Факт 4: SATA за SAS бекплейнами часто використовує STP — протокол-міст, що може зменшувати деталізацію обробки помилок у порівнянні з нативним SAS.
Факт 5: SAS підтримує dual-port на багатьох корпоративних дисках, що дозволяє мультипат; SATA зазвичай цього не робить (з кількома нішевими винятками).
Факт 6: Scrub ZFS створено для постійного виявлення і виправлення тихої корупції; він навмисно генерує робоче навантаження, якого інші файлові системи зазвичай не створюють.
Факт 7: Інциденти «диск зник під навантаженням» часто простежуються до домену скидання: один контролер, що скидається, може флепнути кілька SATA-пристроїв на спільному шляху.
Факт 8: Індустрія роками вчилася, що «SMART каже OK» не є гарантією; таймаути й abort-и команд можуть передувати будь-яким змінам порогів SMART.
Факт 9: Підприємницькі SAS-екосистеми зазвичай ретельніше валідують комбінації прошивок (HBA + експандер + диск), бо ринок вимагає передбачуваної поведінки відмов.

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

Міні-історія 1: Інцидент через хибне припущення

Середня компанія перемістила сховище артефактів збірки на нову ZFS-машину. Дизайн виглядав розумно: RAIDZ2, багато
дешевих висококапакістних SATA-дисків, популярний SAS HBA в IT-режимі і охайне 24-бей шасі. Хтось запитав: «Чи нам купувати SAS-диски?»
Хтось інший відповів: «Та ні, ZFS має контрольні суми. Все буде добре».

Перший місяць був нудним. Потім scrub спіймався під завантаженим днем CI. Затримки зросли. Один диск почав таймаутити.
HBA намагався відновитися скиданнями лінків. Два інші SATA-диски у сусідніх відсіках глітчили настільки, щоб викликати
таймаути також. ZFS вивів один диск з ладу, потім тимчасово позначив інший як недоступний, і пул виявився деградувавшим
з долею паніки.

Хибне припущення було не в тому, що «SATA ненадійний». Хибне припущення було в тому, що «функції цілісності даних усувають проблеми транспорту і таймаутів».
Контрольні суми виявляють корупцію. Вони не змушують I/O завершуватися вчасно.

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

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

Інша команда хотіла швидших resilver-ів. Ідея: підвищити глибину черг, збільшити паралелізм і дати HBA «розбігтися».
Вони змінили налаштування, ввімкнули агресивніший scrub і оголосили перемогу після швидкого тесту на порожньому пулі.

Через шість тижнів один диск реально вийшов з ладу. Resilver почався на пулі, який також обслуговував бекапи бази даних.
Нові налаштування загнали диски у довгі черги. Затримки досягли стелі. Маргінальний SATA-диск, який «буферував», почав накопичувати
таймаути команд. HBA відповів скиданнями, а resilver все одно сповільнився — але тепер пул був деградувавшим і нестабільним.

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

Вони відкотили налаштування, обмежили вплив scrub/resilver і вимірювали успіх за критерієм «пул залишається онлайн і затримки обмежені», а не за чистим MB/s.
Resilver зайняв більше часу. Бізнес отримав менше простоїв. Торг добре вийшов.

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

Фінансова компанія запустила ZFS на SAS-дисках з суворою культурою обслуговування. Нічого героїчного: відома добра прошивка HBA,
узгоджені моделі дисків, планові scrub-и і проста звичка перевіряти лічильники помилок щотижня. Вони також робили недоречну річ:
маркували кожен кабель і записували, який відсік відповідає за який /dev.

Одного кварталу scrub повідомив про кілька checksum-помилок і один пристрій з ростом помилок транспорту.
Ніякого простою. Ніяких заявок. Просто тихі докази.

На чергуванні замінили один кабель під час вікна обслуговування і проактивно поміняли диск з підвищеною кількістю grown defect.
Наступний scrub був чистим.

Через два місяці в сусідній стояку сталася подія живлення, що спричинила коротку лавину скидань лінків. Їхня система залишилась в строю.
Чому? Бо «нудна» гігієна означала, що не було маргінальних лінків, які могли перетворити транзієнт в каскад. Операційна стабільність — це в основному відсутність сюрпризів, а сюрпризи люблять запущені кабелі.

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

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

Спочатку: Підтвердіть, що ZFS вважає за відбувається

Чи пул деградував? Який vdev?
Чи це checksum-ошибkи (корупція даних) або I/O-ошибки/таймаути (пристрій/транспорт)?
Чи проблема локалізована на одному диску або на кількох дисках за тим самим HBA/шляхом бекплейну?

По-друге: Корелюйте з логами ядра та визначте шар транспорту

Шукайте SCSI таймаути, abort-и, task management resets, link resets.
Визначте драйвер: mpt2sas/mpt3sas, megaraid_sas, ahci, ata_piix тощо.
Перевірте, чи уражені пристрої — SAS чи SATA за STP.

По-третє: Виміряйте затримку та тиск черги під час події

Використовуйте zpool iostat -v щоб знайти повільний vdev.
Використовуйте метрики затримки по диску (iostat -x) щоб знайти, який диск зависає.
Перевірте, чи HBA скидається повторно (це ознака проблем транспорту/прошивки або диска, який отруює шину).

По-четверте: Вирішіть, від карантинувати диск чи виправити шлях

Якщо один диск показує повторні таймаути і високі помилки медіа: замінити його.
Якщо кілька дисків на тому ж шляху бекплейна флепають разом: огляньте/замініть кабелі, експандер/бекплейн, прошивку HBA.
Якщо проблеми з’являються лише під scrub/resilver: обмежте агресивність rebuild і плануйте ці роботи поза піком; але розслідуйте базовий слабкий компонент.

Другий жарт (останній): Диск, який «виходить лише під scrub», — як парашут, що «виходить лише під стрибки». Брошура не винна.

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

Команди нижче припускають Linux-хост. Якщо ви використовуєте illumos або FreeBSD, концепти переносяться; імена файлів і інструменти змінюються.
Показані виводи репрезентативні — у вашій машині буде своя драма.

Task 1: Check pool health and error type

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 in progress since Thu Dec 26 01:11:19 2025
        3.21T scanned at 812M/s, 1.94T issued at 492M/s, 12.8T total
        0B repaired, 15.15% done, 0:07:21 to go
config:

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

errors: Permanent errors have been detected in the following files:
        tank/backups/db/full-2025-12-25.sql.zst

Що це означає: Помилки контрольних сум означають, що ZFS виявив дані, які не збігаються з контрольною сумою.
Це може бути поганий сектор, поганий кабель, погане RAM або проблема контролера — але це не лише симптом таймауту.
Рішення: Якщо є checksum-помилки, розглядайте це як інцидент цілісності даних. Ідентифікуйте уражені файли, перевірте резервні копії, а потім шукайте апаратну причину.

Task 2: Watch per-vdev latency during scrub/resilver

cr0x@server:~$ sudo zpool iostat -v tank 2
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        8.44T  4.18T  2.40K    112   520M  5.12M
  raidz2-0                  8.44T  4.18T  2.40K    112   520M  5.12M
    ata-WDC_WD140EDFZ-...       -      -    410     19  86.9M   862K
    ata-WDC_WD140EDFZ-...       -      -     12     18   512K   840K
    ata-WDC_WD140EDFZ-...       -      -    398     18  84.2M   835K
    ata-WDC_WD140EDFZ-...       -      -    401     19  85.1M   860K
    ata-WDC_WD140EDFZ-...       -      -    395     19  83.7M   858K
    ata-WDC_WD140EDFZ-...       -      -    404     19  85.4M   865K
--------------------------  -----  -----  -----  -----  -----  -----

Що це означає: Один диск майже не читає, поки інші працюють. Це класичний знак зависання пристрою або проблеми шляху.
Рішення: Знайдіть OS-імені цього диска і перевірте логи та SMART. Якщо повторюється — плануйте заміну або усунення шляху.

Task 3: Confirm which /dev node maps to the ZFS disk ID

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep WD140EDFZ | head
lrwxrwxrwx 1 root root  9 Dec 26 01:12 ata-WDC_WD140EDFZ-11A0VA0_VGH1ABC1 -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 26 01:12 ata-WDC_WD140EDFZ-11A0VA0_VGH1ABC2 -> ../../sdc
lrwxrwxrwx 1 root root  9 Dec 26 01:12 ata-WDC_WD140EDFZ-11A0VA0_VGH1ABC3 -> ../../sdd

Що це означає: ZFS показує by-id імена; вам потрібен kernel-пристрій для SMART, логів помилок і відображення контролера.
Рішення: Використовуйте by-id послідовно в ZFS, але мапуйте на /dev/sdX для тріажу.

Task 4: Pull kernel errors around the timeouts

cr0x@server:~$ sudo journalctl -k -S "2025-12-26 01:00" -g "timeout|reset|I/O error|mpt3sas|ata"
Dec 26 01:13:44 server kernel: sd 0:0:8:0: [sdb] tag#91 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
Dec 26 01:13:44 server kernel: sd 0:0:8:0: [sdb] tag#91 CDB: Read(16) 88 00 00 00 00 1b 2f 9e 80 00 00 00 01 00 00 00
Dec 26 01:13:44 server kernel: ata9: hard resetting link
Dec 26 01:13:45 server kernel: ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 26 01:13:46 server kernel: sd 0:0:8:0: [sdb] tag#93 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Dec 26 01:13:49 server kernel: mpt3sas_cm0: log_info(0x31120600): originator(PL), code(0x12), sub_code(0x0600)

Що це означає: У вас є SCSI таймаути і скидання SATA-лінку на тому ж шляху. Це вказує або на некоректний SATA-диск за STP,
або на проблему транспорту (кабель/бекплейн), що викликає нестабільність лінку.
Рішення: Якщо скидання зосереджені навколо одного диска — замініть цей диск. Якщо скидання зачіпають кілька дисків на тому самому «ataX» або порту HBA — перевірте кабелі/бекплейн та прошивку HBA.

Task 5: Identify whether a disk is SAS or SATA, and through which host

cr0x@server:~$ sudo lsblk -d -o NAME,MODEL,TRAN,SERIAL,HCTL /dev/sdb
NAME MODEL          TRAN SERIAL     HCTL
sdb  WDC WD140EDFZ  sata VGH1ABC1   0:0:8:0

Що це означає: TRAN=sata повідомляє, що це SATA-диск навіть якщо він стоїть у SAS-шасі.
HCTL показує SCSI-адресу. Рішення: Очікуйте більше нюансів STP; будьте консервативні щодо чутливості до таймаутів і якості кабелів.

Task 6: Inspect SMART for evidence of slow recovery or link trouble (SATA)

cr0x@server:~$ sudo smartctl -a /dev/sdb
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.6.0] (local build)
=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Red
Device Model:     WDC WD140EDFZ-11A0VA0
Serial Number:    VGH1ABC1
SATA Version is:  SATA 3.3, 6.0 Gb/s
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   200   200   0      Old_age   Always       -       3
198 Offline_Uncorrectable   0x0010   200   200   0      Old_age   Offline      -       3
199 UDMA_CRC_Error_Count    0x003e   199   199   0      Old_age   Always       -       24

Що це означає: Pending/offline uncorrectable sectors вказують на проблеми медіа; UDMA CRC помилки вказують на проблему лінку/кабеля/бекплейна.
Рішення: Pending sectors під scrub — червоний прапор — плануйте заміну. CRC-помилки: переутвердьте/замініть кабель/шлях бекплейна і спостерігайте, чи лічильник зростає.

Task 7: Inspect SMART for SAS with richer error logs

cr0x@server:~$ sudo smartctl -a /dev/sde
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.6.0] (local build)
=== START OF INFORMATION SECTION ===
Vendor:               SEAGATE
Product:              ST12000NM000J
Revision:             SN03
Logical Unit id:      0x5000c500d3a1b2c3
Transport protocol:   SAS (SPL-3)
=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK
Current Drive Temperature:     34 C
Elements in grown defect list: 8
Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
read:          1200           2         1202      1200        98123.456         0
write:            0           0            0         0        77234.112         0

Що це означає: Є grown defects, але читання все ще коригуються без некоригованих помилок.
SAS дає більш чітку картину корекційної активності. Рішення: Трендуйте «grown defect list» і швидкість корекцій. Якщо вони прискорюються або з’являються некориговані помилки/таймаути — замінюйте превентивно.

Task 8: Check HBA driver/firmware and spot known reset storms

cr0x@server:~$ sudo lspci -nn | grep -i -E "sas|lsi|broadcom"
03:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0087] (rev 02)

cr0x@server:~$ sudo modinfo mpt3sas | egrep "version|firmware"
version:        46.100.00.00
firmware:       0x2221 (IR)

Що це означає: Потрібно знати, що ви запускаєте. HBA в IR-режимі, наприклад, може бути не тим, що ви хотіли для ZFS passthrough.
Рішення: Переконайтеся, що HBA в IT-режимі для ZFS, і тримайте прошивки/драйвери консистентними в інфраструктурі. Якщо бачите скидання, перевірте, чи ви не на проблемній комбінації.

Task 9: Check link error counters (SAS phy stats)

cr0x@server:~$ for phy in /sys/class/sas_phy/phy-*; do echo "== $phy =="; sudo cat $phy/invalid_dword_count $phy/running_disparity_error_count $phy/loss_of_dword_sync_count $phy/phy_reset_problem_count 2>/dev/null; done | head -n 20
== /sys/class/sas_phy/phy-0:0 ==
0
0
0
0
== /sys/class/sas_phy/phy-0:1 ==
12
5
3
1

Що це означає: Ненульові disparity/sync/reset лічильники — це проблеми фізичного рівня: кабель, бекплейн,
порт експандера або маргінальний конектор. Рішення: Якщо лічильники зростають з часом, замініть компоненти шляху до того, як звинуватите ZFS або диск.

Task 10: Identify which disks share an expander/backplane path

cr0x@server:~$ sudo lsscsi -t
[0:0:0:0]    disk    sas:0x5000c500d3a1b2c3  /dev/sde
[0:0:1:0]    disk    sas:0x5000c500d3a1b2c4  /dev/sdf
[0:0:8:0]    disk    sata:0x50014ee2b7c81234 /dev/sdb
[0:0:9:0]    disk    sata:0x50014ee2b7c85678 /dev/sdc

Що це означає: Ви бачите SAS vs SATA пристрої і часто можете вивести, які за експандером.
Рішення: Якщо кілька пристроїв на тому самому host/channel показують помилки разом — підозрюйте спільний шлях.

Task 11: Observe per-disk latency and queue depth during pain

cr0x@server:~$ iostat -x -d 2 3 /dev/sdb /dev/sdc
Linux 6.6.0 (server)  12/26/2025  _x86_64_ (32 CPU)

Device            r/s   w/s  rkB/s  wkB/s  await  aqu-sz  %util
sdb              8.0   1.0   512    64    980.0   31.5   99.9
sdc            210.0  12.0  86000  1200    12.4    2.1   88.0

Що це означає: sdb має ~1 секунду середнього очікування і велику чергу. Він не встигає, він зависає.
Рішення: Якщо це корелює з таймаутами ядра, у вас проблема з пристроєм/шляхом на sdb. Замініть диск або виправте транспорт; не просто «налаштовуйте ZFS» в надії.

Task 12: Check for ZFS slow I/O messages

cr0x@server:~$ sudo dmesg -T | grep -i "slow io" | tail
[Thu Dec 26 01:13:55 2025] ZFS: vdev IO failure, zio 0x0000000123456789, type 1, offset 231145472, size 131072
[Thu Dec 26 01:13:55 2025] ZFS: vdev slow I/O, zio 0x0000000123456790, 60 seconds

Що це означає: ZFS сигналізує, що I/O займає десятки секунд. Це зазвичай співпадає з відновленням диска або скиданнями транспорту.
Рішення: Слідкуйте за повторюваними повідомленнями «slow I/O» як за індикатором передвідмови; це не нормальний фон.

Task 13: Throttle scrub impact (Linux OpenZFS)

cr0x@server:~$ sudo zfs get -H -o property,value autotrim tank
autotrim	off

cr0x@server:~$ sudo cat /sys/module/zfs/parameters/zfs_vdev_scrub_max_active
10

cr0x@server:~$ echo 4 | sudo tee /sys/module/zfs/parameters/zfs_vdev_scrub_max_active
4

Що це означає: Ви зменшили кількість одночасних scrub I/O на vdev, знизивши тиск.
Рішення: Використовуйте це як тимчасовий важіль стабільності під час інциденту. Якщо після обмеження таймаути зникають, у вас все ще є слабкий компонент — просто такий, що виходить лише під навантаженням.

Task 14: Temporarily pause and resume a scrub to stop the bleeding

cr0x@server:~$ sudo zpool scrub -p tank

cr0x@server:~$ sudo zpool status tank | sed -n '1,12p'
  pool: tank
 state: DEGRADED
  scan: scrub paused since Thu Dec 26 01:20:11 2025
        3.80T scanned at 0B/s, 2.41T issued at 0B/s, 12.8T total

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

Task 15: Offline a flapping disk to protect the pool (carefully)

cr0x@server:~$ sudo zpool offline tank ata-WDC_WD140EDFZ-11A0VA0_VGH1ABC1

cr0x@server:~$ sudo zpool status -v tank | sed -n '1,25p'
  pool: tank
 state: DEGRADED
status: One or more devices is being resilvered or is offline.
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz2-0                  DEGRADED     0     0     0
            ata-WDC_WD140EDFZ-...   OFFLINE      0     0     0
            ata-WDC_WD140EDFZ-...   ONLINE       0     0     3
            ata-WDC_WD140EDFZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDFZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDFZ-...   ONLINE       0     0     0
            ata-WDC_WD140EDFZ-...   ONLINE       0     0     0

Що це означає: Ви видалили флапаючий пристрій зі шляху I/O. Це може зупинити скидання шини і захистити залишкові диски.
Рішення: Робіть це лише якщо надлишковість дозволяє (RAIDZ2/mirror безпека). Якщо ви на один диск від втрати даних, спочатку виправте шлях і уникайте офлайну, якщо диск не отруює весь vdev.

Task 16: Replace the disk and monitor resilver progress

cr0x@server:~$ sudo zpool replace tank ata-WDC_WD140EDFZ-11A0VA0_VGH1ABC1 /dev/disk/by-id/ata-WDC_WD140EDFZ-11A0VA0_VGH9NEW1

cr0x@server:~$ sudo zpool status tank | sed -n '1,22p'
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Thu Dec 26 02:01:09 2025
        1.22T scanned at 421M/s, 512G issued at 176M/s, 12.8T total
        0B repaired, 3.90% done, 5:48:12 to go

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

Task 17: Check SATA error handling parameters (Linux SCSI layer)

cr0x@server:~$ cat /sys/block/sdb/device/timeout
30

cr0x@server:~$ echo 60 | sudo tee /sys/block/sdb/device/timeout
60

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

Task 18: Verify ZFS isn’t being sabotaged by write cache surprises

cr0x@server:~$ sudo hdparm -W /dev/sdb | head -n 2
/dev/sdb:
 write-caching =  1 (on)

Що це означає: Write cache увімкнено. Це нормально, але на деяких споживчих дисках і деяких корпусах кеш + поведінка при втраті живлення можуть бути ризикованими.
Рішення: Якщо у вас немає захисту від втрати живлення і ви дбаєте про синхронні семантики, розгляньте SLOG для синхронних навантажень і підприємницькі диски для передбачуваної поведінки замість бездумного перемикання кешу.

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

1) Симптом: «ZFS продовжує виводити різні диски під час scrub»

Корінь: Скидання на спільному шляху (бекплейн, експандер, кабель або HBA), що викликає таймаути для кількох пристроїв, а не кількох поганих дисків.
Виправлення: Корелюйте, які диски флепають разом, використовуючи логи ядра та HCTL. Замініть кабель/бекплейн/експандер; оновіть прошивку HBA; зменшіть складність домену скидання.

2) Симптом: «SMART виглядає добре, але я бачу таймаути команд»

Корінь: Диски можуть ставати в стані очікування під час внутрішнього відновлення помилок, не спрацьовуючи пороги SMART; помилки транспорту також не завжди відображаються як класичні SMART-збої.
Виправлення: Ставтеся до таймаутів як до першокласного сигналу відмови. Трендуйте CRC/лічильники лінків і скидання ядра; замініть диск або шлях до того, як це стане інцидентом втрати даних.

3) Симптом: «Resilver жахливо повільний і пул здається нестабільним»

Корінь: Агресивний паралелізм відбудови, що насичує черги; слабкий диск, що зависає під навантаженням; або SATA-диск, що виконує довгі внутрішні повторні спроби.
Виправлення: Тимчасово обмежте scrub/resilver, захистіть латентність продакшну і замініть будь-який диск зі значними await/таймаутами.

4) Симптом: «Checksum-помилки з’являються, потім зникають після перезавантаження»

Корінь: Переривчастий лінк або помилка пам’яті; перезавантаження тимчасово маскує це, скидаючи шлях.
Виправлення: Не святкуйте. Запустіть тести пам’яті, перевірте логи ECC і інспектуйте SAS phy або SATA CRC-лічильники. Замініть маргінальні компоненти.

5) Симптом: «Тільки SATA-диски відпадають; SAS — ні»

Корінь: STP-трансляція плюс поведінка споживчих дисків при відновленні помилок та більший радіус побічних скидань.
Виправлення: Використовуйте підприємницькі/NAS-диски з обмеженим відновленням, якщо доступно; віддавайте перевагу SAS для щільних мультибійних шасі; переконайтеся, що бекплейн і HBA валідувані для SATA-навантажень.

6) Симптом: «Після заміни одного диска інший починає таймаутити під час resilver»

Корінь: Resilver створив достатньо стресу, щоб виявити наступний найслабший диск або маргінальний шлях транспорту.
Виправлення: Запустіть повний scrub після resilver, стежте iostat/затримки і превентивно замініть будь-який диск із зростаючими pending sectors або повторними slow I/O.

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

Покроково: коли ви бачите таймаути під scrub/resilver

Заморозьте зону ураження: призупиніть scrub, якщо система нестабільна і впливає на продакшн.
Зберіть докази: збережіть zpool status -v, zpool iostat -v та логи ядра за період події.
Ідентифікуйте підозріле(і) пристрій(и): замапуйте by-id → /dev/sdX і зафіксуйте HCTL-адреси.
Відрізніть медіа від транспорту: SMART pending/offline uncorrectable вказує на медіа; CRC/лічильники лінку вказують на транспорт.
Перевірте кореляцію спільного шляху: чи декілька дисків ділять той самий host/port/сегмент бекплейна?
Застосуйте тимчасові обмеження: зменшіть конкурентність scrub/resilver для стабілізації під час роботи.
Виправте найімовірнішу причину: замініть кабель/бекплейн спочатку, якщо лічильники лінку ростуть; замініть диск, якщо він сам стукоче або має помилки медіа.
Відновіть scrub/resilver і спостерігайте: якщо помилки повторюються — ви пропустили справжню слабку ланку.
Гігієна після інциденту: заплануйте повний scrub після resilver і переглядайте тренди лічильників помилок щотижня протягом місяця.

Чекліст рішення: коли обирати SAS замість SATA для ZFS

Оберіть SAS, якщо у вас щільне шасі, експандери, багато дисків на HBA або вимоги до високого часу безвідмовної роботи.
Оберіть SAS, якщо очікуються часті resilver-и (великі пули, високий churn) і ви хочете обмежене відновлення помилок за замовчуванням.
Оберіть SATA, якщо вартість/TB домінує, шасі просте і ви готові бути суворим щодо моделей дисків, кабелів і превентивної заміни.
Уникайте змішування «що дешевше цього кварталу» SATA-SKU в одному пулі. Послідовність краще за сюрприз.

Конфігураційний чекліст: зробіть SATA менш хобі

Використовуйте реальний HBA в IT-режимі; уникайте RAID-режимів.
Віддавайте перевагу якісним бекплейнам і коротким пронумерованим кабелям; замініть усе, що інкрементує CRC-лічильники.
Плануйте scrub-и поза піком і обмежуйте їх, якщо латентність важлива.
Трендуйте таймаути і скидання, а не лише SMART «PASSED».
Тримайте запаси дисків; замінюйте при перших ознаках slow I/O під scrub, а не після третього інциденту.

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

1) Чи SAS априорі надійніший за SATA?

Не априорно. Екосистеми SAS зазвичай інженерно розроблені для передбачуваної поведінки відмов під багатодисковим навантаженням.
Ця передбачуваність — те, що оператори інтерпретують як надійність.

2) Чому SATA-диски «випадають» під scrub ZFS?

Часто тому, що диск зависає під час внутрішнього відновлення помилки, ОС таймаутить команду, і контролер скидає лінк.
За STP за SAS HBA це скидання може бути дуже гучним.

3) Якщо ZFS має контрольні суми, навіщо важливі таймаути?

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

4) Чи варто збільшувати Linux disk timeouts, щоб зупинити флап?

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

5) Чи експандери SAS викликають таймаути?

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

6) Чи checksum-помилки завжди проблема диска?

Ні. Вони можуть походити від диска, кабеля, HBA, бекплейна або пам’яті. Тому обов’язково корелюйте логи ядра, лічильники лінку і SMART.

7) Чому SAS «фейлиться швидко» і це краще для ZFS?

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

8) Чи погано змішувати SAS і SATA в одному пулі?

Це не заборонено, але ускладнює операційну підтримку. Різна поведінка таймаутів і телеметрії ускладнює інтерпретацію інцидентів.
Якщо змушені змішувати — ізолюйте за vdev-класом або призначенням пулу і документуйте очікування.

9) Який найпоказовіший індикатор проблеми з кабелем/бекплейном?

Помилки, що зачіпають кілька дисків, які ділять фізичний шлях, плюс зростаючі CRC/лічильники лінку. Помилки медіа зазвичай локалізовані; помилки транспорту люблять компанію.

10) Що оптимізувати: швидкість scrub чи стабільність?

Стабільність. Scrub — це захисна процедура. Якщо потрібно, щоб він завершувався швидше, масштабувати ємність або краще планувати.
Не перетворюйте перевірку надлишковості на denial-of-service.

Висновок: наступні кроки, які запобігають дзвінку о 3:00

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

Практичні наступні кроки:

Класифікуйте ваші помилки (checksum vs timeout vs transport) і перестаньте трактувати їх як взаємозамінні.
Корелюйте відмови зі спільними шляхами використовуючи HCTL і лічильники лінку; агресивно міняйте кабелі/бекплейни.
Замініть диски, які зависають під scrub навіть якщо SMART каже «PASSED». Ваш пул потребує своєчасного I/O, а не оптимізму.
Обмежуйте scrub/resilver щоб захистити продакшн-латентність, а потім виправляйте базову слабкість, замість постійного життя на обмеженнях.
Якщо важливий час безвідмовної роботи — купуйте SAS для щільних мультибійних систем. Ви платите за обмежену поведінку відмов і менший радіус побічних скидань.

Одна перефразована думка, яку варто тримати на самоклейці, з зазначенням авторства: paraphrased idea — John Allspaw: надійність походить від побудови систем, які очікують відмов і відновлюються передбачувано.