О 02:17 хтось пише: «Сховище показує помилки. Можу просто виконати zpool clear?» Це UNIX‑еквівалент питання, чи можна зупинити пожежну сигналізацію, вийнявши батарейку. Іноді це нормально. Іноді так ви перетворюєте відновлювану помилку на кар’єрно‑обмежувальний інцидент.
zpool clear — це не магія і не обслуговування. Це мітла. Використовуйте її, щоб підмести вже відомі, вже виправлені проблеми. Не ховайте з її допомогою прориву сантехніки.
Що zpool clear насправді робить (і чого не робить)
zpool clear скидає лічильники помилок та певні стани несправності, які ZFS записав для пулу або конкретного vdev. І все. Воно не «ремонтує дані». Воно не «фіксує диск». Воно не «прибирає корупцію». Воно навіть не гарантує, що пул залишиться здоровим наступні п’ять хвилин.
Уявіть ZFS як систему з двома шарами правди:
- Фізична реальність: що диски, HBA, експандери, кабелі, бекплейни і контролери фактично можуть доставити.
- Записане спостереження: що ZFS побачив (помилки, повторні спроби, невідповідності контрольних сум) і порахував.
zpool clear скидає записане спостереження. Воно нічого не робить з фізичною реальністю. Якщо фізична реальність ще зламана, ZFS просто почне рахувати знову — часто миттєво, іноді через секунди після скидання. Якщо ви очистили і лічильники залишаються нулевими під навантаженням, ймовірно, ви щось виправили і тепер статус пулу читабельний. Якщо ви очистили і лічильники миттєво поповнюються, ви щойно підтвердили живу проблему.
Також: очищення може перевести пул зі стану DEGRADED/FAULTED до ONLINE, якщо пристрій тепер доступний і несправність була перехідною. Це зручно. Але це також спосіб ненавмисно «довести», що хиткий шлях добрий, бо він пропрацював одну хвилину.
Роль лічильників помилок у роботі ZFS
ZFS використовує лічильники по vdev (READ, WRITE, CKSUM) і стейт‑машини (ONLINE, DEGRADED, UNAVAIL, FAULTED), щоб допомогти відповісти на два питання:
- Чи під ризиком дані прямо зараз?
- Якщо так — чи це проблема пристрою, шляху чи реально пошкоджені дані на диску?
Очищення лічильників — це гігієнічний крок після того, як ви відповіли на обидва питання й усунули причину. Це не перший крок.
Парафразована ідея, приписують: «Сподівання — не стратегія.»
— часто приписують практикам з культури reliability/ops (парафразована ідея).
Факти та контекст для «war room»
- ZFS створювали, щоб виявляти тиху корупцію — клас помилок і переворотів бітів, які ваш RAID‑контролер радо ігнорує, повертаючи «успіх». Тому невідповідності контрольних сум важливіші за страшний банер «degraded».
- End‑to‑end контрольні суми не були звичною функцією файлових систем на момент розробки ZFS на початку 2000‑х; ZFS популяризував ідею, що сховище повинно перевіряти те, що воно віддає, а не лише те, що зберігає.
- Концепція «scrub» навмисно проактивна: це запланована операція «прочитати все і перевірити», а не реактивний fsck після збою. Так ZFS знаходить погані сектори до того, як вони знадобляться.
- Лічильники READ/WRITE/CKSUM — по vdev і зберігаються через перезавантаження, доки їх не скинуть. Така стійкість корисна для виявлення трендів і небезпечна для тих, хто панікує через старі числа.
- Одна невідповідність контрольної суми не автоматично означає втрату даних у редундантних vdev (mirror/raidz). Часто ZFS виявляє погану копію й поправляє її з доброї — тихо вас рятуючи.
- Функції «fault management» ZFS були натхненні підходом serviceability: система намагається підказати, який компонент замінити, а не просто сказати «щось не так». Це добре, але вона не всезнаюча щодо кабелів і бекплейнів.
- Багато «помилок диска» насправді — проблеми транспорту: скидання лінків SATA/SAS, маргінальні експандери, нещільно посаджені диски, проблеми з живленням. ZFS не може сказати, що ваш кабель раптом зневірився.
- На стеку, похідному від Solaris, FMA (Fault Management Architecture) інтегрувалася з ZFS. На Linux екосистема інша (ZED, udev, журнали ядра), тому діагностика часто потребує кореляції джерел.
- Поява дешевих великих дисків зробила латентні помилки секторів реальною операційною проблемою. Scrub‑и та планування резервування стали обов’язковими, оскільки часи відновлення зросли і математика URE стала неприємною.
Як розуміти READ/WRITE/CKSUM дорослою мовою
zpool status показує вам три лічильники на пристрій:
- READ: пристрій повернув помилку I/O при читанні, відмовив або таймаутнув, або інакше не доставив блоки.
- WRITE: пристрій не зміг записати блоки (або підтвердити записи).
- CKSUM: пристрій повернув дані, але ZFS обчислив невідповідність контрольної суми — байти відрізняються від тих, що були записані спочатку.
На практиці:
- READ/WRITE помилки часто вказують на пристрій, який не може надійно виконувати I/O, або на проблему шляху (HBA, експандер, кабель, живлення). Зазвичай вони супроводжуються повідомленнями ядра. Вони можуть спричинити відключення vdev.
- CKSUM помилки — «тихо жахлива» категорія. Їх може спричинити помираючий диск, так. Але їх також може спричинити нестабільний транспорт, проблемна оперативна пам’ять (рідше з ECC, але можливо), дивна прошивка або контролери, що «допомагають» некоректно. ZFS каже: Я отримав байти, але я їм не довіряю.
Що потрібно розуміти з лічильників для дій
Ось поле‑гайд, який відповідає тому, що роблять досвідчені інженери на чергуванні, а не тому, що вони кажуть, що роблять:
- CKSUM на одному диску, невеликий лічильник, більше не зростає: ймовірно, перехідна або відновлена подія. Запустіть scrub, зіставте логи, потім очистіть, якщо ви усунули причину (пересадили диск, замінили кабель, оновили прошивку тощо).
- CKSUM зростає під час scrub або під навантаженням: активна проблема цілісності. Не очищуйте. Знайдіть компонент. Замініть речі, поки лічильник не перестане зростати.
- READ/WRITE помилки з скиданнями/таймаутами: трактуйте як нестабільність шляху/пристрою. ZFS може продовжувати обслуговувати, але ваш бюджет стійкості витрачається.
- Помилки на кількох дисках за одним HBA/експандером: не починайте масової заміни дисків. Так ви отримаєте «нові диски, ті самі помилки». Підозрюйте спільну інфраструктуру.
Коли очищення помилок доречне
zpool clear доречне, коли стан помилок застарілий, підлягаюча причина усунена, і вам потрібні чисті лічильники, щоб перевіряти стабільність далі.
Використовуйте його після виправлення чіткої причини
Хороші тригери:
- Ви замінили невдалий диск, resilver завершився, пул здоровий, але все ще показує старі лічильники. Очистіть, щоб скинути табло.
- Ви пересадили диск або замінили SATA/SAS кабель/слот бекплейну і хочете підтвердити, що помилки не повторюються під час scrub.
- Відбулася одноразова повітряна подія потужності (PDU hiccup, втрати живлення шасі), яка спричинила перехідні I/O помилки; після перевірки стабільності апаратури очистіть, щоб не жити з «історичною ганьбою».
- Ви виправили помилкову конфігурацію (неправильна прошивка, режим контролера, налаштування multipath) і хочете довести виправлення, спостерігаючи лічильники під навантаженням.
Використовуйте його, щоб зробити моніторинг адекватним
Багато систем моніторингу спрацьовують на ненульові лічильники помилок. Якщо ви зробили роботу — проскрабили, усунули причину, валідували — залишати старі лічильники тренує вашу організацію ігнорувати алерти. Очистка стає операційним скиданням: «від цього моменту нові помилки означають нові інциденти.»
Використовуйте його для конкретного пристрою під час ізоляції
Очищення всього пулу може стерти корисний криміналістичний контекст. Віддавайте перевагу:
zpool clear poolnameколи ви повністю закінчили й хочете все скинути.zpool clear poolname /dev/disk/by-id/...коли ви відстежуєте підозрілого актора і хочете свіжий лічильник для цього шляху.
Коли очищення помилок — дурість
Очищення помилок — дурість, коли ви не довели стабільність пулу, або коли ви використовуєте його, щоб заглушити симптоми замість того, щоб діагностувати причину.
Не очищуйте, поки помилки ще накопичуються
Якщо scrub виконується і CKSUM зростає, очищення — це як змінити одометр, поки двигун горить. Ви втратите можливість оцінити «наскільки погано» і «з якою швидкістю». Зберігайте числа. Вони — докази.
Не очищуйте, щоб «виправити» корупцію даних
Іноді zpool status повідомляє errors: Permanent errors have been detected. Це не проблема лічильників. Це ZFS каже, що воно знайшло блоки, які не змогло відновити з редундантності. Очищення не воскресить дані. Воно приховає попередження до наступного читання, яке вдарить дорожче — для вашого застосунку.
Не очищуйте, щоб зробити degraded пул зеленим
Пул у стані DEGRADED вже витрачає редундантність. Якщо ви очистите і оголосите перемогу без заміни несправного компонента, ви ставите на те, що решта vdev поводитиметься коректно. Така ставка популярна статистично і професійно жалюгідна.
Не очищуйте, поки не зберете контекст
Очищення стирає сліди. Перед очищенням зафіксуйте:
zpool status -vzpool events -v(якщо є)- Журнали ядра навколо часу появи помилок
smartctlдля постраждалих дисків
Перший жарт (короткий, доречний): Очищати помилки ZFS без діагностики — це як перезавантажити пожежний датчик. Ви не загасили пожежу; ви просто зробили її тихішою.
Швидкий плейбук діагностики
Коли ви на чергуванні, у вас немає розкоші філософських роздумів про сховище. Ось як швидко дійти до «що зламалося».
Перше: з’ясуйте, активна це чи історична подія
- Перевірте
zpool statusі помітте, чи лічильники збільшуються з часом. - Якщо scrub/resilver в процесі, дивіться, чи помилки ростуть під час цієї активності.
Друге: класифікуйте режим відмови (пристрій vs шлях vs дані)
- Якщо переважають READ/WRITE з таймаутами в логах → підозра на пристрій або транспорт.
- Якщо CKSUM без I/O помилок → підозра на пошкодження в дорозі (кабель/HBA/експандер/RAM) або диск, що повертає неправильні дані.
- Якщо з’являється
Permanent errors→ трактуйте як інцидент втрати даних, поки не доведено інше.
Третє: шукайте спільну зону ураження
- Чи помилки на кількох дисках на тому самому HBA/порті/експандері? Це спільний компонент.
- Чи помилки на одному диску лише? Зазвичай це диск, його слот або кабель.
Четверте: вирішіть, чи можете продовжувати обслуговувати
- Редундантний vdev, одиночні помилки пристрою, scrub успішно ремонтує: часто можна продовжувати обслуговувати та запланувати заміну.
- Нередундантний vdev або кілька пристроїв в одній RAIDZ групі дають збій: припиніть гратися в рулетку. Спершу стабілізуйте.
Практичні завдання: команди, виводи, рішення
Нижче реальні операційні завдання, які можна виконати. Кожне містить: команду, що означає вивід, і яке рішення прийняти.
Завдання 1: Отримати загальний статус (без прицілювання)
cr0x@server:~$ sudo zpool status
pool: tank
state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible. Otherwise restore the entire pool from backup.
scan: scrub repaired 0B in 02:41:13 with 0 errors on Tue Dec 24 03:12:01 2025
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-ABC123 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-GHI789 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-JKL012 UNAVAIL 8 2 0 cannot open
errors: Permanent errors have been detected in the following files:
tank/data/finance.dbЩо це означає: Це не «лише лічильники». У вас відсутній диск, і ZFS повідомляє про постійні помилки у конкретному файлі.
Рішення: Не запускайте zpool clear як перший крок. Стабілізуйте апарат (поверніть диск / замініть), потім опрацьовуйте пошкоджений файл (відновлення з репліки/резервної копії або відновлення на рівні застосунку).
Завдання 2: Отримати детальний вивід про помилки і файли
cr0x@server:~$ sudo zpool status -v tank
pool: tank
state: DEGRADED
scan: scrub repaired 0B in 02:41:13 with 0 errors on Tue Dec 24 03:12:01 2025
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-ABC123 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-GHI789 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-JKL012 UNAVAIL 8 2 0 cannot open
errors: Permanent errors have been detected in the following files:
tank/data/finance.dbЩо це означає: ZFS вказує на конкретний шлях у dataset. Це дієво.
Рішення: Залучіть власника застосунку. Визначте, чи можна відновити або перебудувати файл. Аппаратна і робота з даними мають іти паралельно.
Завдання 3: Підтвердити, що диск реально відсутній або був перейменований
cr0x@server:~$ ls -l /dev/disk/by-id/ | grep JKL012
Що це означає: Відсутність виводу свідчить, що ОС не бачить пристрій взагалі (відключено, мертвий, лінк впав, проблема контролера).
Рішення: Перевірте кабелі/бекплейн/HBA. Якщо це гаряча шасі, перемістіть диск у слот. Якщо це VM — перевірте приєднання віртуального диска.
Завдання 4: Зіставити з логами ядра (шлях vs медіа)
cr0x@server:~$ sudo dmesg -T | egrep -i "ata|sas|scsi|reset|timeout|I/O error" | tail -n 20
[Wed Dec 24 02:01:44 2025] ata9.00: exception Emask 0x0 SAct 0x0 SErr 0x4050000 action 0x6 frozen
[Wed Dec 24 02:01:44 2025] ata9: SError: { CommWake DevExch }
[Wed Dec 24 02:01:45 2025] ata9.00: failed command: READ FPDMA QUEUED
[Wed Dec 24 02:01:45 2025] blk_update_request: I/O error, dev sdi, sector 918273645 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Wed Dec 24 02:01:47 2025] ata9: hard resetting link
[Wed Dec 24 02:01:52 2025] ata9: link is slow to respond, please be patient (ready=0)
[Wed Dec 24 02:01:57 2025] ata9: SATA link down (SStatus 0 SControl 300)Що це означає: Скидання лінків і «link down» кричать «transport/path» більше ніж «поганий сектор». Диск може бути ще нормальний; шлях — ні.
Рішення: Інспектуйте/замініть кабель, порт бекплейну або лінію HBA. Не міняйте диск першим, якщо немає інших доказів.
Завдання 5: Отримати SMART, щоб побачити, чи хворий диск
cr0x@server:~$ sudo smartctl -a /dev/sdi | egrep -i "Reallocated|Pending|Uncorrect|CRC|SMART overall|Power_On_Hours" -n
5:SMART overall-health self-assessment test result: PASSED
83: 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
88:197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 0
89:198 Offline_Uncorrectable 0x0010 200 200 000 Old_age Offline - 0
102:199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 47
109: 9 Power_On_Hours 0x0032 094 094 000 Old_age Always - 46712Що це означає: Високі CRC‑помилки за відсутності realloc/pending секторів вказують на шум у кабелі/бекплейні/контролері. Медіа диска явно не виглядає поганою.
Рішення: Виправте шлях. Потім запустіть scrub. Потім розгляньте очищення лічильників.
Завдання 6: З’ясувати, в який фізичний відсік відображається by-id
cr0x@server:~$ sudo lsblk -o NAME,SERIAL,MODEL,HCTL,SIZE,STATE | grep -E "sdi|JKL012"
sdi WD-JKL012 WDC WD80EFAX-68LHPN0 3:0:9:0 7.3T runningЩо це означає: HCTL дає host:channel:target:lun, що корисно з SAS HBA і картографією шасі.
Рішення: Використовуйте HCTL і мапу шасі, щоб доторкнутись до правильного диска. Уникайте класичної помилки «витягнути не той диск».
Завдання 7: Підтвердити топологію пулу і ashift (прогноз майбутніх проблем)
cr0x@server:~$ sudo zpool get ashift,autoreplace,autotrim tank
NAME PROPERTY VALUE SOURCE
tank ashift 12 local
tank autoreplace off default
tank autotrim off defaultЩо це означає: ashift=12 — це 4K сектора; нормально. autoreplace=off означає, що заміна диска може вимагати явних дій. autotrim off типовий для HDD пулів.
Рішення: Якщо ви очікуєте hot‑swap поведінку, вирішіть, чи вмикати autoreplace після розуміння середовища. Не чіпайте це під час інциденту, якщо вам не подобаються сюрпризи.
Завдання 8: Запустити scrub і дивитись, чи лічильники збільшуються
cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ watch -n 10 sudo zpool status tank
Every 10.0s: sudo zpool status tank
pool: tank
state: ONLINE
scan: scrub in progress since Wed Dec 24 04:01:10 2025
1.23T scanned at 1.4G/s, 212G issued at 245M/s, 7.98T total
0B repaired, 2.59% done, 08:31:12 to go
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-ABC123 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-GHI789 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-JKL012 ONLINE 0 0 0
errors: No known data errorsЩо це означає: Scrub виконується, пул стабільний, помилки не зростають. Це хороший знак.
Рішення: Якщо це відбувається після усунення (пересеяння кабелю/заміни), ви наближаєтеся до «безпечного для очищення» після завершення scrub.
Завдання 9: Перевірити результат scrub і відновлені байти
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: scrub repaired 12M in 02:39:44 with 0 errors on Wed Dec 24 06:41:02 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 3
raidz1-0 ONLINE 0 0 3
ata-WDC_WD80EFAX-68LHPN0_WD-ABC123 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-GHI789 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-JKL012 ONLINE 0 0 3
errors: No known data errorsЩо це означає: Scrub відновив 12M (self‑heal), але диск все ще має помилки контрольної суми. Якщо ці помилки історичні і не зростають, можна очистити після впевненості, що причина виправлена.
Рішення: Зіставте з логами під час scrub. Якщо немає нових скидань/таймаутів і SMART CRC перестає зростати, очистіть і моніторьте.
Завдання 10: Очистити один пристрій (сургічна операція)
cr0x@server:~$ sudo zpool clear tank ata-WDC_WD80EFAX-68LHPN0_WD-JKL012
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: scrub repaired 12M in 02:39:44 with 0 errors on Wed Dec 24 06:41:02 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-ABC123 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-DEF456 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-GHI789 ONLINE 0 0 0
ata-WDC_WD80EFAX-68LHPN0_WD-JKL012 ONLINE 0 0 0
errors: No known data errorsЩо це означає: Лічильники скинуті. Тепер у вас чистий базовий рівень.
Рішення: Поставте пул під нормальне навантаження і перевірте через кілька годин/днів. Якщо лічильники з’являться знову, виправлення не витримало.
Завдання 11: Використати zpool events для перегляду останньої активності збоїв ZFS
cr0x@server:~$ sudo zpool events -v | tail -n 25
TIME CLASS
Dec 24 2025 02:01:58.219388000 ereport.fs.zfs.io
vdev_path: /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_WD-JKL012
vdev_guid: 1234567890123456789
pool: tank
pool_guid: 9876543210987654321
ereport_payload:
zio_err: 5
zio_offset: 469124961280
zio_size: 131072
zio_objset: 54
zio_object: 1
zio_level: 0Що це означає: ZFS залогував I/O ereport для цього vdev. Мітка часу допомагає зіставити з логами ядра і фізичними подіями.
Рішення: Якщо події припиняться після усунення — ви перемагаєте. Якщо триватимуть — ескалюйте ізоляцію апаратури.
Завдання 12: Підтвердити, що пул не тихо resilver‑иться або не застряг
cr0x@server:~$ sudo zpool status -D tank
pool: tank
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
ata-WDC...ABC123 ONLINE 0 0 0
ata-WDC...DEF456 ONLINE 0 0 0
ata-WDC...GHI789 ONLINE 0 0 0
ata-WDC...JKL012 ONLINE 0 0 0
errors: No known data errorsЩо це означає: Немає поточної перевірки, нічого не відтерміновано.
Рішення: Якщо ви чекали resilver і його немає — можливо, ви замінили не той пристрій або ZFS не приєднав новий диск, як ви очікували.
Завдання 13: Правильно замінити диск (і уникнути передчасного очищення)
cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80EFAX-68LHPN0_WD-JKL012 /dev/disk/by-id/ata-WDC_WD80EFAX-68LHPN0_WD-MNO345
cr0x@server:~$ sudo zpool status tank
pool: tank
state: DEGRADED
scan: resilver in progress since Wed Dec 24 07:10:04 2025
612G scanned at 1.1G/s, 118G issued at 211M/s, 7.98T total
118G resilvered, 1.44% done, 06:10:22 to go
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
ata-WDC...ABC123 ONLINE 0 0 0
ata-WDC...DEF456 ONLINE 0 0 0
ata-WDC...GHI789 ONLINE 0 0 0
replacing-3 DEGRADED 0 0 0
ata-WDC...JKL012 UNAVAIL 0 0 0 cannot open
ata-WDC...MNO345 ONLINE 0 0 0 (resilvering)Що це означає: Resilver активний; ZFS реконструює редундантність на новий диск.
Рішення: Не очищуйте під час resilver, якщо лише ви не очищуєте історичні помилки після вирішеної перехідної проблеми і при цьому зберегли докази. Дайте resilver завершитись; потім валідуйте scrub.
Завдання 14: Очистити весь пул після завершеної і валідуваної ремедіації
cr0x@server:~$ sudo zpool clear tank
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: resilvered 7.98T in 06:44:09 with 0 errors on Wed Dec 24 13:54:13 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
ata-WDC...ABC123 ONLINE 0 0 0
ata-WDC...DEF456 ONLINE 0 0 0
ata-WDC...GHI789 ONLINE 0 0 0
ata-WDC...MNO345 ONLINE 0 0 0
errors: No known data errorsЩо це означає: Чистий базовий рівень після успішної заміни/resilver.
Рішення: Встановіть нагадування перевірити SMART і zpool status через робочий день і після наступного запланованого scrub.
Три корпоративні міні‑історії з реального світу
Міні‑історія 1: Інцидент, спричинений неправильною тезою
Команда зберігання даних у середній компанії виконувала змішане навантаження на RAIDZ2 пулі: аналітичні читання, нічні компакти та кілька «тимчасових» dataset‑ів, що якось стали постійними. Одного ранку моніторинг почав пейджити через помилки контрольної суми на одному диску. Інженер на чергуванні побачив, що пул все ще ONLINE, і вирішив, що це старий шум. Він виконав zpool clear, щоб припинити спам алертів.
За кілька годин лічильник CKSUM повернувся — швидко. Але оскільки пейджинг було «опрацьовано», це не отримало належної уваги. Наступної ночі важке пакетне завдання підвищило навантаження, і другий диск у тому самому vdev почав видавати таймаути читання. Тепер пул перейшов у DEGRADED. Команда вирішила, що це «два погані диски» і почала стандартний процес заміни.
Що вони пропустили: обидва диски були підключені через той самий шлях експандера SAS, і прошивка експандера мала відому проблему з менеджментом живлення лінків. Початкові помилки CKSUM були раннім попередженням. Очищення стерло можливість показати, що помилки зростали, і скинуло тимчасову хронологію в нотатках чергування, бо ніхто не зняв zpool status -v та логи перш ніж очищувати.
Вони замінили один диск. Resilver повз, з періодичними скиданнями. Заміняли другий диск — без покращення. Потім третій диск почав помилятися, і усі зрозуміли: це не набір поганих дисків. Це спільна інфраструктура.
Фікс був нудний: відключити проблемну опцію управління живленням лінків, оновити прошивку експандера під вікно технічного обслуговування і переставити маргінальний mini‑SAS кабель. Після цього помилки припинилися. Вони знову очистили лічильники — тепер правильно — і спостерігали, що вони лишаються нульовими. Вартість була не лише в залізі; це була втрата довіри. Алрти сховища ігнорували тижнями, і так організації накопичують майбутні відмови як борг.
Міні‑історія 2: Оптимізація, яка відігралася
Інша організація хотіла прискорити scrubs. У них був великий пул і вузьке вікно обслуговування, тому хтось налаштував параметри scrub на системному рівні (точні регулятори відрізнялися по платформах) і запланував scrubs на бізнес‑години «бо масив швидкий». В тесті це працювало.
У production швидший scrub підвищив навантаження на читання на наборі застарілих дисків. Це вивело на поверхню маргінальний HBA та сумнівний трейс на бекплейні. Нічого катастрофічного — лише достатньо повторів і скидань лінків, щоб ZFS почав логувати помилки контрольної суми на кількох дисках. Пул залишився online, тому тікети знизили пріоритет до «спостерігати».
Потім команда зробила найгірше для своєї спостережливості: вони щотижня очищували помилки після кожного scrub, бо керівництву не подобалися червоні числа на дашбордах. При постійному скиданні лічильників стало неможливо показати тренд деградації середовища. Система раннього попередження перетворилася на косметичний фільтр.
Врешті важке записуюче навантаження збіглося зі scrub і глюком прошивки, спричинивши тимчасове відключення vdev. Пул відновився, але застосунок побачив транзієнтні помилки і почав відбудовувати індекси з нуля, що ще більше навантажило сховище. Інцидент не був одним вибухом; це була ланцюгова реакція, живлена «оптимізацією».
Постмортем дав чіткий урок: тюнінг продуктивності, що ховає сигнали надійності — це не оптимізація. Це борг. Вони відкочували агресивні налаштування scrub, перемістили scrubs у контрольовані вікна, відремонтували спільне залізо і лише після цього використали zpool clear для скидання базових рівнів. Продуктивність повернулася. Так само і їхня репутація.
Міні‑історія 3: Нудна, але правильна практика, що врятувала
Фінансова команда використовувала ZFS для внутрішніх сервісів, які не могли дозволити собі непередбачувані події. У них було правило: перед тим, як хтось запускає zpool clear, до тікета треба приєднати три артефакти — zpool status -v, релевантний фрагмент логів ядра і smartctl для будь‑яких задіяних дисків. Без винятків, без «швидкого фіксу».
Однієї вихідної, пул показав невелику кількість помилок CKSUM на одному диску. Система інакше поводилася нормально. Інженер на чергуванні дотримався ритуалу, зібрав докази і помітив тонку деталь: SMART показував збільшення CRC‑помилок, але realloc/pending сектори були нульовими. Журнали ядра показували скидання лінка на конкретному порту.
Замість заміни диска вони пересадили диск в інший відсік і поміняли кабель до бекплейна. Після цього запустили scrub; нових помилок не з’явилося. Тільки тоді вони очистили лічильники пристрою. Моніторинг мовчав місяцями.
Що їх врятувало — не геній. Це було відмовляння дозволяти «очистити помилки» замінювати діагностику. Ритуал створив достатньо даних, щоб один раз вибрати правильний компонент у спокійному вікні обслуговування, без марафону resilver і без ризику другої відмови під час відновлення.
Типові помилки: симптом → причина → виправлення
Помилка 1: «Пул ONLINE, отже помилки CKSUM не важливі.»
Симптом: Пул показує ONLINE, але на одному диску ростуть CKSUM помилки.
Причина: Редундантність маскує корупцію; ZFS читає і ремонтує, але щось повертає неправильні дані (диск або шлях).
Виправлення: Зіставте з dmesg та SMART; перевірте на наявність CRC помилок і скидань лінків. Поміняйте кабель/порт або диск, якщо SMART вказує на пошкодження медіа. Запустіть scrub для валідації. Очищайте тільки після того, як лічильник перестане зростати.
Помилка 2: Очищення помилок, щоб заглушити моніторинг
Симптом: Алерти припиняються після zpool clear, потім повертаються пізніше, часто гіршими.
Причина: Моніторинг був правий; ви видалили докази і відклали діагностику.
Виправлення: Зберігайте лічильники, поки не усунете корінь проблеми. Якщо реально є fatigue алертів, налаштуйте моніторинг на «швидкість зростання», «активні degraded/faulted стани» і «scrub помилки», а не просто на ненульові історичні лічильники.
Помилка 3: Заміна дисків, коли справжня проблема — HBA/експандер
Симптом: Кілька дисків показують помилки, часто у різних vdev, і заміна не допомагає.
Причина: Відмова спільного компонента: перегрів HBA, баги прошивки експандера, поганий бекплейн, перепади живлення.
Виправлення: Замапте пристрої на HBA/порти (HCTL), перевірте логи на загальні патерни скидань і ізолюйте, перемістивши один проблемний диск на інший контролер, якщо можливо. Замініть/відремонтуйте спільний компонент.
Помилка 4: Трактувати «Permanent errors» як проблему лічильників
Симптом: zpool status перераховує конкретні файли з permanent errors.
Причина: ZFS не змогло самостійно відновити ці блоки (недостатня редундантність, множинні відмови або корупція протрималась у всіх репліках).
Виправлення: Відновіть уражені файли з бекапу/репліки або перебудуйте на рівні застосунку. Визначте й усуньте апаратну/транспортну проблему, що спричинила корупцію. Очищення лічильників не відновить файл.
Помилка 5: Очищення до збирання доказів
Симптом: «Було вчора, але не можемо відтворити.»
Причина: Лічильники/події/логи були перезаписані або очищені, зруйнувавши кореляцію.
Виправлення: Захоплюйте zpool status -v, zpool events -v і часовий фрагмент логів перед будь‑якою деструктивною гігієною. Стандартизуйте це в runbook.
Помилка 6: Плутати scrub з resilver і робити неправильний вибір
Симптом: Команда запускає scrubs, очікуючи відновлення редундантності після заміни, або замінює диски, коли потрібен scrub.
Причина: Scrub перевіряє і ремонтує; resilver реконструює на замінений/новий пристрій. Різні цілі — різні сигнали.
Виправлення: Якщо пристрій був замінений/перепідключений, підтвердіть, що відбувається resilver. Після resilver запустіть scrub для валідації. Очищайте помилки після валідації.
Чеклісти / покроковий план
Чекліст A: «Чи можу я зараз виконати zpool clear?»
- Чи зафіксували ви
zpool status -vу тікеті? - Чи журнали ядра пояснюють останні релевантні I/O помилки/скидання?
- Чи пул
ONLINEбез відсутніх пристроїв? - Чи завершився scrub після виправлення з
0 errors? - Чи індикатори SMART стабільні (CRC не росте, немає зростання pending/reallocated)?
- Чи лічильники помилок не зростають під навантаженням?
Якщо ви не можете ствердно відповісти на більшість із цих — не очищуйте. Якщо можете — очищайте хірургічно (по пристрою), а потім моніторьте.
Чекліст B: Покрокова реакція на інцидент, коли zpool status показує помилки
- Стабілізувати: підтвердьте стан пулу, редундантність і чи якийсь vdev offline/unavail.
- Зберегти докази: збережіть
zpool status -v,zpool events -v, логи, SMART. - Класифікувати: READ/WRITE vs CKSUM vs permanent errors.
- Окреслити обсяг: один диск vs кілька дисків vs шаблон спільного компонента.
- Пом’якшити: пересадити/замінити кабель/порт; замінювати диск тільки коли показання вказують на це.
- Валідувати: resilver (якщо потрібно), потім scrub.
- Скинути базу: очищайте помилки тільки після валідації.
- Моніторити: перевірте статус через 1 годину, 24 години і після наступного scrub; стежте за дельтами SMART.
Чекліст C: Постфікс‑верифікація (те, що люди пропускають)
- Запустіть scrub (або заплануйте негайно, якщо пул великий і потребує вікна).
- Підтвердьте, що під час scrub не з’являються нові помилки.
- Підтвердьте, що лічильники залишаються стабільними при принаймні одному циклі нормального навантаження.
- Лише потім скиньте лічильники помилок і закрийте інцидент.
Другий жарт (короткий, доречний): Найшвидший спосіб зробити zpool status здоровим — це zpool clear. Другий за швидкістю — виправити проблему.
FAQ
1) Чи виправляє zpool clear корупцію?
Ні. Воно скидає записані лічильники помилок і може зняти деякі стани несправності. Корупцію виправляють редундантні ремонти під час читань/scrub, resilver або відновлення даних з бекапу.
2) Якщо я очищу помилки, чи можу я втратити дані?
Саме очищення не видаляє дані, але воно може призвести до пропуску розвиваючоїся відмови, бо ви прибрали докази. Втрата даних може статися пізніше, якщо ви не встигнете замінити поганий компонент вчасно.
3) Коли очищати: до чи після scrub?
Після. Scrub — це ваше підтвердження, що пул може прочитати і перевірити дані наскрізь. Очищення перед scrub стирає базу для порівняння.
4) Мій пул показує помилки контрольних сум, але «No known data errors.» Це нормально?
Може бути нормально, якщо помилки історичні і не зростають — ZFS міг їх відремонтувати. Ненормально, якщо лічильник контрольної суми росте, особливо під час scrub або під сильним навантаженням.
5) Чому помилки контрольної суми часто вказують на кабелі та HBA?
Тому що диск може повернути байти, які були пошкоджені в дорозі або через ненадійний шлях контролера. Лічильник SMART CRC та логи ядра про скидання лінків — типовий підказувач.
6) Чи можу я очистити лише помилки одного диска?
Так, і часто варто. Використовуйте zpool clear poolname vdev, щоб скинути лічильники на підозрілому пристрої, зберігаючи контекст по всьому пулу.
7) Що робити, якщо помилки повертаються одразу після очищення?
Це подарунок: означає, що у вас активна проблема. Перестаньте очищувати. Зіставте з логами і SMART, і ізолюйте, чи це диск чи шлях/спільне залізо.
8) Чи безпечно очищати помилки на degraded пулі?
Зазвичай ні, як «фікс». Якщо пул degraded через відсутній пристрій, очищення не відновить редундантність. Єдиний безпечний випадок — після відновлення доступності пристрою і підтвердження стабільності.
9) Як вирішити: замінити диск чи поміняти кабель?
Якщо SMART показує зростання realloc/pending/uncorrectables — міняйте диск. Якщо SMART показує CRC‑помилки і логи показують скидання лінків — пріоритет за кабелем/портом/HBA. Якщо не впевнені — спочатку міняйте шлях; це низькоризикова і швидка дія.
10) Чи впливає очищення помилок на майбутню діагностику?
Так. Ви втрачаєте історичні лічильники, що допомагають показати тренд. Тому знімайте докази спочатку і очищайте лише після того, як виправили і валідували.
Наступні кроки, які можна зробити сьогодні
Якщо ви експлуатуєте ZFS у production — перестаньте трактувати zpool clear як ритуал і почніть розглядати його як контрольоване скидання доказів.
- Додайте правило в runbook: заборона на очищення до приєднання
zpool status -v, релевантних логів і SMART‑виводу до тікета. - Навчіть моніторинг реагувати на зміну, а не на сором: алертуйте на зростання лічильників, degraded/faulted стани, помилки scrub і повторні відключення пристроїв.
- Плануйте scrubs по‑дорослому: регулярно, щоб знаходити латентні проблеми, але контрольовано, щоб не створювати ваше пікове навантаження.
- Практикуйте хірургічні очищення: очищайте окремий vdev під час ізоляції. Очищайте весь пул, коли інцидент справді закритий і валідація пройдена.
- Проведіть один tabletop‑випадок: симулюйте помилки CKSUM на одному диску і пройдіть плейбук без спокуси «швидко виконати
zpool clear».
Коли ви очищуєте — робіть це з причиною, базовим рівнем і планом спостереження за наслідками. Це не забобони. Це операції.