Повільний ZFS scrub: як відрізнити нормальну затримку від реальної проблеми

Ваш scrub «виконується» вже стільки часу, що колеги запитують, чи не заселено сховище привидами. Додатки відчуваються повільними, панелі показують море I/O, а ETA або відсутній, або бреше. Потрібно зрозуміти: це нормальний, нудний scrub, який виконує свою роботу, чи це симптом проблеми, яка може підкласти вам міну пізніше?

Ось виробничо-дружній спосіб відповісти на це запитання. Ми відділимо очікувану повільність (ту, що ви плануєте й терпите) від патологічної повільності (яку треба виправити, поки вона не перетвориться на пожежу в службі підтримки).

Що насправді робить scrub (і чому іноді «повільно» — це нормально)

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

Це тягне за собою дві речі, які дивують людей:

• Scrub за своєю суттю читає багато даних (з періодичними записами під час виправлень). Ваш пул може «повільніти», тому що читання повільні, через конкуренцію з реальними навантаженнями або тому, що ZFS свідомо поводиться стримано.
• Scrub працює на рівні блоків, а не файлів. Фрагментація, вибір recordsize і накладні витрати на метадані можуть важити більше, ніж сирі МБ/с диска.

Scrub також поводиться по-різному залежно від розкладки vdev. Дзеркала зазвичай скрабляться швидше і передбачуваніше, ніж RAIDZ, бо дзеркала можуть обслужити читання з будь-якого диска, а паритетні обчислення простіші. RAIDZ scrubs цілком нормальні, коли пул здоровий, але вони можуть розтягнутися, якщо у вас широкі vdev, слабкі диски або інтенсивний випадковий I/O від додатків.

Ось правило для виробництва, яким я користуюся: час scrub — це спостережувана властивість вашої системи, а не моральна провина. Але швидкість scrub, яка колапсує, або ETA, що зростає, — це запах проблеми. Не завжди пожежа, але завжди варто подивитися.

Короткий жарт №1: Scrub без ETA — як інцидент зі сховищем без постмортему: технічно можливо, соціально неприйнятно.

Цікаві факти та трохи історії

• ZFS популяризував наскрізну перевірку контрольних сум у серверному сховищі. Контрольні суми зберігаються окремо від даних, тому ZFS може виявити «брехливі диски», які повертають пошкоджені блоки без I/O помилок.
• Scrub — це відповідь ZFS на «bit rot» — тиху, поступову корупцію, яку класичний RAID часто не помічає, поки не прочитають дані і не спрацює відновлення паритету.
• Термін «scrub» походить з більш старих систем зберігання, які періодично сканували носій на помилки. ZFS зробив це рутинним і видимим для користувача.
• RAIDZ створювався, щоб уникнути write hole у класичних RAID5/6, зберігаючи транзакційну послідовність метаданих і семантику copy-on-write.
• ZFS народився в Sun Microsystems і пізніше поширився через OpenZFS. Сучасна поведінка залежить від версії OpenZFS, а не лише від бренду «ZFS».
• Раніше scrubs були болючішими на системах без хорошого планувальника I/O або де обмеження scrub були примітивні. Сучасні стек Linux і FreeBSD дають більше важелів, але й більше способів зашкодити собі.
• Метадані мають значення. Пули з мільйонами дрібних файлів можуть скрабитися повільніше, ніж пул з меншим числом великих файлів, навіть якщо «використаної місця» виглядає схоже.
• SMR-диски зробили scrubs непередбачуванішими у реальних умовах. Коли диск виконує фонову шінґлову збірку сміття, «читання» можуть перетворитися на «читання плюс внутрішній перезапис», що ускладнює роботу.
• Підприємницькі масиви робили патрульні читання десятиліттями, часто непомітно. ZFS просто дає вам правду відкрито — і виявляється, що правда може бути повільною.

Нормальна повільність scrub проти реальної проблеми: модель мислення

«Повільний scrub» неоднозначний. Потрібно визначити, який саме тип повільності ви бачите. Я ділю це на чотири категорії:

1) «Великий пул, фізика» — повільно

Якщо у вас сотні ТБ на обертових дисках, scrub, що триває дні, може бути нормальним. Його обмежує послідовна пропускна здатність, розкладка vdev і те, що scrub не завжди отримує ідеально послідовні доступи (розподілені блоки не обов’язково сусідні).

Ознаки нормальності:

• Швидкість scrub стабільна протягом годин.
• Затримки диска не вибухають.
• Вплив на додатки передбачуваний і обмежений.
• Немає помилок контрольних сум або помилок читання.

2) «Навмисне обмежено» — повільно

ZFS часто самоблокуватиме scrub, щоб виробничі навантаження не впали. Це означає, що scrub може здаватися неприємно повільним, поки система залишається придатною для роботи. Це хороша інженерна поведінка. Ви можете налаштувати це, але робіть це свідомо.

Ознаки обмеження:

• CPU в основному в нормі.
• IOPS не досягають максимуму, але прогрес scrub рухається повільно.
• Затримка навантаження залишається в межах SLO.

3) «Конкуренція з навантаженням» — повільно

Якщо пул обслуговує завантажену базу даних, ферму VM або об’єктне навантаження, читання scrub конкурують із читаннями/записами додатків. Тепер швидкість scrub залежить від робочих годин бізнесу. Це не провина ZFS; це питання планування.

Ознаки конкуренції:

• Швидкість scrub змінюється залежно від патернів трафіку.
• Спайки затримок корелюють із піками додатків.
• Вимкнення scrub робить користувачів задоволенішими.

4) «Щось не так» — повільно

Ця категорія — саме те, про що ви насправді питаєте. Повільність scrub стає симптомом: диск повторно читає, контролер видає помилки, лінк перейшов на 1.5Gbps, член vdev хворіє і тягне всіх, або ви побудували розкладку пулу, яка придатна для ємності, але погана для scrub.

Ознаки, що це справжня проблема:

• Помилки читання, помилки контрольних сум або зростання «відновлених» байтів між scrub.
• Один диск показує значно вищі затримки або нижчу пропускну здатність, ніж інші.
• Швидкість scrub колапсує з часом (спочатку нормальна, потім повзе).
• Логи ядра показують ресети, тайм-аути або проблеми з лінком.
• SMART-параметри показують переназначені/очікувані сектори або UDMA CRC помилки.

Ключове: «повільно» — не діагноз. Ви полюєте на вузьке місце і потім питаєте, чи це очікуване, налаштоване або відмовне.

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

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

Перший: Чи здоровий scrub?

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

Другий: Чи тягне якийсь пристрій весь vdev?

• Перевірте затримки по диску і час обслуговування I/O під час scrub.
• Швидко перевірте SMART на наявність очікуваних секторів, помилок носія і CRC лінку.
• Рішення: якщо один диск повільний або робить ретраї, замініть його або ізолюйте; scrub — це канарка.

Третій: Це конкуренція чи обмеження?

• Корелюйте швидкість scrub з метриками навантаження (IOPS, затримка, глибина черги).
• Перевірте налаштування ZFS і чи не обмежено scrub навмисно.
• Рішення: якщо це обмеження, налаштуйте обережно; якщо конкуренція — перенесіть чи розділіть навантаження.

Лише після цих трьох кроків переходьте до «архітектурних питань», як ширина vdev, recordsize, спеціальні vdev або додавання кешу. Якщо scrub повільний через гнучкий SATA-кабель, жодне «тонке налаштування» не допоможе.

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

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

Завдання 1: Підтвердити стан scrub, швидкість і помилки

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Dec 23 01:00:02 2025
        12.3T scanned at 612M/s, 8.1T issued at 403M/s, 43.2T total
        0B repaired, 18.75% done, 2 days 09:14:33 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       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

errors: No known data errors

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

Рішення: Якщо READ/WRITE/CKSUM рахунки ненульові, перестаньте сприймати це як «просто повільно». Розслідуйте несправні пристрої перед налаштуванням.

Завдання 2: Отримати однолінійний прогрес регулярно (добре для каналів інцидентів)

cr0x@server:~$ zpool status tank | sed -n '1,12p'
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Dec 23 01:00:02 2025
        12.3T scanned at 612M/s, 8.1T issued at 403M/s, 43.2T total
        0B repaired, 18.75% done, 2 days 09:14:33 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0

Що це означає: Це мінімальний життєздатний фрагмент статусу. Якщо ETA постійно зростає година за годиною, ймовірно, ви маєте конкуренцію або ретраї читань.

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

Завдання 3: З’ясувати, з якою розкладкою vdev ви маєте справу

cr0x@server:~$ zpool status -P tank
  pool: tank
 state: ONLINE
config:

        NAME                                   STATE     READ WRITE CKSUM
        tank                                   ONLINE       0     0     0
          raidz2-0                             ONLINE       0     0     0
            /dev/disk/by-id/ata-ST12000...A1   ONLINE       0     0     0
            /dev/disk/by-id/ata-ST12000...B2   ONLINE       0     0     0
            /dev/disk/by-id/ata-ST12000...C3   ONLINE       0     0     0
            /dev/disk/by-id/ata-ST12000...D4   ONLINE       0     0     0
            /dev/disk/by-id/ata-ST12000...E5   ONLINE       0     0     0
            /dev/disk/by-id/ata-ST12000...F6   ONLINE       0     0     0

Що це означає: RAIDZ2 у одному широкому vdev. Швидкість scrub буде обмежена найповільнішим диском та накладними витратами паритету. Один невідповідний диск може загальмувати весь vdev.

Рішення: Якщо у вас дуже широкий RAIDZ vdev і scrubs болісні, вам може знадобитися архітектурна зміна пізніше (більше vdev, вужча ширина). Не намагайтеся «натюнити» фізику.

Завдання 4: Перевірити затримки по дисках і завантаження під час scrub (Linux)

cr0x@server:~$ iostat -x 2 3
Linux 6.6.12 (server)     12/25/2025  _x86_64_    (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.21    0.00    2.73    8.14    0.00   84.92

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s  w_await aqu-sz  %util
sda             112.0   28800.0     0.0   0.00   18.40   257.1      2.0     512.0   4.30   2.10  98.5
sdb             118.0   30208.0     0.0   0.00   17.92   256.0      2.0     512.0   4.10   2.12  97.9
sdc             110.0   28160.0     0.0   0.00   19.30   256.0      2.0     512.0   4.20   2.05  98.2
sdd              15.0    3840.0     0.0   0.00  220.10   256.0      1.0     256.0  10.00   3.90  99.1
sde             115.0   29440.0     0.0   0.00   18.10   256.0      2.0     512.0   4.00   2.08  98.0
sdf             114.0   29184.0     0.0   0.00   18.70   256.0      2.0     512.0   4.20   2.11  98.4

Що це означає: sdd має r_await близько 220ms, тоді як інші — близько 18ms. Це ваш анклав scrub. Пул рухатиметься в темпі найгіршого виконавця в RAIDZ vdev.

Рішення: Негайно перевірте sdd на помилки/логи/SMART. Якщо це кабель або контролер — виправте це перед заміною диска.

Завдання 5: Перевірити системні логи на ресети/тайм-аути (Linux)

cr0x@server:~$ sudo dmesg -T | egrep -i 'ata|scsi|reset|timeout|error' | tail -n 12
[Wed Dec 24 13:18:44 2025] ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Wed Dec 24 13:18:44 2025] ata7.00: failed command: READ FPDMA QUEUED
[Wed Dec 24 13:18:44 2025] ata7: hard resetting link
[Wed Dec 24 13:18:45 2025] ata7: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[Wed Dec 24 13:18:46 2025] ata7.00: sd 6:0:0:0: [sdd] tag#17 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=14s
[Wed Dec 24 13:18:46 2025] blk_update_request: I/O error, dev sdd, sector 123456789 op 0x0:(READ) flags 0x0 phys_seg 8 prio class 0

Що це означає: Ресет лінку і повторне узгодження на 1.5Gbps — класична ознака проблем з кабелем/бекплейном/портом. Це також може бути вмираючий диск, але кабелі дешевші і соромно поширені.

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

Завдання 6: Швидка перевірка SMART для повільного пристрою

cr0x@server:~$ sudo smartctl -a /dev/sdd | egrep -i 'Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|UDMA_CRC_Error_Count|SMART overall|Power_On_Hours'
SMART overall-health self-assessment test result: PASSED
  9 Power_On_Hours          0x0032   086   086   000    Old_age   Always       -       31245
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       12
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       3
199 UDMA_CRC_Error_Count    0x003e   200   199   000    Old_age   Always       -       27

Що це означає: Очікувані сектори та offline uncorrectable означають, що диск має проблеми з читанням деяких областей. UDMA CRC помилки часто вказують на проблеми з кабелем/бекплейном. «PASSED» — не виправдання; це маркетинг.

Рішення: Якщо є pending/offline uncorrectable, плануйте заміну. Якщо CRC помилки зростають, виправте шлях (кабель/бекплейн/HBA) також.

Завдання 7: Виявити, чи пул виконує виправлення (і скільки)

cr0x@server:~$ zpool status -v tank | sed -n '1,25p'
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Dec 23 01:00:02 2025
        14.8T scanned at 540M/s, 10.2T issued at 372M/s, 43.2T total
        256M repaired, 23.61% done, 2 days 05:01:12 to go
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0

Що це означає: Ненульовий показник «repaired» під час scrub означає, що ZFS знайшов невідповідності контрольних сум і виправив їх. Це scrub, який виконує свою роботу, але також доказ корупції десь нижче (диск, кабель, контролер або пам’ять).

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

Завдання 8: Шукати індикатори I/O і затримки на рівні ZFS (Linux)

cr0x@server:~$ sudo cat /proc/spl/kstat/zfs/arcstats | egrep '^(hits|misses|size|c_max|demand_data_misses|prefetch_data_misses) ' | head
hits                            2876543210
misses                          456789012
size                            17179869184
c_max                           34359738368
demand_data_misses              123456789
prefetch_data_misses            234567890

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

Рішення: Якщо ARC виснажена і вузол підмінює, вирішіть проблему пам’яті перш за все. Не звинувачуйте scrub у дефіциті RAM.

Завдання 9: Перевірити I/O пулу в реальному часі (Linux з zpool iostat)

cr0x@server:~$ zpool iostat -v tank 2 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        28.1T  15.1T  3.10K    220   380M  12.1M
  raidz2-0  28.1T  15.1T  3.10K    220   380M  12.1M
    sda          -      -    520     35  63.5M  2.1M
    sdb          -      -    525     36  64.1M  2.1M
    sdc          -      -    518     35  63.2M  2.0M
    sdd          -      -    110     34  12.9M  2.0M
    sde          -      -    523     35  64.0M  2.1M
    sdf          -      -    524     35  64.3M  2.1M
----------  -----  -----  -----  -----  -----  -----

Що це означає: Знову ж таки, sdd демонструє низьку продуктивність порівняно з іншими. У RAIDZ це може зменшити ефективну пропускну здатність і збільшити час scrub.

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

Завдання 10: Підтвердити ashift і базові властивості пулу (базова продуктивність)

cr0x@server:~$ zdb -C tank | egrep 'ashift|vdev_tree' -n | head -n 8
64:        ashift: 12
120:    vdev_tree:
121:        type: 'root'
122:        id: 0

Що це означає: ashift: 12 означає 4K сектори. Якщо ви бачите ashift: 9 на сучасних 4K дисках, ви можете отримати ампліфікацію записів і дивну поведінку продуктивності. Це не завжди показує себе під час scrub (в основному читання), але може погіршити загальну продуктивність пулу і накладні витрати на resilver/scrub.

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

Завдання 11: Перевірити стиснення та recordsize набору даних (взаємодія з навантаженням)

cr0x@server:~$ zfs get -o name,property,value -s local compression,recordsize tank/vmstore
NAME         PROPERTY     VALUE
tank/vmstore compression  lz4
tank/vmstore recordsize   128K

Що це означає: Для образів VM recordsize часто ставлять меншим (наприклад, 16K) залежно від патернів I/O. Великий recordsize не завжди «помилка», але якщо ваше навантаження випадкове 4K, ви можете отримати більше читань на корисний байт під час scrub і загалом більше операцій.

Рішення: Не змінюйте recordsize легковажно на існуючих даних. Але якщо більші труднощі зі scrub корелюють з набором даних, відомим дрібним випадковим I/O, перегляньте дизайн набору даних для наступної ітерації.

Завдання 12: Перевірити наявність спеціальних vdev (для метаданих) та їх стан

cr0x@server:~$ zpool status tank | egrep -n 'special|log|cache|spares' -A3
15:    special
16:      nvme0n1p2             ONLINE       0     0     0

Що це означає: Якщо у вас є special vdev (часто NVMe), що зберігає метадані/дрібні блоки, його стан і затримка можуть домінувати у поведінці scrub для пулів з великою кількістю метаданих. Помираючий special vdev може зробити весь пул «повільним», навіть якщо HDD у порядку.

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

Завдання 13: Перевірити фактичний шлях пристрою і швидкість лінку (поширена прихована несправність)

cr0x@server:~$ sudo hdparm -I /dev/sdd | egrep -i 'Transport|speed|SATA Version' | head -n 5
Transport: Serial, ATA8-AST, SATA 3.1
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 1.5 Gb/s)

Що це означає: Диск підтримує 6.0Gb/s, але наразі працює на 1.5Gb/s. Це сильний індикатор проблеми лінку, а не «ZFS повільний».

Рішення: Виправте фізичний шлях. Після ремонту підтвердіть узгодження на 6.0Gb/s і знову запустіть iostat.

Завдання 14: Перевірити параметри, пов’язані з обмеженням scrub (Linux OpenZFS)

cr0x@server:~$ sudo systool -m zfs -a 2>/dev/null | egrep 'zfs_scrub_delay|zfs_top_maxinflight|zfs_vdev_scrub_max_active' | head -n 20
  Parameters:
    zfs_scrub_delay        = "4"
    zfs_top_maxinflight    = "32"
    zfs_vdev_scrub_max_active = "2"

Що це означає: Ці значення впливають на те, як агресивно scrub витісняє I/O. Більш агресивне не завжди краще; ви можете збільшити глибину черги і затримки для додатків, а іноді уповільнити сам scrub через трешинг.

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

Завдання 15: Підтвердити TRIM і autotrim поведінку (SSD пули)

cr0x@server:~$ zpool get autotrim tank
NAME  PROPERTY  VALUE     SOURCE
tank  autotrim  off       default

Що це означає: У SSD пулах autotrim може впливати на довготривалу продуктивність. Не безпосередньо на швидкість scrub, але змінює поведінку пулу під стійкими читаннями/записами і GC, що може робити scrubs «випадково жахливими».

Рішення: Якщо ви на SSD і бачите періодичні провали продуктивності — оцініть ввімкнення autotrim у контрольованому вікні змін.

Завдання 16: Перевірити, чи ви випадково не запускаєте scrubs надто часто

cr0x@server:~$ sudo grep -R "zpool scrub" -n /etc/cron* /var/spool/cron 2>/dev/null | head
/etc/cron.monthly/zfs-scrub:4: zpool scrub tank

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

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

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

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

Середня компанія експлуатувала ZFS-підтримуваний кластер віртуалізації. Нічого екзотичного: RAIDZ2, великі SATA-диски, по одному пулу на вузол. Scrubs були заплановані щомісяця і завжди займали «трохи часу». Люди це сприймали як норму.

Потім одного місяця ETA scrub почав зростати. Спочатку не драматично — лише на день. На виклику припустили, що це конкуренція навантаження: пакетні задачі наприкінці кварталу. Вони дали процесу йти далі. «Scrubs повільні; закінчиться.»

Через два дні латентність VM для користувачів підскочила, потім спала, потім знову підскочила. Zpool status все ще показував ONLINE, без очевидних помилок. Припущення трималося: «занадто завантажено». Тож ніхто не дивився на статистику по дисках. Це була помилка.

Коли хтось нарешті запустив iostat -x, один диск мав read await 300–800ms, тоді як інші — 15–25ms. SMART показав pending сектори. Диск не помирав швидко; він помирав коректно, тягнучи весь vdev через ретраї. Це найгірший вид, бо виглядає як «нормальна повільність» доти, доки раптом не перестає бути нормальною.

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

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

Інша організація мала суворі вікна обслуговування. Вони хотіли, щоб scrubs закінчувалися впродовж вихідних без винятків. Хтось знайшов параметри scrub і вирішив «підвищити швидкість». Збільшили конкуренцію scrub і зменшили затримки. Показник пропускної здатності виглядав чудово — близько години.

Потім латентність додатків підскочила. Гіпервізори почали логувати зависання зберігання. Користувачі у понеділок обурилися «випадковою повільністю». Команда спочатку звинувачувала мережу (як це зазвичай буває), потім ZFS, потім гіпервізор. Класичний трикутник заперечення.

Насправді сталося банальне: I/O патерн scrub витіснив кеш навантаження і розгромив черги дисків. HDD опинилися майже на 100% util з високими часами обслуговування. Деякі читання додатків стали хвостовими затримками. Сам scrub і не закінчився загалом швидше — бо коли черги виросли, ефективна пропускна здатність впала і зросли ретраї.

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

Короткий жарт №2: Налаштування зберігання — як офісна політика: якщо тиснеш занадто сильно, усі гальмують, і врешті-решт це все одно твоя провина.

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

Команда фінтеху експлуатувала OpenZFS на Linux для навантаження, схожого на реєстр. Scrubs вважали формальною процедурою обслуговування: планували, моніторили і порівнювали з історичними базами. Ніяких геройств. Просто графіки й дисципліна.

Вони мали простий рукбук: після кожного scrub записувати тривалість, середню issued bandwidth і будь-які відновлені байти. Якщо «repaired» ненульовий — це тригер для глибшої перевірки: логи ядра, SMART long test і перегляд останніх змін у апаратурі.

Якось місяця scrub завершився з невеликою кількістю repaired — нічого страшного саме по собі. Але це було другий місяць підряд. Їхня логіка по базі даних це відфільтрувала. На виклику знайшли інтермітентні CRC помилки на одному шляху диска. Не досить, щоб диск відразу відмовив, але достатньо, щоб іноді перевертати біти під навантаженням. Саме такий дефект руйнує вам день через шість місяців.

Вони замінили бекплейн-кабель і перемістили диск на інший порт HBA. Виправлення припинилися. Ні аварій, ні втрат даних, ні драматичного інцидентного звіту. Це той виграш, який зазвичай не святкують, бо нічого й не вибухнуло. Але його варто святкувати.

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

Цей розділ навмисно відвертий. Це шаблони, що з’являються в продакшні знову й знову, бо люди — послідовні істоти.

ETA scrub зростає з часом

• Симптом: ETA з «12 годин» до «2 днів» під час виконання scrub.
• Причина: Пристрій повторно читає (проблеми носія) або лінк флапає; альтернативно — конкуренція навантаження піднялася.
• Виправлення: Запустіть iostat -x і zpool iostat -v, щоб знайти повільний диск; перевірте dmesg і SMART. Якщо повільного диска немає, корелюйте з навантаженням і перенесіть scrub.

Scrub «повільний» лише в робочі години

• Симптом: Scrub повзе 9–17 і прискорюється вночі.
• Причина: Конкуренція з виробничим навантаженням; ZFS і/або планувальник ОС роблять правильно, віддаючи пріоритет foreground I/O.
• Виправлення: Плануйте scrubs на періоди з малим трафіком; розгляньте обмеження замість агресії. Не збільшуйте конкуренцію бездумно.

Один диск має в 10 разів більший await, ніж інші

• Симптом: В iostat -x один диск має високий r_await або незвичні патерни %util.
• Причина: Вмираючий диск, поведінка SMR під навантаженням, поганий кабель/бекплейн, порт узгодився вниз.
• Виправлення: Перевірте dmesg і SMART, підтвердіть швидкість лінку, поміняйте кабель/порт, замініть диск якщо є pending сектори або uncorrectables.

Scrub викликає тайм-аути додатків

• Симптом: Спайки затримки, тайм-аути, черги ростуть; scrub ніби «DoS» систему.
• Причина: Scrub I/O надто агресивний, погана ізоляція навантажень, замало vdev, HDD-пул обслуговує випадкове I/O без достатньої кількості шпинделів.
• Виправлення: Зменшіть агресивність scrub; перенесіть у часи з меншим трафіком; додайте vdev або перемістіть навантаження на SSD/NVMe; розгляньте спеціальні vdev для метаданих. Перестаньте очікувати, що один широкий RAIDZ vdev поводиться як масив.

Scrub повторно повідомляє про відновлені байти

• Симптом: Кожен scrub щось відновлює.
• Причина: Хронічне джерело корупції: поганий диск, кабель, контролер або проблеми з пам’яттю (так, пам’ять).
• Виправлення: Розслідуйте апаратний шлях від початку до кінця; запустіть SMART long tests; перевірте логи ECC якщо доступні; розгляньте контрольне тестування пам’яті. Відновлення даних — це подарунок: не ігноруйте його.

Scrub повільний на SSD пулі «без причини»

• Симптом: NVMe/SSD пул scrubs повільніші, ніж очікується, іноді з періодичними падіннями.
• Причина: Троттлінг температури, GC SSD, погана поведінка TRIM, проблеми PCIe лінку або вузьке місце special vdev.
• Виправлення: Перевірте температури і швидкість PCIe лінку; перегляньте autotrim; підтвердіть прошивку; переконайтеся, що special vdev не перевантажений або не має помилок.

Scrub ніколи не встигає до наступного запланованого scrub

• Симптом: Постійно виконується scrub; оператори перестають звертати увагу.
• Причина: Перевищено розмір пулу для наявних носіїв, занадто часта каденція або scrub перезапускається автоматично.
• Виправлення: Зменшіть каденцію; переконайтеся, що scrubs не перезапускаються даремно; розгляньте архітектурні зміни (більше vdev, швидші носії), якщо перевірки цілісності не завершуються в розумні строки.

Швидкість scrub значно нижча, ніж підказує математика дисків

• Симптом: «У нас N дисків, кожен дає X MB/s, отже чому не N×X?»
• Причина: Scrub читає виділені блоки, не обов’язково послідовні; метадані; паритет RAIDZ; фрагментація; і пул може бути близький до заповнення, що погіршує ситуацію.
• Виправлення: Порівнюйте зі своїми історичними scrub-базами, а не з даташитами виробника. Якщо майже повний — звільніть простір. Якщо фрагментація значна — розгляньте планову перебудову через реплікацію на свіжий пул.

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

Покроково: Визначити, чи повільний scrub — «нормальний»

1. Захопіть поточний стан. Запустіть zpool status -v. Збережіть у тікеті/чаті.
2. Пошукайте помилки. Ненульові READ/WRITE/CKSUM або зміни «repaired» змінюють пріоритет.
3. Виміряйте issued rate. Якщо issued стабільний і в межах історії — ймовірно нормально.
4. Перевірте затримки по дисках. Використайте iostat -x (Linux) і знайдіть аутлайєри.
5. Перевірте логи. Один рядок у dmesg про ресети може пояснити дні scrub-болю.
6. Перевірте SMART. Pending сектори, uncorrectable і CRC помилки вирішують питання заміни апаратури.
7. Корелюйте з навантаженням. Якщо scrub повільний лише під навантаженням — виправте планування і/або throttling.
8. Лише потім тюнінг. І робіть по одній зміні з планом відкату.

Покроково: Якщо ви знайшли повільний диск під час scrub

1. Підтвердіть, що він послідовно повільний: iostat -x 2 5 і zpool iostat -v 2 5.
2. Перевірте, чи лінк узгодився вниз: hdparm -I для SATA або логи контролера для SAS.
3. Перегляньте системні логи на ресети/тайм-аути: відфільтруйте dmesg -T.
4. Перевірте SMART: pending/offline uncorrectable означають, що диск «живе на позиченому часі».
5. Спочатку поміняйте дешеві речі (кабель/порт), якщо є ознаки проблеми лінку.
6. Замініть диск, якщо присутні проблеми носія або помилки залишаються після виправлення шляху.
7. Після заміни запустіть ще один scrub або принаймні цільову перевірку відповідно до ваших операційних стандартів.

Покроково: Якщо scrub здоровий, але порушує продуктивність

1. Підтвердіть, що жоден пристрій не хворий (аномальна затримка, помилки).
2. Підтвердіть, чи scrub уже обмежений (перевірте параметри і спостережувану глибину I/O).
3. Перенесіть розклад scrub на періоди з низьким трафіком; рознесіть по пулах/вузлах.
4. Якщо доводиться scrub в робочі години — краще обмежити, ніж прискорювати.
5. Переоцініть розкладку пулу, якщо ви постійно не встигаєте завершити scrubs у вікні обслуговування.

FAQ

1) Яка «нормальна» швидкість ZFS scrub?

Нормальна — це те, що робить ваш пул, коли він здоровий, слабко навантажений і без помилок. Використовуйте власні історичні тривалість scrub і issued bandwidth як базу. Специфікації послідовності від виробника диска — не обіцянка scrub.

2) Чому scanned відрізняється від issued в zpool status?

«Scanned» відображає логічний прогрес по блоках; «issued» — фактичні I/O, надіслані/завершені на vdev. Великі розбіжності можуть бути через кешування, readahead або очікування повільних пристроїв. Якщо issued низький і затримка висока — шукайте тягнучий диск.

3) Чи scrub читає вільний простір?

Зазвичай scrub перевіряє виділені блоки (те, що реально використовується). Це не повне поверхневе сканування кожного сектора. Тому диск може мати латентні погані сектори, які виявляться лише при записі або пізнішому читанні.

4) Чи варто зупиняти scrub, якщо він повільний?

Якщо scrub здоровий, але порушує SLO виробництва, пауза/зупинка може бути розумним рішенням — і потім перепланувати. Якщо ви бачите помилки або виправлення, зупинка лише відтерміновує інформацію, яка вам, ймовірно, потрібна. Вирішуйте апаратні проблеми.

5) Як часто слід виконувати scrub?

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

6) Scrub знайшов і виправив дані. Чи тепер я в безпеці?

Ви в кращому положенні, ніж були, але це не кінець. Виправлення означає, що десь нижче була корупція. Якщо ремонти повторюються, потрібен root cause analysis дисків, кабелів, контролерів і, можливо, пам’яті.

7) Чи RAIDZ природно повільніший під час scrub порівняно з дзеркалами?

Дзеркала часто швидші і передбачуваніші для читань, бо можуть балансувати навантаження і не виконують паритетну реконструкцію на читанні. RAIDZ може бути нормальним, коли здоровий, але широкі RAIDZ vdev більш чутливі до одного повільного диска і до випадкових I/O патернів.

8) Чи тюнінг може значно прискорити scrubs?

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

9) Чому scrub повільний на пулі, що здебільшого порожній?

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

10) У чому різниця між scrub і resilver, і чому це важливо для повільності?

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

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

Повільні scrubs самі по собі не страшні. Насправді, повільний scrub на великому, завантаженому пулі часто означає, що ZFS поводиться відповідально. Страшно — це незрозуміла повільність, особливо з аутлайєрами по дисках, ресетами ядра або повторюваними ремонтами.

Використовуйте цю послідовність за замовчуванням:

1. Запустіть zpool status -v і вирішіть, чи це подія надійності (помилки/ремонти) або питання планування/продуктивності.
2. Запустіть iostat -x і zpool iostat -v, щоб знайти повільний пристрій або підтвердити конкуренцію.
3. Перевірте dmesg і SMART на очевидні проблеми апаратного шляху.
4. Лише потім розглядайте тюнінг і зміну розкладу, і вимірюйте вплив по відношенню до вашої історичної бази.

Одна перефразована ідея від W. Edwards Deming підходить для операційної роботи: «Без даних ви просто людина з думкою». Повільність scrub — це ваш шанс зібрати дані, поки ви не зібрали інцидентів.