Resilver та Scrub у ZFS: перестаньте їх плутати

The mental model: verification vs reconstruction

Уявіть пул ZFS як дві задачі, що виконуються з часом:
довести, що дані коректні та відновити цілісність надлишковості.
Scrub — перша задача. Resilver — друга.

Scrub — це повний аудит цілісності. ZFS обходить виділені блоки, читає їх, перевіряє контрольні суми,
і якщо існує надлишковість (mirror, RAIDZ), намагається виправити погані копії, перезаписуючи їх правильною версією.
Scrub стосується коректності по всьому тому, що ви зберегли.

Resilver — це реконструкція, спрямована на пристрій, який має стати коректним членом vdev знову:
після заміни диска, після подій offline/online, після транзитного відключення або після видалення та повторного додавання пристрою.
Resilver відновлює надлишковість для цього одного пристрою (або його частини), а не проводить аудит усього простору.

Ось фраза, яка запобігає інцидентам: Scrub доводить ваші дані; resilver відновлює вашу надлишковість.
Обидва процеси можуть виявляти помилки і можуть виправляти їх. Але їхні наміри й охоплення різні.

Точні визначення (і чого вони не є)

Scrub: a checksum-driven audit of allocated data

Scrub читає виділені блоки в пулі. Не вільний простір. Не «сирий диск». Самі живі дані та метадані.
Кожен блок перевіряється за контрольною сумою. Якщо блок пошкоджено, ZFS намагається взяти правильну копію з надлишковості і відновити її.
Якщо ZFS не знаходить коректної копії, ви отримуєте постійну помилку: контрольна сума не співпала і не було джерела для відновлення.

Чого scrub не є:

• Не перевірка поверхні диска (це ближче до діагностики вендора або SMART long tests).
• Не «оптимізація продуктивності». Якщо після scrub стало швидше — значить щось було не так.
• Не заміна бекапів. Він може виявити корупцію; не може створити відсутні дані з повітря.

Resilver: bringing a device back into correct membership

Resilver копіює (або реконструює) дані, необхідні, щоб пристрій знову став коректним членом vdev:
у mirror це означає копіювання блоків з робочого диска на новий/повернений диск.
У RAIDZ це означає реконструкцію за допомогою паритету, щоб заповнити новий/повернений диск.

Сучасні реалізації ZFS роблять послідовний resilver і відстежують dirty time logs / resilver checkpoints,
тому resilver зазвичай фокусується на фактично виділених даних, а не на «всьому диску». Це добре.
Саме тому іноді недооцінюють навантаження resilver: воно менше, ніж повне відновлення диска, але все одно важке
й чутливе до затримок чит+запис.

Чого resilver не є:

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

Цитата, яку операційні люди вчать на практиці:
Hope is not a strategy.
— перефразована ідея, часто в SRE-кругах (іноді пов’язується зі словами Gordon R. Sullivan)

Що запускає scrub, що запускає resilver

Якщо ви не можете відповісти «чому зараз відбувається сканування?», ви не контролюєте систему. ZFS робитиме те, що ви наказали,
і також те, що має зробити.

Scrub triggers

• Ви його запускаєте: zpool scrub pool.
• Його запускає ваш планувальник: cron, systemd timer або інтерфейс NAS.
• Деякі пристрої запускають його автоматично після оновлень або певних технічних робіт.

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

Resilver triggers

• Заміна диска: zpool replace.
• Повернення пристрою: транзитний збій кабелю або HBA і диск повернувся в систему.
• Онлайн після offline: zpool offline потім zpool online або перезавантаження.
• Attach у mirror: zpool attach, щоб перетворити один диск у mirror.

Resilver — це подія доступності. Змінено набір пристроїв, що формують надлишковість, і ZFS відновлює контракт надлишковості.

Жарт №1: Scrub — це як інвентаризація; resilver — як поповнення після того, як вкрали палету. Плутати їх — те саме, що перевпорядковувати скріпки під час пожежі.

Що читається, що записується, і чому зникають IOPS

Scrub I/O profile

Scrub читає кожен виділений блок і перевіряє його. Це означає:

• Переважають читання, часто стрімінгові, але не ідеально послідовні (обхід метаданих стрибає).
• Записи відбуваються лише при необхідності ремонту (або при перезаписі метаданих унаслідок виявлення/ремонту).
• У найгіршому випадку — випадкові читання проявляються на фрагментованих пулах або завантажених датасетах з багатьма дрібними блоками.

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

Resilver I/O profile

Resilver за визначенням — читання + запис: потрібно заповнити один пристрій коректними даними. Залежно від топології:

• Mirror resilver: читає з робочого диска(ів), пише на новий/повернений диск.
• RAIDZ resilver: читає з усіх залишкових дисків (щоб реконструювати), пише на цільовий диск.
• Спеціальні vdev (метадані/дрібні блоки) можуть зробити resilver несподівано «піковим».

Resilver конкурує з вашим продукційним навантаженням за IOPS і пропускну здатність. Якщо пул деградований, resilver також конкурує з тим, що «кожне звичайне читання тепер має менше надлишковості», що підвищує вартість обробки помилок.

The operational implication

Scrub — це запланований біль; resilver — незапланований біль. Плануйте перший, щоб другий не став катастрофою.
Якщо ви resilver-ите, налаштування продуктивності другорядне порівняно з безпекою даних. Ваше завдання — завершити resilver, не втративши ще один диск.

Як читати zpool status як слід

zpool status — тут живе реальність. Воно показує, чи ви scrub-ите або resilver-ите, на якій стадії,
і чи виявляються або виправляються помилки.

Ключові поля, що мають значення під час інцидентів

• state: ONLINE / DEGRADED / FAULTED / UNAVAIL. Це визначає терміновість ваших дій.
• scan: scrub in progress, resilver in progress, scrub repaired X, resilvered X, та швидкість/ETA.
• errors: «No known data errors» — не триумф, але хороший знак.
• READ/WRITE/CKSUM колонки по пристроях: показують, чи пристрій бреше, падає чи його виганяють.

Якщо взяти нічого більше: рядок «scan» каже, який процес запущено. Припиніть гадати.

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

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

Task 1: Confirm whether it’s a scrub or resilver

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.
action: Wait for the resilver to complete.
  scan: resilver in progress since Thu Dec 26 00:41:11 2025
        1.23T scanned at 612M/s, 742G issued at 369M/s, 5.41T total
        742G resilvered, 13.40% done, 03:46:12 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz2-0                  DEGRADED     0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
            sdc                     ONLINE       0     0     0
            sdd                     ONLINE       0     0     0
            sde                     ONLINE       0     0     0
            sdf                     ONLINE       0     0     0
            sdg                     ONLINE       0     0     0
            sdh                     ONLINE       0     0     0
            sdi                     ONLINE       0     0     0
            sdj                     ONLINE       0     0     0
            sdk                     ONLINE       0     0     0
            sdl                     ONLINE       0     0     0
            sdm                     ONLINE       0     0     0
            sdn                     ONLINE       0     0     0
            sdo                     ONLINE       0     0     0
            sdp                     ONLINE       0     0     0
            sdq                     ONLINE       0     0     0
            sdr                     ONLINE       0     0     0
            sds                     ONLINE       0     0     0
            sdt                     ONLINE       0     0     0
            sdu                     ONLINE       0     0     0
            sdv                     ONLINE       0     0     0
            sdw                     ONLINE       0     0     0
            sdx                     ONLINE       0     0     0
            sdy                     ONLINE       0     0     0
            sdz                     ONLINE       0     0     0
            sdaa                    ONLINE       0     0     0
            sdab                    ONLINE       0     0     0
            sdac                    ONLINE       0     0     0
            sdad                    ONLINE       0     0     0
            sdae                    ONLINE       0     0     0
            sdaf                    ONLINE       0     0     0
            sdag                    ONLINE       0     0     0
            sdah                    ONLINE       0     0     0
            sdai                    ONLINE       0     0     0
            sdaj                    ONLINE       0     0     0
            sdak                    ONLINE       0     0     0
            sdal                    ONLINE       0     0     0
            sdam                    ONLINE       0     0     0
            sdan                    ONLINE       0     0     0
            sdao                    ONLINE       0     0     0
            sdap                    ONLINE       0     0     0
            sdaq                    ONLINE       0     0     0
            sdar                    ONLINE       0     0     0
            sdas                    ONLINE       0     0     0
            sdat                    ONLINE       0     0     0
            sdau                    ONLINE       0     0     0
            sdav                    ONLINE       0     0     0
            sdaw                    ONLINE       0     0     0
            sdax                    ONLINE       0     0     0
            sday                    ONLINE       0     0     0
            sdaz                    ONLINE       0     0     0
            sdba                    ONLINE       0     0     0
            sdbb                    ONLINE       0     0     0
            sdbc                    ONLINE       0     0     0
            sdbd                    ONLINE       0     0     0
            sdbe                    ONLINE       0     0     0
            sdbf                    ONLINE       0     0     0
            sdbg                    ONLINE       0     0     0
            sdbh                    ONLINE       0     0     0
            sdbi                    ONLINE       0     0     0
            sdbj                    ONLINE       0     0     0
            sdbk                    ONLINE       0     0     0
            sdbl                    ONLINE       0     0     0
            sdbm                    ONLINE       0     0     0
            sdbn                    ONLINE       0     0     0
            sdbo                    ONLINE       0     0     0
            sdbp                    ONLINE       0     0     0
            sdbq                    ONLINE       0     0     0
            sdbr                    ONLINE       0     0     0
            sdbs                    ONLINE       0     0     0
            sdbt                    ONLINE       0     0     0
            sdbu                    ONLINE       0     0     0
            sdbv                    ONLINE       0     0     0
            sdbw                    ONLINE       0     0     0
            sdbx                    ONLINE       0     0     0
            sdby                    ONLINE       0     0     0
            sdbz                    ONLINE       0     0     0

errors: No known data errors

Значення: Це resilver, не scrub («scan: resilver in progress»). Пул DEGRADED, але не фатально.

Рішення: Не запускайте scrub «щоб допомогти». Дозвольте resilver завершитися, якщо тільки у вас немає доказів тихої корупції, яку потрібно одразу аудіювати (рідко під час активного resilver).

Task 2: Start a scrub on purpose (and only on purpose)

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Thu Dec 26 01:12:03 2025
        388G scanned at 1.05G/s, 122G issued at 331M/s, 5.41T total
        0B repaired, 2.20% done, 04:41:09 to go
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0

errors: No known data errors

Значення: Scrub запущено; «0B repaired» поки що добре. Рядок «issued» показує фактичний I/O, іноді менший за «scanned».

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

Task 3: Stop a scrub (because you like your latency)

cr0x@server:~$ sudo zpool scrub -s tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub canceled on Thu Dec 26 01:24:55 2025
        512G scanned at 1.02G/s, 0B repaired, 9.24% done
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0

errors: No known data errors

Значення: Scrub зупинено. Ви не «зламали» пул; ви просто скасували аудит.

Рішення: Переплануйте scrub у вікно, де він не конкуруватиме з піковим I/O. Не ігноруйте його шість місяців тільки тому, що скасування було приємним.

Task 4: Identify which device is being resilvered (and why)

cr0x@server:~$ sudo zpool status -P tank
  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.
  scan: resilver in progress since Thu Dec 26 00:41:11 2025
        742G resilvered, 13.40% done, 03:46:12 to go
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            DEGRADED     0     0     0
          mirror-0                                      DEGRADED     0     0     0
            /dev/disk/by-id/ata-WDC_WD80EFAX_A1A...     ONLINE       0     0     0
            /dev/disk/by-id/ata-WDC_WD80EFAX_B2B...     ONLINE       0     0     0  (resilvering)

Значення: Тег «(resilvering)» показує ціль. -P показує постійні шляхи, а не крихкі імена /dev/sdX.

Рішення: Перед тим як витягати щось з шасі, перевірте, що фізичний диск відповідає by-id шляху. Це запобігає фатальним «замінили не той диск» інцидентам.

Task 5: Replace a failed disk correctly

cr0x@server:~$ sudo zpool replace tank /dev/disk/by-id/ata-WDC_WD80EFAX_B2B... /dev/disk/by-id/ata-WDC_WD80EFAX_NEW...
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Thu Dec 26 02:03:22 2025
        96.4G scanned at 485M/s, 62.1G issued at 313M/s, 5.41T total
        62.1G resilvered, 1.15% done, 05:02:10 to go

Значення: Ініційовано заміну; почався resilver. «Issued» показує фактичну роботу реконструкції.

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

Task 6: Spot silent corruption versus device errors

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 06:11:44 with 0 errors on Thu Dec 26 08:02:13 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda     ONLINE       0     0     2
            sdb     ONLINE       0     0     0

errors: No known data errors

Значення: Пристрій sda має помилки контрольної суми. Scrub нічого не відновив, але ZFS спостерігав погані дані з цього пристрою і виправив їх з надлишковості.

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

Task 7: Correlate ZFS errors with kernel logs

cr0x@server:~$ sudo dmesg -T | tail -n 20
[Thu Dec 26 03:11:19 2025] sd 2:0:8:0: [sda] tag#231 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Thu Dec 26 03:11:19 2025] sd 2:0:8:0: [sda] Sense Key : Medium Error [current]
[Thu Dec 26 03:11:19 2025] sd 2:0:8:0: [sda] Add. Sense: Unrecovered read error
[Thu Dec 26 03:11:19 2025] blk_update_request: I/O error, dev sda, sector 2384812048
[Thu Dec 26 03:11:21 2025] ata3: hard resetting link

Значення: Це не «ZFS бурчить». Ядро повідомляє реальні помилки читання і скидання лінка.

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

Task 8: Check SMART quickly (triage)

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i 'Reallocated|Pending|Offline_Uncorrectable|UDMA_CRC|SMART overall'
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   098   098   010    Pre-fail  Always       -       12
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       4
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       4
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       87

Значення: «PASSED» не означає виправдання. Pending/uncorrectable сектори — погано; високе число CRC помилок кричить про проблеми з кабелем/шляхом.

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

Task 9: Find the pool’s ashift and topology (sets expectations)

cr0x@server:~$ sudo zdb -C tank | egrep 'ashift|vdev_tree|type'
        ashift: 12
        type: 'root'
            type: 'mirror'
            type: 'disk'
            type: 'disk'

Значення: ashift: 12 означає 4K сектори. Неправильний вибір ashift може карати за випадковий I/O і робити scrub/resilver повільнішими, ніж потрібно.

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

Task 10: Check whether autotrim is affecting scan performance

cr0x@server:~$ sudo zpool get autotrim tank
NAME  PROPERTY  VALUE     SOURCE
tank  autotrim  on        local

Значення: Autotrim може додавати фонову роботу на SSD пулах. Зазвичай це нормально, але іноді — фактор «чому все зараз повільно».

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

Task 11: Observe real-time I/O while scrub/resilver runs

cr0x@server:~$ sudo iostat -x 2 5
Linux 6.8.0 (server)  12/26/2025  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.1    0.0    2.8     18.6     0.0    75.5

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
sda             415.2    18.1  54032    6120     252.1     9.84   23.5    22.9     37.2    1.9   82.4
sdb             402.7    17.5  52810    5904     251.6     9.21   22.1    21.6     35.8    1.8   79.3

Значення: Високе %util і черга (avgqu-sz) з підвищеним await вказують, що диски насичені. Це розтягне ваше сканування і вдарить по затримкам додатків.

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

Task 12: Identify whether ARC pressure is making everything worse

cr0x@server:~$ sudo arcstat 2 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  size     c  avail
01:33:20  328K  112K     34  28K   25   72K   64   12K   11   92G  104G   18G
01:33:22  341K  126K     36  31K   25   83K   66   12K   10   92G  104G   18G
01:33:24  355K  149K     42  45K   30   96K   64    8K    5   92G  104G   18G

Значення: Зростання miss rate під час скану свідчить, що скан витісняє корисний кеш, особливо на завантажених системах.

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

Task 13: Verify last scrub time and whether you’re overdue

cr0x@server:~$ sudo zpool status tank | grep -E 'scan:|scrub'
  scan: scrub repaired 0B in 06:11:44 with 0 errors on Thu Dec 26 08:02:13 2025

Значення: У вас є базова лінія: тривалість і результат.

Рішення: Якщо ви не бачите недавнього рядка «scrub repaired … with … errors» в історії — ви літаєте в сліпу. Впровадьте розклад і алертинг.

Task 14: Check if a resilver is restarting or not making progress

cr0x@server:~$ sudo zpool status tank | sed -n '1,25p'
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Thu Dec 26 00:41:11 2025
        1.23T scanned at 612M/s, 742G issued at 369M/s, 5.41T total
        742G resilvered, 13.40% done, 03:46:12 to go

Значення: «Scanned» зростає, а «issued» стоїть на місці — це може означати, що скан обходить метадані, але не надсилає корисного I/O — іноді через контенцію або помилки.

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

Task 15: Confirm pool health after completion

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: resilvered 5.41T in 06:02:18 with 0 errors on Thu Dec 26 06:43:29 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0

errors: No known data errors

Значення: Resilver завершився з 0 помилок і пул ONLINE.

Рішення: Тепер заплануйте scrub (незабаром), якщо ви давно його не робили, бо завершення resilver не гарантує відсутності латентної корупції в інших місцях.

Швидкий план діагностики (знайдіть вузьке місце швидко)

Коли scrub/resilver повільний, команди годинами сперечаються про «накладні витрати ZFS». Не робіть цього.
Знайдіть вузьке місце. Майже завжди це одне з: пристрій, контролер/шлях, контенція навантажень,
recordsize/шаблони дрібних блоків або тиск пам’яті системи.

Перший крок: з’ясуйте, що саме виконується і що означає «повільно»

1. Перевірте тип і прогрес скану:
   запустіть zpool status. Зафіксуйте scanned/issued rate, ETA і чи з’являються помилки.
   Якщо ETA росте — це не просто повільно; це нестабільно.
2. Перевірте стан пулу:
   ONLINE проти DEGRADED змінює пріоритети. Якщо DEGRADED, завершення resilver — пріоритет номер один.

Другий крок: знайдіть обмежувальний шар (диск vs шлях vs CPU vs кеш)

1. Насичення диска: iostat -x. Шукайте високе %util, високе await, великі черги.
   Якщо один диск має значно гіршу латентність за інших — він винуватець.
2. Помилки ядра: dmesg -T. Скидання лінків, тайм-аути, «Medium Error», «I/O error» — це тверді докази.
   Виправте проблеми шляху перед тим, як налаштовувати ZFS.
3. Тиск ARC: arcstat або еквівалент платформи.
   Якщо скан витісняє гарячі дані, застосунки постраждають і можуть посилити I/O.
4. Ботлнек CPU (рідше, але буває при сильному навантаженні контрольними сумами):
   перевірте завантаження CPU і чи діє компресія/шифрування. Scrub перевіряє контрольні суми; це навантаження на обчислення.

Третій крок: вирішіть режим роботи

• Режим безпеки перш за все (degraded, недавні помилки диска, невпевнене обладнання):
  мінімізуйте додаткову роботу, не запускайте нові scrubs, зменшіть пікові записи додатків і уникайте перезавантажень.
• Режим продуктивності (здоровий пул, плановий scrub):
  плануйте, обмежуйте і тримайте прогнозованість. Мета — «завершити непомітно», а не «виграти бенчмарк».

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

Mistake 1: “Scrub will rebuild the missing disk”

Симптоми: Пул DEGRADED. Хтось запускає scrub. Нічого не виправляється. DEGRADED залишається.

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

Виправлення: Заміна/онлайн/прикріплення пристрою, щоб ініціювати resilver. Використайте zpool replace або zpool online відповідно. Потім спостерігайте за resilver.

Mistake 2: “Resilver finished, so data is verified”

Симптоми: Після заміни диска команда розслабилася. Через тижні читання файлу кидає помилки контрольних сум або додаток повідомляє про корупцію.

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

Виправлення: Плануйте регулярні scrubs. Після значних подій (збої дисків, скиди контролера) виконайте scrub у наступне безпечне вікно.

Mistake 3: Canceling scrubs forever because “they hurt performance”

Симптоми: Scrub-и постійно скасовують. Згодом другий диск відмовляє під час rebuild і латентні помилки виявляються в найгірший момент.

Причина: Scrub — механізм, що виявляє латентні сектора помилок, поки ще є надлишковість для їх виправлення.

Виправлення: Запускайте scrubs у передбачуваному циклі. Якщо вплив неприйнятний — налаштуйте графік, додайте запас I/O або змініть дизайн пулу.

Mistake 4: Treating checksum errors as “just ZFS being dramatic”

Симптоми: CKSUM лічильники ростуть на одному пристрої. Пул залишається ONLINE. Люди ігнорують.

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

Виправлення: Перевірте кабелі/HBA, потім SMART, і замініть пристрій, якщо помилки не зникають. Також запустіть scrub, щоб примусово перевірити і вилікувати.

Mistake 5: Optimizing scan speed by starving applications (or the reverse)

Симптоми: Ви так обмежуєте scrubs, що вони йдуть днями, або знімаєте обмеження так сильно, що продукція падає.

Причина: Сканування — фонова I/O робота, яку треба балансувати з потребами латентності переднього плану.

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

Mistake 6: Replacing the wrong disk because /dev/sdX changed

Симптоми: Після перезавантаження ім’я «failed» диска змінилося. Технік виймає не ту полку. Тепер DEGRADED двічі.

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

Виправлення: Використовуйте /dev/disk/by-id шляхи в ZFS та операційних документах. Перед фізичною дією перевіряйте за zpool status -P.

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

Mini-story #1: The incident caused by a wrong assumption

Середня SaaS-компанія запускала ZFS на парі дзеркалованих HDD на вузол. Нічого надзвичайного. Вихід диска стався в тихий вікенд.
Інженер on-call побачив «DEGRADED» і зробив, як вважав безпечним і консервативним: запустив scrub.

Припущення було просте: scrub = «ремонт». І ZFS дійсно ремонтує під час scrub — коли є надлишковість. Але відсутній диск все ще був відсутній.
Scrub сумлінно обійшов залишковий диск, перевірив що міг і примусив купу читань. Тим часом пул не мав надлишковості.

Залишковий диск не витримав тривалого навантаження як єдине джерело істини. Виявилися латентні секторні помилки.
Декілька блоків не можна було прочитати правильно. Без mirror-партнера ZFS не могла їх вилікувати. Тепер пул мав реальні помилки даних, а не просто «деградовану надлишковість».

Вони замінили диск у понеділок і resilver завершився. Надлишковість повернулася, але пошкоджені блоки залишились — бо єдиної доброї копії ніколи не було.
Наслідки не були повним втратою даних, але були болісні: кілька пошкоджених об’єктів у blob-сторі додатку, виявлені клієнтами.

Постмортем-висновок був нудний: трактувати «degraded» як «мінімізуйте додаткове навантаження», пріоритезувати відновлення надлишковості (resilver),
і виконати scrub після resilver у вікні. Також: додати в рукопис операцій «scrub is not a rebuild» великими літерами.

Mini-story #2: The optimization that backfired

Фінансова компанія мала RAIDZ2 пули для даного сховища. Scrub-и були болісні, тому інженер вирішив «оптимізувати»: запускати scrubs постійно на низькій інтенсивності
і скасовувати їх у робочий час. Ідея була в тому, щоб постійно робити прогрес і залишатись непомітними.

Насправді scrubs ніколи не завершувалися. Вони працювали кілька годин, скасовувались, перезапускались пізніше, знову скасовувались. Тижні пройшли без завершеного scrub-а.
Всі відчували себе краще, бо історія команд показувала «scrub started» часто. Керівництво любить активність.

Потім один диск відмовив. Resilver стартував і виявився повільнішим, ніж очікували, бо один із залишкових дисків мав зростаючу кількість непрочитуваних секторів.
Непрочитувані сектори були присутні давно, але постійна стратегія «дрібних scrubs» ніколи не завершувала повний прохід, що міг би виявити проблему раніше.

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

Виправлення не було «менше scrub-ів». Було «робіть scrub правильно»: плануйте вікно, де він завершиться, ставте алерти на завершення та помилки, і фіксуйте базовий час виконання.
Їхня «оптимізація» була активністю без результату — корпоративний аналог бігу на місці.

Mini-story #3: The boring but correct practice that saved the day

Медіакомпанія тримала великі ZFS пули з дзеркалами SSD для гарячого контенту і RAIDZ для архівів.
Нічого героїчного, але вони робили три дисципліновані речі: щомісячні scrubs з алертами на завершення, стабільні by-id імена пристроїв повсюди,
і суворе правило: будь-які помилки контрольних сум розслідуються протягом доби.

Одного ранку алерти показали, що scrub завершився з невеликою кількістю помилок контрольних сум на одному SSD.
Пул залишався ONLINE. Немає впливу на клієнтів. Саме в цю мить команди часто хочуть знизити значущість повідомлення.

Вони не знизили. Перевірили SMART, побачили зростання CRC-помилок і знайшли поганий кабель у бекплейні.
Виправили шлях, замінили кабель і переустановили з’єднання, потім запустили повторний scrub.
Більше помилок не виявлено. Проблема закінчилася тихо.

Через місяць інший вузол справді втратив диск. Resilver пройшов швидко, бо залишкові пристрої були здорові і команда вже мала довіру до базових показників сканів. Без драм і без несподіваних пошкоджених файлів.

Нудні практики недооцінюють, бо вони не дають адреналіну. Вони дають аптайм.

Цікаві факти та історичний контекст

• ZFS був побудований навколо сквозного контролю сум, тобто файлова система, а не диск, вирішує, чи коректні дані.
• Scrub існує для виявлення латентних помилок — класу «bit rot», який традиційний RAID може не помітити до того, як стане запізно.
• Ранні системи ZFS популяризували регулярні scrubs як операційну звичку, подібно до того, як СУБД популяризували регулярні бекапи і перевірки консистентності.
• Повадки resilver з часом еволюціонували; старі підходи могли схожіти на «відновлення цілого диска», тоді як нові фокусуються на виділеному просторі і працюють послідовно де можливо.
• Resilver у RAIDZ по суті читає багато дисків, щоб реконструювати відсутній. Mirrors можуть бути м’якшими: читають одну сторону, пишуть іншу.
• Імена пристроїв завдали багато проблем; зрушення індустрії до стабільних ідентифікаторів (by-id, WWN) виникло через реальні інциденти заміни не того диска.
• Контрольні суми не запобігають корупції; вони її виявляють. Запобігання — це надлишковість плюс дії з відновлення (scrub або звичайні читання, що викликають healing).
• Scrub — не перевірка вільного простору. Якщо ви хочете випробувати новий диск, робіть burn-in і SMART тест, а не лише ZFS scrub.
• Навантаження, що чутливе до затримок, помічає сканування першим; біль не в «пропускній здатності», а в чергах. Тому iostat await важить більше за чисті MB/s.

Жарт №2: Scrub — це як візит до дантиста — якщо пропустити їх достатньо довго, врешті доведеться платити за кореневі канали.

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

Plan A: You replaced a disk and resilver started

1. Підтвердіть цільовий пристрій: zpool status -P. Переконайтеся, що resilver відбувається на тому, що ви думаєте.
2. Перевірте стан пулу: якщо DEGRADED, розглядайте це як пріоритетний інцидент до завершення resilver.
3. Стежте за новими помилками: перевіряйте READ/WRITE/CKSUM кожні 10–30 хвилин на ранніх етапах.
4. Перевірте лог ядра: якщо бачите скидання/тайм-аути, виправте шлях зараз. Флапаючий лінк може розтягнути resilver і спричинити додаткові відмови.
5. Визначте політику контенції: якщо це критичне навантаження, можливо тимчасово зменшите навантаження додатку, щоб завершити resilver швидше.
6. Після завершення: перевірте ONLINE і 0 помилок; потім заплануйте scrub найближчим часом (не обов’язково одразу) для перевірки всього пулу.

Plan B: A scrub is slow and the business is yelling

1. Виміряйте вплив: перевірте латентність додатку і диск await. Якщо не можете це кількісно визначити, ви торгуєтеся на основі відчуттів.
2. Перевірте, чи scrub знаходить ремонти: zpool status. Якщо він ремонтує, скасування може відкласти лікування. Зважте ризики.
3. Вирішіть: скасувати чи продовжити: Якщо продукція під загрозою і пул здоровий — скасуйте scrub і переплануйте. Якщо пул показує помилки — скоріше продовжуйте в контрольованому вікні.
4. Виправляйте корінну причину: повільні scrubs часто вказують на відмови дисків, проблеми з кабелями або дизайн пулу з недостатнім IOPS запасом.
5. Фіксуйте базові тривалості: записуйте, скільки часу займає scrub на здоровому обладнанні. Коли вона подвоюється — щось змінилося.

Plan C: You see checksum errors but everything “seems fine”

1. Визначте пристрій: який диск накопичує CKSUM помилки?
2. Перевірте dmesg: шукайте I/O помилки і скидання.
3. Перевірте SMART: pending сектори і CRC помилки вкажуть, чи це медіа чи шлях.
4. Запустіть scrub (в безпечному вікні): примусьте верифікацію і лікування.
5. Замініть або виправте шлях: якщо помилки тривають, не торгуйтеся з диском, що бреше. Замініть його.

FAQ

1) Does a scrub read free space?

Ні. Scrub обходить виділені блоки (живі дані і метадані). Це перевірка цілісності, а не поверхнева сканування диска.

2) Does resilver verify checksums like scrub?

Resilver читає блоки і записує реконструйовані/коректні копії, і перевірка контрольних сум відбувається у процесі звичайних читань.
Але resilver не є всебічним аудитом усього пулу; він фокусуєтсья на тому, що потрібно цільовому пристрою, щоб знову стати коректним.

3) Should I run a scrub immediately after resilver?

Зазвичай: найближчим часом — так. Одразу: залежить. Якщо система крихка або завантажена, заплануйте scrub у наступне безпечне вікно.
Головна мета — валідувати широкий пул після руйнівної події.

4) Why is “scanned” higher than “issued” in zpool status?

«Scanned» відображає, наскільки далеко ZFS пройшов у просторі, який потрібно опрацювати. «Issued» відображає фактичні I/O-запити, що надійшли.
Різниця зростає через обхід метаданих, пропуск непотрібних регіонів, контенцію або інші внутрішні особливості реалізації.

5) Is it safe to cancel a resilver?

«Безпечно» — неправильне питання. Скасування resilver залишає вас довше DEGRADED. Це збільшує ризик.
Скасовуйте лише при гострій необхідності і перезапускайте якомога швидше після вирішення причини (наприклад, проблеми шляху).

6) Scrub found errors but “errors: No known data errors” still appears. What gives?

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

7) Does running scrubs reduce SSD lifespan?

Scrub — здебільшого читання; записи відбуваються під час ремонту. Читання також створюють навантаження на контролер SSD, але занепокоєння щодо зношення через scrub зазвичай помірне.
Більше ризику — у впливі на продуктивність і забезпеченні, щоб SSD були здорові і охолоджені.

8) How often should I scrub?

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

9) Why does resilver take so long on RAIDZ compared to mirrors?

RAIDZ resilver потребує читання даних/паритету з кількох дисків, щоб реконструювати відсутній. Mirrors можуть скопіювати з одного здорового члена.
Топологія визначає I/O fan-out і покарання при контенції.

10) If my pool is healthy, can I ignore occasional checksum errors?

Ні. «Іноді» може означати «рідко і транзитно», але також може бути «першим попередженням». Розслідуйте спочатку.
Вартість перевірки логів та SMART мала порівняно з тим, щоб виявити проблему вже під час DEGRADED події.

Наступні кроки на цей тиждень

• Розплануйте scrub, який дійсно завершується (і налаштуйте алерти на завершення та помилки). «Запущено» — не інформативний статус.
• Зафіксуйте базову тривалість scrub на здоровому обладнанні. Коли вона змінюється суттєво — розслідуйте до відмови.
• Стандартизуйте стабільні ідентифікатори дисків (/dev/disk/by-id) у конфігураціях пулу та в рунбуках.
• Напишіть односторінкову процедуру для DEGRADED-pool: пріоритезуйте resilver, мінімізуйте шум, стежте за другою відмовою, уникайте ризикових перезавантажень.
• Навчіть команду читати zpool status: рядок scan, лічильники помилок і що насправді означає «No known data errors».
• Визначте політику впливу сканів: коли скасовувати scrub, коли дозволяти йому працювати і як відповідати на бізнес-тиснення, не кидаючи перевірки цілісності.

Scrub і resilver — обидва «scan» операції, тому люди й плутають їх у розмові.
Але в операціях дієслова мають значення. Одне доводить. Інше відновлює. Якщо ставитись до них як до взаємозамінних, ZFS не сперечатиметься — воно просто сумлінно виконає вашу помилку.