Помилки контрольної суми ZFS у Proxmox: диск чи кабель — як це довести

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

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

У вас працює сервер Proxmox. ZFS до цього часу був нудно надійним (найкращий тип сховища). А потім одного ранку ви це бачите: CKSUM збільшується у виводі zpool status. Пул усе ще онлайн, віртуальні машини завантажуються, і ваш мозок вже починає вмовляти себе: «Напевно, це артефакт scrub.»

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

Що насправді означають помилки контрольної суми ZFS (і чого вони не означають)

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

Ось важлива тонкість:

Помилки контрольної суми — це відмова цілісності від початку до кінця. Корупція може трапитися на носії, у прошивці диска, контролері, кабелі, бекплейні, експандері, у RAM, під час DMA або через проблеми ядра/драйверів.
ZFS часто може 자동атично їх виправити, якщо є надмірність (mirror/RAIDZ) і «погану» копію можна замінити на «добру». Саме тому ви можете бачити помилки контрольної суми без видимих збоїв додатків — поки не побачите.
Це не те саме, що помилки читання. Помилка читання — це «я не зміг прочитати сектор». Помилка контрольної суми — це «я щось прочитав, але це не те, що ви записували раніше».

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

Цитата для кишені: «Єдина справжня надійність — це надійність, яку ви вимірюєте.» — John Allspaw (ідея перефразована)

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

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

Перший крок: підтвердьте масштаб і чи щось відновив ZFS

Чи деградований пул, або просто показує історичні помилки?
Чи помилки збільшуються зараз, або застигли на одному числі?
Чи виводить zpool status -v шляхи до файлів (метадані) або лише підрахунки?

Другий крок: корелюйте помилки ZFS з помилками транспортного шару ядра

Шукайте скидання лінії ata, I/O error, «frozen» команди, SAS phy reset або SCSI sense-дані в ті ж часові проміжки, що й scrubs/resilvers.
Якщо ви бачите нестабільність транспорту, ваш «поганий диск» може насправді бути кабелем, слотом бекплейна або портом HBA.

Третій крок: використайте журнали SMART/NVMe, щоб відокремити помилку носія від транспорту

Проблеми носія проявляються як reallocated/pending/uncorrectable сектори (HDD) або помилки media/data integrity (NVMe).
Проблеми транспорту проявляються як CRC-помилки (SATA), скидання лінії/тайм-аути (SAS/SATA), але можуть залишити лічильники SMART носія чистими.

Потім вирішуйте: спочатку міняти кабель/слот (дешево, швидко) або спочатку міняти диск (також швидко, але ризиковано, якщо насправді проблема в слоті і ви «заражуєте» замінник).

Цікаві факти та контекст (бо історія повторюється)

End-to-end контрольні суми ZFS були реакцією на «мовчазну корупцію даних» в традиційних стек-платформах, де файлова система сліпо довіряла диску.
Лічильники ATA UDMA CRC існують, бо ще в 1990-х інженери визнали, що кабелі й роз’єми — це елементи з відмовами, а не аксесуари.
Промислові SAS бекплейни додали експандери і більше конекторів — більше гнучкості, але й більше місць, де можуть ховатися погані сигнали.
Споживчі SATA-кабелі дуже різняться за якістю; деякі фактично декоративні, особливо на швидкостях 6 Gb/s при жорстких допусках.
Scrub ZFS навмисно нудний: він читає все і перевіряє контрольні суми, тому часто саме він «виявляє» слабкі ланки першим.
Брехні кешування записів старші за вашу кар’єру: диск/контролер може підтвердити запис, а пізніше його втратити. ZFS контрольні суми фіксують наслідки при читанні.
Поведінка CMR vs SMR HDD може створювати тривалі спади латентності I/O, які виглядають як тайм-аути; тайм-аути можуть викликати скидання, що виглядає як «поганий кабель», хоча диск навантажений.
ECC RAM важлива, бо ZFS активно використовує RAM; корупція в RAM може перетворитися на «помилки контрольної суми» пізніше. Це рідше ніж проблеми з кабелем, але не міфічно.

Рамки доказів: де може статися корупція

Коли ZFS показує помилки контрольної суми для /dev/sdX, вам потрібно вирішити, кого звинувачувати:

Носій диска (поверхня/NAND-клітини)
Електроніка/прошивка диска
Транспорт (SATA-кабель, SAS-кабель, роз’єми)
Бекплейн/експандер (слот, трасування, чіп експандера)
HBA/контролер (порт, прошивка, PCIe-помилки)
Хост (RAM, проблеми PCIe, живлення, драйвер ядра)

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

Як зазвичай виглядає «диск несправний»: SMART показує reallocated/pending/uncorrectable; помилки зберігаються навіть після переміщення в інший порт/кабель; помилки ZFS продовжуються на тому ж фізичному диску після пересування.

Як зазвичай виглядає «кабель/слот несправний»: лічильники SMART носія чисті, але UDMA CRC помилки зростають (SATA) або в журналах ядра видно скидання лінії; заміна/переміщення кабелю/слота зупиняє помилки, навіть з тим самим диском.

Жарт №1 (короткий, по темі): Несправний SATA-кабель — це такий «високодоступний» елемент, який ламається лише коли ви дивитесь.

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

Ось завдання, які я реально виконую на хостах Proxmox/Debian. Кожне включає те, що ви шукаєте, і яке рішення це дає. Виконуйте їх по порядку, якщо можете; перескакуйте, якщо продукція горить.

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

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
  scan: scrub repaired 0B in 02:11:43 with 3 errors on Sun Dec 22 03:12:11 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EFZX-68...   ONLINE       0     0     3
            ata-WDC_WD80EFZX-68...   ONLINE       0     0     0

errors: No known data errors

Що це означає: ZFS виявив невідповідність контрольної суми на одному пристрої і виправив її за допомогою надмірності (mirror). Пул усе ще онлайн.

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

Завдання 2 — Визначте точний шлях пристрою, який використовує ZFS

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep WD80EFZX
lrwxrwxrwx 1 root root  9 Dec 26 09:20 ata-WDC_WD80EFZX-68... -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 26 09:20 ata-WDC_WD80EFZX-68... -> ../../sdc

Що це означає: Ви можете співвіднести імена членів ZFS з /dev/sdX для кореляції з SMART і журналами ядра.

Рішення: Використовуйте імена з /dev/disk/by-id в командах ZFS (стабільні) і співвідносьте з /dev/sdX лише для діагностики.

Завдання 3 — Витягніть останні помилки ядра для цього диска (транспорт SATA/SAS сам себе виказує)

cr0x@server:~$ sudo journalctl -k --since "24 hours ago" | egrep -i "sdb|ata|scsi|sas|link reset|I/O error" | tail -n 30
Dec 26 02:41:12 server kernel: ata6.00: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0x6 frozen
Dec 26 02:41:12 server kernel: ata6: SError: { CommWake DevExch PhyRdyChg }
Dec 26 02:41:12 server kernel: ata6.00: failed command: READ FPDMA QUEUED
Dec 26 02:41:12 server kernel: ata6: hard resetting link
Dec 26 02:41:13 server kernel: ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Dec 26 02:41:15 server kernel: sd 5:0:0:0: [sdb] tag#19 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Dec 26 02:41:15 server kernel: sd 5:0:0:0: [sdb] Sense Key : Medium Error [current]
Dec 26 02:41:15 server kernel: sd 5:0:0:0: [sdb] Add. Sense: Unrecovered read error

Що це означає: Ви бачите скидання лінії і помилку читання. Це може бути диск, але нестабільність транспорту дуже ймовірна через повторювані скидання/завислі команди.

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

Завдання 4 — Перевірте стан SMART і ті лічильники, що відокремлюють «носій» від «транспорту» (HDD/SATA)

cr0x@server:~$ sudo smartctl -a /dev/sdb | egrep -i "Serial Number|SMART overall|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|UDMA_CRC_Error_Count"
Serial Number:    WD-ABC123XYZ
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   199   000    Old_age   Always       -       12

Що це означає: Лічильники носія чисті (0), але є CRC-помилки. CRC-помилки — класичний знак проблем із цілісністю сигналу кабелю/роз’єму/бекплейна для SATA.

Рішення: Замініть SATA-кабель або перемістіть диск в інший слот/порт у першу чергу. Не надсиліть на RMA цілком здоровий диск через особистість $3-кабелю.

Завдання 5 — Для NVMe перевірте журнали помилок і помилки носія (інша термінологія)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0 | egrep -i "critical_warning|media_errors|num_err_log_entries|temperature|percentage_used"
critical_warning                    : 0x00
temperature                         : 42 C
percentage_used                     : 3%
media_errors                        : 0
num_err_log_entries                 : 0

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

Рішення: Якщо помилки контрольної суми ZFS з’являються на NVMe з чистими індикаторами носія, дивіться уважніше на помилки PCIe, живлення, прошивки та слот материнської плати.

Завдання 6 — Перевірте помилки PCIe/AER (особливо для HBA та NVMe)

cr0x@server:~$ sudo journalctl -k --since "7 days ago" | egrep -i "AER|pcie|Corrected error|Uncorrected" | tail -n 40
Dec 25 11:03:18 server kernel: pcieport 0000:00:1c.0: AER: Corrected error received: 0000:03:00.0
Dec 25 11:03:18 server kernel: pcieport 0000:00:1c.0: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer
Dec 25 11:03:18 server kernel: pcieport 0000:00:1c.0: AER: [ 0] RxErr

Що це означає: Помилки фізичного рівня можуть проявлятися як дивні поведінки сховища. «Corrected» не означає «безпечне»; це означає «ми помітили і виправили, поки не перестали помічати».

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

Завдання 7 — Запустіть scrub ZFS і стежте, чи збільшуються помилки контрольної суми під час тривалого читання

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ watch -n 30 "zpool status tank"
Every 30.0s: zpool status tank

  pool: tank
 state: ONLINE
  scan: scrub in progress since Thu Dec 26 09:31:12 2025
        1.32T scanned at 682M/s, 920G issued at 475M/s, 6.12T total
        0B repaired, 0.00% done, 03:45:12 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EFZX-68...   ONLINE       0     0     5
            ata-WDC_WD80EFZX-68...   ONLINE       0     0     0

Що це означає: Кількість CKSUM зростає під час scrub. Це активна відмова, а не історичний залишок.

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

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

cr0x@server:~$ sudo zpool clear tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:11:43 with 0 errors on Thu Dec 26 12:05:01 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-WDC_WD80EFZX-68...   ONLINE       0     0     0
            ata-WDC_WD80EFZX-68...   ONLINE       0     0     0

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

Рішення: Скидайте тільки після збереження zpool status -v і відповідних зрізів journalctl. Якщо помилки швидко повертаються, це доказ наявної проблеми.

Завдання 9 — Перевірте самотести SMART (вони не ідеальні, але допустимі як докази)

cr0x@server:~$ sudo smartctl -t long /dev/sdb
Please wait 728 minutes for test to complete.
cr0x@server:~$ sudo smartctl -a /dev/sdb | egrep -i "Self-test execution|# 1|error"
Self-test execution status:      241 (The previous self-test routine completed with a read failure)
# 1  Extended offline    Completed: read failure       90%     54123         12345678

Що це означає: Довгий тест виявив помилку читання. Це сильний індикатор проблеми носія/диска, а не лише кабелю. (Кабелі все ще можуть викликати помилки читання, але запис помилки читання в SMART зазвичай звинувачує диск.)

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

Завдання 10 — Для SATA спостерігайте `UDMA_CRC_Error_Count` з часом (він не повинен рости)

cr0x@server:~$ sudo smartctl -A /dev/sdb | awk '$2==199 || /UDMA_CRC_Error_Count/ {print}'
199 UDMA_CRC_Error_Count    0x003e   200   199   000    Old_age   Always       -       12
cr0x@server:~$ sleep 60
cr0x@server:~$ sudo smartctl -A /dev/sdb | awk '$2==199 || /UDMA_CRC_Error_Count/ {print}'
199 UDMA_CRC_Error_Count    0x003e   200   199   000    Old_age   Always       -       14

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

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

Завдання 11 — Зіставте диск з фізичним слотом (щоб не поміняти не ту річ о 2 ранку)

cr0x@server:~$ sudo lsblk -o NAME,SERIAL,MODEL,SIZE,WWN,HCTL
NAME   SERIAL         MODEL         SIZE WWN                HCTL
sdb    WD-ABC123XYZ   WDC WD80EFZX  7.3T 0x50014ee2b1c2d3e4 5:0:0:0
sdc    WD-DEF456UVW   WDC WD80EFZX  7.3T 0x50014ee2b1c2d3e5 6:0:0:0

Що це означає: У вас є серійні номери та HCTL. З HBA/бекплейном HCTL допомагає зв’язати фізичний порт/слот. Для SAS можна глибше використовувати SAS-адреси.

Рішення: Маркуйте лотки/кабелі. Якщо ви не можете надійно зіставити фізичне і логічне, ви врешті-решт заміните здоровий диск і залишите зламаний.

Завдання 12 — Перевірте SAS-топологію та події лінків (для SAS HBA/бекплейнів)

cr0x@server:~$ sudo sas2ircu 0 DISPLAY | egrep -i "Enclosure|Slot|Serial|PHY|Link Rate|Error"
Enclosure# : 1
Slot #     : 4
Serial No  : WD-ABC123XYZ
PHY Error Count : 19
Negotiated Link Rate : 6.0 Gbps

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

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

Завдання 13 — Перевірте статистику помилок SATA в sysfs (корисно, коли SMART шумить або неповний)

cr0x@server:~$ for h in /sys/class/ata_link/link*/ata_link/*/dev*/../.. 2>/dev/null; do :; done
cr0x@server:~$ sudo grep -R . /sys/class/ata_link/link*/sata_spd 2>/dev/null | head
/sys/class/ata_link/link5/sata_spd:6.0 Gbps
/sys/class/ata_link/link6/sata_spd:6.0 Gbps

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

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

Завдання 14 — Навантажувальне читання підозрілого диска (обережно) і моніторинг логів

cr0x@server:~$ sudo dd if=/dev/sdb of=/dev/null bs=8M status=progress
118111600640 bytes (118 GB, 110 GiB) copied, 25 s, 4.7 GB/s
240019120128 bytes (240 GB, 224 GiB) copied, 55 s, 4.4 GB/s
^C
cr0x@server:~$ sudo journalctl -k --since "5 minutes ago" | egrep -i "sdb|ata|reset|I/O error" | tail -n 20
Dec 26 09:52:41 server kernel: ata6: hard resetting link
Dec 26 09:52:45 server kernel: ata6.00: configured for UDMA/133
Dec 26 09:52:46 server kernel: blk_update_request: I/O error, dev sdb, sector 123456789 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0

Що це означає: Під тривалим читанням лінк скидається і помилки I/O повторюються. Це не «ZFS драматизує». Це нестабільність транспорту або диска під навантаженням.

Рішення: Якщо dd надійно викликає скидання лінії, ви можете відтворити дефект. Відтворіть один раз до зміни, і знову після заміни кабелю/слота. Це дасть вам «доказ», а не відчуття.

Завдання 15 — Перевірте цілісність пам’яті (рідко, але катастрофічно, коли це причина)

cr0x@server:~$ sudo dmesg -T | egrep -i "EDAC|MCE|Machine check|memory error" | tail -n 20
[Thu Dec 26 07:11:32 2025] EDAC MC0: 1 CE memory scrubbing error on CPU#0Channel#1_DIMM#0

Що це означає: Логуються кориговані помилки ECC пам’яті. Це не негайне обвинувачення, але означає, що платформа не ідеальна. Системи без ECC цього не зафіксують; вони просто будуть корумпувати дані і мовчати.

Рішення: Якщо бачите MCE/EDAC активність і помилки ZFS на кількох vdev/пристроях, розширте діагностику до RAM/CPU/материнської плати перед заміною купи «поганих дисків».

Завдання 16 — Коли вирішили замінити, робіть це по-правильному в стилі ZFS (і зберігайте докази)

cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80EFZX-68... /dev/disk/by-id/ata-WDC_WD80EFZX-NEW123
cr0x@server:~$ watch -n 30 "zpool status tank"
Every 30.0s: zpool status tank

  pool: tank
 state: ONLINE
  scan: resilver in progress since Thu Dec 26 10:12:40 2025
        1.88T scanned at 512M/s, 1.02T issued at 278M/s, 6.12T total
        1.02T resilvered, 16.66% done, 05:12:11 to go
config:

        NAME                                              STATE     READ WRITE CKSUM
        tank                                              ONLINE       0     0     0
        mirror-0                                        ONLINE       0     0     0
            replacing-0                                   ONLINE       0     0     0
              ata-WDC_WD80EFZX-68...                      ONLINE       0     0     0
              ata-WDC_WD80EFZX-NEW123                     ONLINE       0     0     0
            ata-WDC_WD80EFZX-68...                        ONLINE       0     0     0

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

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

Три міні-історії з корпоративного життя (як усе йде не так)

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

Середня компанія працювала на Proxmox на кількох серверах. Дзеркальні ZFS boot-пули, RAIDZ для зберігання VM. На одному хості почали з’являтися помилки контрольної суми на одному диску. Інженер on-call зробив те, що всі роблять під стресом: замінив диск. Помилки зникли. Всі повернулися спати.

Через два тижні помилки контрольної суми повернулися — цього разу на заміненому диску. Це викликало гіпотезу «партія поганих дисків». Пройшла ще одна заміна. Та сама історія: трохи тиші, потім помилки знову.

Неправильне припущення було тонким: «Якщо помилка показує диск, то диск — причина.» Вони ніколи не перевіряли SATA CRC-лічильники. Вони не дивилися dmesg на скидання лінії. Фізичний слот мав кабель, що був сильно зігнутий під час поспішного технічного обслуговування.

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

Урок: ZFS сказав правду («погані байти прийшли»), але не всю правду («де саме вони зіпсувалися»). Треба допросити шлях.

Міні-історія №2: оптимізація, яка обернулася проти

Велика внутрішня команда хотіла швидших відновлень і кращої продуктивності VM. Вони додали HBA з більшою кількістю портів і перейшли з прямого SATA на SAS експандер бекплейн, щоб спростити кабелі. Шафа виглядала чистіше. Інвентарна таблиця виглядала краще. Всім подобалось чисто.

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

Оптимізація полягала в тому, що вони використовували кабелі mini-SAS різної якості і прокладали їх щільно поруч із проводкою живлення. Експандер плюс довші траси кабелів зменшили запас сигналу. Під піковими I/O (scrub плюс знімки VM) шлях інколи глючив. ZFS робив свою роботу: виявляв невідповідність, брав дані з паритету/дзеркала і лікував. Платформа виглядала нормально — до того дня, коли другий диск в тому ж vdev відключився під час resilver і вікно для відновлення стало вузьким.

Вони вирішили проблему звичними засобами: кабелі вищої якості, менш агресивна прокладка і переміщення HBA в слот з меншим числом PCIe correct-ошибок. Продуктивність залишилась високою. Найважливіше — scrubs стали передбачуваними, а помилки контрольної суми припинилися як сезонні алергії.

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

Одна команда, що підтримує фінансові бази, працювала на Proxmox з дзеркалами ZFS для критичних БД. Їхнє середовище не було вишуканим, але в них була звичка: місячні планові scrubs і внутрішній runbook, який вимагає «результати scrub + DELTA SMART» для рев’ю.

Одного разу scrub показав дві помилки контрольної суми на одному члені дзеркала. Не сотні. Усього дві. SMART виглядав чистим, крім того, що CRC-лічильник збільшився на одиницю. Ніяких заявок від користувачів. Спокуса була знехтувати.

Runbook наказував наступний крок: збережіть лічильники, замініть кабель, повторіть scrub протягом 48 годин і порівняйте. Після заміни кабелю CRC перестав зростати. Scrub пройшов чисто. Диск залишився на місці.

Три місяці потому у того ж хоста сталася подія з живленням (техобслуговування UPS). Диски витримали, але старий кабель міг би ускладнити відновлення. Натомість пул піднявся чистим. Команда не «врятувала день» героїчними діями — вони врятували його, дотримуючись нудного графіка.

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

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

1) CKSUM зростає під час scrub, SMART носія виглядає ідеально

Симптом: zpool status показує зростання CKSUM; Reallocated/Pending/Uncorrectable = 0.
Ймовірний корінь: SATA-кабель або роз’єм бекплейна, що викликає CRC-помилки; або SAS PHY-помилки.
Виправлення: Замініть кабель, пересійте обидва кінці, перемістіть на інший порт/слот, потім повторіть scrub і підтвердіть, що CRC/PHY перестали зростати.

2) Один диск показує CKSUM, потім замінений диск показує CKSUM у тій же шафі

Симптом: Ви замінили диск; помилки повернулися на новому.
Ймовірний корінь: Поганий bay/ланка бекплейна, порт експандера або порт HBA.
Виправлення: Залиште новий диск, перемістіть його в інший bay; по можливості вставте відомо хороший диск в підозрілий bay як тест. Якщо помилки лишаються з bay — лагодьте/замініть бекплейн або змініть порт HBA.

3) ПОмиЛКИ CHECKSUM на кількох дисках одночасно

Симптом: Кілька пристроїв в різних vdev показують зростання CKSUM приблизно одночасно.
Ймовірний корінь: Системний: проблема HBA, PCIe-помилки, нестабільність живлення, RAM/MCE або спільний шлях експандера/бекплейна.
Виправлення: Перегляньте журнали AER/MCE, прошивку HBA, PSU/кабелі та спільні шляхи експандера. Не міняйте багато дисків підряд, не звузивши спільний компонент.

4) CKSUM ненульовий, але ніколи не зростає

Симптом: Історичний CKSUM залишається сталим протягом тижнів.
Ймовірний корінь: Минуща подія: втрата живлення, одноразове підкручування кабелю, одноразовий глюк контролера.
Виправлення: Збережіть докази і очистьте лічильники; моніторьте. Якщо повертається — ставтеся як до активної проблеми. Якщо ні — зафіксуйте і рухайтесь далі.

5) «No known data errors», але всі панікують

Симптом: ZFS каже, що виправив помилки; файли не вказані.
Ймовірний корінь: Надмірність спрацювала. Але це все одно вказує на проблему надійності.
Виправлення: Розслідуйте транспорт/носій. Не ігноруйте — це ваша рання система попередження.

6) Помилки з’являються після зміни recordsize, compression або ввімкнення «продуктивнісного» параметру

Симптом: Часові зв’язки вказують, що конфіг змусив корупцію.
Ймовірний корінь: Здебільшого не сам ZFS-параметр. Частіше він збільшив I/O-навантаження і виявив маргінальний кабель/диск, який ламається тільки під постійним навантаженням.
Виправлення: Відтворіть під навантаженням; перевірте помилки транспорту; виправте маргінальний компонент. Потім вирішуйте, чи параметр все ще підходить для навантаження.

Жарт №2 (короткий, по темі): Відмови сховища — як наради: якщо не записуєте нотатки, повторите їх.

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

Контрольний список A — Доведіть «диск» проти «кабель/слот» з мінімальним простоєм

Зніміть докази: збережіть вивід zpool status -v і зріз журналу ядра навколо останнього вікна scrub/resilver.
Перевірте лічильники SMART носія: reallocated, pending, offline uncorrectable (HDD) або media errors (NVMe).
Перевірте лічильники транспорту: SATA UDMA_CRC_Error_Count; SAS PHY помилки; скидання/тайм-аути в журналах ядра.
Очистіть помилки ZFS: тільки після збору доказів.
Замініть найдешевший підозрілий елемент першим: замініть SATA/SAS-кабель або перемістіть диск в інший bay/порт.
Повторіть scrub (або контрольований тест читання): підтвердіть, чи повертаються помилки і чи зростають CRC/PHY лічильники.
Якщо помилки слідують за диском по портах: замініть диск.
Якщо помилки залишаються з портом/bay: лагодьте бекплейн/HBA lane/маршрут кабелів; розгляньте оновлення прошивки HBA і зміну PCIe слота.

Контрольний список B — Якщо пул деградований (перестаньте діагностувати, почніть стабілізувати)

Зменшіть навантаження: призупиніть важкі бекапи, реплікацію та агресивні scrubs.
Підтвердіть стан надмірності: mirror vs RAIDZ, кількість відмов, яку можна витримати.
Експортуйте докази (стан пулу, логи) кудись безпечно.
Замініть найбільш ймовірний несправний компонент на основі доказів, але збережіть старий диск до завершення resilver і перевірки scrub.
Після resilver запустіть scrub знову. Нема scrub — немає впевненості.

Контрольний список C — «Нам потрібні докази для закупівель»

Покажіть zpool status -v з точним членом і зростанням CKSUM.
Покажіть журнали ядра з скиданнями лінії/тайм-аутами або помилками середовища, пов’язаними з тим пристроєм.
Покажіть дельти SMART: CRC зростає (кабель) або reallocated/pending зростає (диск).
Покажіть A/B тест: після заміни кабелю/порту проблема або зупинилася (кабель), або пішла за диском (диск).

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

1) Чи завжди помилки контрольної суми ZFS означають, що диск несправний?

Ні. Це відмова цілісності даних. Диски — поширені винуватці, але кабелі, бекплейни, HBA, PCIe-проблеми та RAM можуть давати ті самі симптоми.

2) Якщо SMART каже «PASSED», чи може диск все одно бути поганим?

Так. Загальний статус SMART — низький бар’єр. Дивіться конкретні атрибути (reallocated/pending/uncorrectable) і результати self-test. Також корелюйте з журналами ядра.

3) Який найкращий один індикатор поганого SATA-кабелю?

Зростання UDMA_CRC_Error_Count. Одна-дві історичні CRC-помилки можуть траплятися; лічильник, що постійно зростає під навантаженням, — курильний знак.

4) ZFS виправив помилки. Чи можна це ігнорувати?

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

5) Чи варто запускати `zpool clear` негайно?

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

6) Чому помилки з’являються під час scrub, але не під час звичайної активності VM?

Scrub змушує повне поверхневе читання і перевірку контрольних сум. Це тривале навантаження і широке покриття, яке виявляє маргінальний транспорт або слабкий носій, які звичайні робочі патерни можуть ніколи не зачепити.

7) Якщо я заміню диск, що слід спостерігати під час resilver?

Слідкуйте за новими помилками читання/запису/контрольної суми на будь-якому члені, і дивіться журнали ядра на скидання. Resilver — це тест для всього ланцюга: диск, кабель, HBA, експандер, живлення.

8) Чи можуть проблеми з RAM виглядати як помилки контрольної суми диска?

Так. Пошкоджена RAM може спотворити дані в пам’яті до запису або після читання. ECC знижує ймовірність і підвищує спостережуваність через журнали EDAC/MCE.

9) Чи можуть compression або recordsize викликати помилки контрольної суми?

Безпосередньо — ні. Ці налаштування змінюють патерни I/O і навантаження CPU, що може виявити маргінальні апаратні шляхи. Виправляйте маргінальність, не звинувачуйте стиснення, просто тому що це останнє, що ви міняли.

10) Що якщо пул RAIDZ і ZFS вказує на один диск з CKSUM?

Звертайтеся аналогічно: перевірте транспорт/носій для того диска спочатку. Але пам’ятайте, що resilver/scrub RAIDZ навантажує весь vdev; уважно стежте за іншими членами під час діагностики.

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

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

Зробіть це в такому порядку:

Зніміть zpool status -v і відповідне вікно журналу ядра.
Перевірте індикатори SMART/NVMe носія і індикатори транспорту (CRC/PHY/скидання лінії).
Очистьте лічильники, потім відтворіть під scrub або контрольованим читанням.
Якщо докази вказують на транспорт (CRC/PHY помилки, скидання з чистими носіями) — спочатку міняйте кабель/слот/порт.
Замініть диск, коли докази вказують на носій (провалений довгий SMART-тест, зростання reallocated/pending/uncorrectable, помилки слідують за диском).
Після будь-якого виправлення — scrub знову. Якщо ви не зробили scrub, ви не перевірили.

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

Схожі статті

ZFS Scrub: як часто запускати та що він доводить Помилки контрольної суми ZFS: що вони означають і що робити насамперед Файлова система Proxmox стала лише для читання: чому це трапляється і як відновити