ZFS Resilver: Чому відновлення займає дні (і як його безпечно прискорити)

Повідомлення приходить о 09:12: «DEGRADED pool.» Ви міняєте диск, запускаєте zpool replace і очікуєте пару годин метушні.
Потім zpool status повідомляє «resilvering… 3%» і ETA, який виглядає як довгі вихідні.

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

Що фактично робить відновлення (і чому воно здається повільнішим, ніж «має бути»)

У ZFS «відновлення» — це реконструкція після заміни або повернення пристрою онлайн. ZFS обходить метадані пулу, щоб з’ясувати, які блоки реально використовуються,
потім відтворює відсутні копії/паріт і записує їх на новий (або повернутий) пристрій.

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

Також відновлення — це не просто велике потокове читання і запис. Це «знайти всі посилання на блоки й виправити відсутню сторону», що в RAIDZ означає читання достатньої кількості колонок для реконструкції паритету, а в дзеркалах — копіювання блоків з іншої сторони. Дзеркала можуть бути швидкими, якщо читають послідовно. RAIDZ часто не може.

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

Чому відновлення займає дні: реальні вузькі місця

1) Випадковий I/O і фрагментація: «використані байти» не підряд

Якщо ваш пул працює роками з мішаними навантаженнями — образи VM, бази даних, дрібні файли, видалення, снапшоти — блоки розкидаються.
ZFS мусить ганятися за вказівниками метаданих, що перетворюється на багато дрібних читань. HDD це ненавидять. Навіть SSD можуть страждати при насиченні через невідповідність глибин черг
або через write amplification.

Брехня, яку ми собі розповідаємо: «Використано лише 12 ТБ; має відновитися за 12 ТБ / пропускна здатність диска.» Це припускає послідовні читання і записи, низькі накладні витрати на метадані
і відсутність конкуренції. Насправді ефективна пропускна здатність відновлення часто обмежена IOPS, а не MB/s.

2) Геометрія vdev: RAIDZ читає більше, ніж ви думаєте

У дзеркалі, щоб відновити відсутню сторону, ви зазвичай можете прочитати здоровий диск і записати новий. У RAIDZ, щоб реконструювати один відсутній диск,
ZFS читає решту колонок кожного стрипу. Це більше I/O на відновлений байт і воно розкидане по більшій кількості шпинделів.

Відновлення RAIDZ особливо жорстоке на широких vdev з великими дисками. Пул деградував, тож резервність зменшилася, і продуктивність падає саме тоді, коли вона потрібна.
Якщо ви невдалий, ви також будете обслуговувати читання з меншим числом колонок. Це ніби ремонтуєш міст під час годин пік.

3) «Виділення під час відновлення»: блоки змінюються під ногами

ZFS — copy-on-write. Нові записи йдуть у нові локації, старі блоки залишаються посиланнями, поки їх не звільнять. Під час відновлення активні записи можуть змінити те, що треба копіювати:
оновлення метаданих, непрямі блоки, нові вказівники блоків. ZFS це опрацьовує, але це робить операцію менш «одноразовою», ніж люди припускають.

4) Заповненість пулу: вище приблизно 80% стає погано дуже швидко

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

5) Recordsize, volblocksize і навантаження з дрібними блоками

Відновлення має справу з розміром блоків, як вони зберігаються на диску. Zvol для VM з volblocksize 8K або dataset для бази даних з recordsize 16K
призводить до значно більшої кількості блоків для обходу, ніж dataset з 1M записами.

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

6) Стиснення і dedup: добре до моменту відновлення

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

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

7) Контрольні суми, крипто і вузькі місця CPU

ZFS перевіряє контрольні суми під час читання. Якщо ви використовуєте нативне шифрування, він також розшифровує. На старих процесорах або зайнятих системах відновлення може стати CPU-зв’язуваним,
особливо коли патерн I/O — багато дрібних блоків (більше операцій контрольних сум на байт).

8) «Пріоритет відновлення» — це компроміс, а не безкоштовний обід

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

9) Повільні або несумісні диски-замінники

Якщо новий диск — SMR, має агресивний внутрішній GC, підключений через сумний HBA або просто повільніший за старий,
час відновлення може вибухнути. «Така сама ємність» ≠ «така сама поведінка».

Жарт №1: Відновлення — це еквівалент фарбування будинку, поки ви в ньому живете — технічно можливо, але не приємно.

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

• ZFS почався в Sun Microsystems у середині 2000-х як реакція на файлові системи, що розділяли «volume manager» і «filesystem».
• Copy-on-write був свідомою ставкою: він зробив снапшоти дешевими і консистентність сильною, але ускладнив патерни виділення з часом.
• Відновлення — не те саме, що scrub: scrub перевіряє весь пул; відновлення реконструює резервність після втрати пристрою. Вони ділять код, але мають різні цілі.
• «Slop space» існує з причини: ZFS зберігає трохи простору незастосовуваним, щоб уникнути катастрофічної фрагментації й відмов виділення на майже заповнених пулах.
• Історично RAIDZ важко розширювався (зростання RAIDZ vdev шляхом додавання дисків), що штовхало багатьох зробити широкі vdev заздалегідь — чудово в день нуль, напружено на день 900.
• SMR-диски змінили гру: в бенчмарках вони можуть виглядати нормально, а потім провалюватися під постійними випадковими записами, як трафік відновлення.
• OpenZFS став центром гравітації після Sun, з кількома платформами (illumos, FreeBSD, Linux), що несуть факел і розходяться в налаштуваннях.
• Покращення послідовного відновлення з’являлися з часом, щоб зробити деякі патерни швидшими, але вони не виправлять фрагментацію або «пул заповнений на 92%» як життєвий вибір.

План швидкої діагностики: знайти вузьке місце за 10 хвилин

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

Перше: підтвердіть, що реконструкція реальна і подивіться її форму

• Перевірте zpool status щодо швидкості сканування, помилок і чи це resilver чи scrub.
• Підтвердіть, який vdev уражений і чи у вас RAIDZ або mirror.
• Пошукайте прогрес у стилі «resilvered X in Y»; якщо він ледве рухається, ви ймовірно обмежені IOPS або блокуєтесь помилками/повторами.

Друге: ідентифікуйте обмежений ресурс (IOPS, пропускна здатність, CPU або конкуренція)

• Диск зайнятий, але низька пропускна здатність: випадковий I/O / черги / SMR / повторні спроби.
• Високе навантаження CPU у ядрі/потоках ZFS: контрольні суми/шифрування/метадані.
• Спайки затримок у додатках: відновлення конкурує з продукційним I/O; налаштуйте пріоритети або розгляньте зниження навантаження.

Третє: вирішіть щодо безпечного втручання

• Якщо продукція спокійна — трохи підвищте агресивність відновлення і стежте за затримками.
• Якщо продукція страждає — зменште вплив відновлення і прийміть довший термін — якщо ризик не диктує інакше.
• Якщо пристрій видає помилки — припиніть «настройки» і займіться апаратним триажем першочергово.

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

Ось перевірки, які я реально виконую. Кожна включає, що означає вивід і яке рішення з нього випливає.
Команди показані так, ніби ви на Linux з OpenZFS; адаптуйте шляхи, якщо ви на illumos/FreeBSD.

Завдання 1: Підтвердити стан сканування, швидкість і чи це resilver чи scrub

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: DEGRADED
status: One or more devices is being resilvered.
action: Wait for the resilver to complete.
  scan: resilver in progress since Mon Dec 23 09:12:11 2025
        1.87T scanned at 58.3M/s, 612G issued at 19.1M/s, 22.4T total
        102G resilvered, 2.91% done, 5 days 03:18:22 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
            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
            sdcA                    ONLINE       0     0     0
            sdcB                    ONLINE       0     0     0
            sdcC                    ONLINE       0     0     0
            sdcD                    ONLINE       0     0     0
            sdcE                    ONLINE       0     0     0
            sdcF                    ONLINE       0     0     0
            sdcG                    ONLINE       0     0     0
            sdcH                    ONLINE       0     0     0
            sdcI                    ONLINE       0     0     0
            sdcJ                    ONLINE       0     0     0
            sdcK                    ONLINE       0     0     0
            sdcL                    ONLINE       0     0     0
            sdcM                    ONLINE       0     0     0
            sdcN                    ONLINE       0     0     0
            sdcO                    ONLINE       0     0     0
            sdcP                    ONLINE       0     0     0
            sdcQ                    ONLINE       0     0     0
            sdcR                    ONLINE       0     0     0
            sdcS                    ONLINE       0     0     0
            sdcT                    ONLINE       0     0     0
            sdcU                    ONLINE       0     0     0
            sdcV                    ONLINE       0     0     0
            sdcW                    ONLINE       0     0     0
            sdcX                    ONLINE       0     0     0
            sdcY                    ONLINE       0     0     0
            sdcZ                    ONLINE       0     0     0
            sdd0                    ONLINE       0     0     0
errors: No known data errors

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

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

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

cr0x@server:~$ zpool status -x
pool 'tank' is degraded

Що це означає: Пул не здоровий; очікується відновлення. Якщо ви бачите додаткові помилки (READ/WRITE/CKSUM), це більш терміново.

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

Завдання 3: Підтвердити, який диск новий і чи домовився він про швидкість (link speed, size)

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,ROTA,TYPE /dev/sdx
NAME   SIZE MODEL         SERIAL       ROTA TYPE
sdx   14.6T ST16000NM000J ZR12ABCDEF      1 disk

Що це означає: Ви хочете, щоб заміна відповідала очікуваній ємності і була CMR-ентрепрайз моделлю, а не несподіваним SMR-десктоп диском.

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

Завдання 4: Помітити поведінку SMR або глибокі паузи запису за допомогою iostat

cr0x@server:~$ iostat -x 2 5 /dev/sdx
Linux 6.6.0 (server)  12/25/2025  _x86_64_  (32 CPU)

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
sdx              12.0   180.0     1.1     9.4     116.0     27.8   145.2     8.1   154.8   2.9  56.8
sdx              11.5   190.5     1.0     2.2      36.2     64.1   336.7     9.2   356.8   2.7  52.4

Що це означає: Зростаючий await з падінням wMB/s — класична поведінка «диск ставить паузи».
Це не завжди SMR, але часто «прошивка диска виконує реорганізацію записів» або у вас проблема з транспортом/HBA.

Рішення: Якщо замінник має патологічний await, перемістіть його в інший відсік/кабель/порт HBA або замініть модель диска.

Завдання 5: Подивитися, чи відновлення обмежене IOPS по всьому vdev

cr0x@server:~$ iostat -x 2 3
Device            r/s     w/s   rMB/s   wMB/s  avgqu-sz   await  %util
sda              85.0    22.0     5.1     1.2      9.2   86.4   92.0
sdb              82.0    25.0     4.9     1.4      8.7   84.9   90.1
sdc              83.0    23.0     5.0     1.3      9.1   85.7   91.5

Що це означає: Високий %util з низькими MB/s означає, що ви не стрімите; ви шукаєте. Ось чому математика «14TB диск при 250MB/s» провалюється.

Рішення: Не крутіть «регулятори швидкості відновлення» і не очікуйте чудес. Потрібно зменшити випадкове I/O-навантаження (припинити важкі робочі навантаження, зменшити churn зі снапшотами),
або прийняти графік.

Завдання 6: Перевірити тиск ARC і чи система трешається

cr0x@server:~$ arcstat 2 5
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
09:23:01   914   202     22    46   23   156   77     0    0   96G   112G
09:23:03   901   229     25    51   22   178   78     0    0   96G   112G
09:23:05   938   301     32    90   29   211   70     0    0   96G   112G

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

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

Завдання 7: Підтвердити, що не відбувається свопінг (свопінг перетворює відновлення на повільну катастрофу)

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  0      0  82432  12644 9812448   0    0  4920  1280 4200 6100 18 12 58 12  0
 2  0      0  80120  12644 9812016   0    0  5100  1320 4302 6230 17 11 57 15  0

Що це означає: si/so повинні бути нуль. Якщо йде свопінг, обхід метаданих ZFS і робота з контрольними сумами будуть повзти.

Рішення: Якщо відбувається свопінг, зменшіть ARC cap, зупиніть процеси-«поїдачі» пам’яті або перемістіть навантаження. Не говоріть «просто дочекаємося».

Завдання 8: Перевірити, чи одночасно виконується scrub (і зупинити його, якщо це не політика)

cr0x@server:~$ zpool status tank | sed -n '1,20p'
  pool: tank
 state: DEGRADED
  scan: scrub in progress since Mon Dec 23 08:55:02 2025
        3.11T scanned at 72.5M/s, 901G issued at 21.0M/s, 22.4T total
        0B repaired, 4.03% done, 2 days 22:10:05 to go

Що це означає: Scrub, який конкурує з відновленням, зазвичай — самосаботаж, якщо немає конкретної причини.

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

cr0x@server:~$ sudo zpool scrub -s tank
scrub stopped

Завдання 9: Перевірити autotrim і припущення ashift (сюди ховаються провали продуктивності)

cr0x@server:~$ zdb -C tank | egrep -i 'ashift|autotrim'
        ashift: 12
        autotrim: off

Що це означає: ashift визначає вирівнювання секторів. Неправильний ashift може назавжди підірвати продуктивність запису.
autotrim важливий переважно для SSD пулів.

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

Завдання 10: Перевірити властивості на рівні dataset, що посилюють роботу відновлення

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

Що це означає: Малий recordsize, dedup=on та atime=on (для активних datasets) можуть усі збільшити метаданні і роботу при відновленні.

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

Завдання 11: Визначити, чи спеціальний vdev або метадані-пристрої є вузьким місцем

cr0x@server:~$ zpool status tank | sed -n '1,120p'
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Mon Dec 23 09:12:11 2025
config:

        NAME                       STATE     READ WRITE CKSUM
        tank                       DEGRADED     0     0     0
          raidz2-0                 DEGRADED     0     0     0
            sda                    ONLINE       0     0     0
            ...
        special
          mirror-1                 ONLINE       0     0     0
            nvme0n1                ONLINE       0     0     0
            nvme1n1                ONLINE       0     0     0

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

Рішення: Слідкуйте за затримками і станом NVMe; «добрий» data vdev усе ще може повільно відновлюватися, якщо метадані-сайти наситилися або деградували.

Завдання 12: Перевірити помилки I/O і повтори в логах ядра (тихий вбивця)

cr0x@server:~$ sudo dmesg -T | egrep -i 'ata[0-9]|scsi|reset|I/O error|blk_update_request' | tail -n 12
[Tue Dec 23 10:02:14 2025] sd 3:0:8:0: [sdx] tag#83 I/O error, dev sdx, sector 1883742336 op 0x1:(WRITE) flags 0x0 phys_seg 16 prio class 0
[Tue Dec 23 10:02:15 2025] ata9: hard resetting link
[Tue Dec 23 10:02:20 2025] ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 310)

Що це означає: Скидання лінку і знижена швидкість лінку (1.5 Gbps) розтягнуть відновлення до геологічних часових рамок.

Рішення: Виправте кабелі/бекплейн/HBA. Не налаштовуйте ZFS, щоб компенсувати нестабільний транспорт.

Завдання 13: Подивитися, чи ZFS обмежує відновлення через налаштування (і коригувати обережно)

cr0x@server:~$ sudo sysctl -a 2>/dev/null | egrep 'zfs_vdev_resilver|zfs_resilver|scan_idle'
debug.zfs_scan_idle=50
debug.zfs_vdev_resilver_max_active=2
debug.zfs_vdev_resilver_min_active=1

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

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

Завдання 14: Перевірити, що пул не небезпечно заповнений (повні пули відновлюються повільно і винахідливо виходять з ладу)

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint -p tank | head
NAME         USED        AVAIL       REFER       MOUNTPOINT
tank   19854735163392  2533274798080  1048576    /tank

Що це означає: Приблизно 19.8 TB використано, 2.5 TB доступно. На пулі ~22 TB це вже на межі зони ризику.

Рішення: Якщо ви вище ~80–85% і відновлення повільне, пріоритетно звільніть простір (видаліть старі снапшоти, перемістіть холодні дані) перед тим, як налаштовувати швидкість.

Безпечні способи прискорити відновлення (що працює, що не працює)

Мета не «зробити відновлення швидким». Мета — «відновити резервність швидко, не знищивши продукцію або не пошкодивши дані».
Це не те саме. Швидко завжди можна зробити, якщо робити неправильно.

1) Зменшити конкуренцію I/O (непристойно негарна, найефективніша дія)

Якщо відновлення обмежене IOPS, перемога — припинити генерувати випадкове I/O. Зазвичай це означає:

• Призупинити пакетні завдання: бекапи, реіндексацію логів, аналітику, великі rsync.
• Тротлити або перемістити галасливих орендарів (кластерні VM відомі цим).
• Відтермінувати прибирання снапшотів, що спричиняють масові frees/rewrites (залежить від реалізації і навантаження).

Це часто політично важко. Не повинно бути. Деградований пул — це ризикове явище. Ставтеся до нього відповідно.

2) Підвищити агресивність відновлення — обережно і з планом відкату

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

cr0x@server:~$ sudo sysctl -w debug.zfs_scan_idle=0
debug.zfs_scan_idle = 0

Що це означає: Менший idle означає, що сканування частіше не віддає хід нормальному I/O. Відновлення отримує більше «ходів».

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

cr0x@server:~$ sudo sysctl -w debug.zfs_vdev_resilver_max_active=4
debug.zfs_vdev_resilver_max_active = 4

Що це означає: Більше одночасних I/O операцій на vdev. Добре для недовантажених систем, погано для шпинделів, що вже завантажені.

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

3) Помістіть замінник на кращий шлях (HBA, прошивка, кабелі)

Сумна правда: швидкість відновлення часто обмежена одним проблемним лінком. Один диск на 1.5 Gbps SATA або порт HBA, що скидається,
може тягнути одне RAIDZ відновлення вниз, бо реконструкція паритету чекає на відстаючих.

Виправте фізичний шар. Потім налаштовуйте.

4) Віддавайте перевагу дзеркалам, коли час відновлення важливіший за ємність

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

RAIDZ — теж нормальний варіант, але не мати ілюзій: це інша істота в час відновлення.

5) Тримайте пули менш заповненими (ваше майбутнє «я» скаже дякую)

Найпростіший спосіб пришвидшити відновлення — уникати патологічної фрагментації. Найнадійніший предиктор фрагментації в ZFS:
наскільки близько до повного ви тримаєте пул.

Встановлюйте квоти. Дотримуйтесь плану ємності. «Ми приберемо пізніше» — шлях до 5-денних відновлень і засідань о 2:00 ночі.

6) Використовуйте розумні розміри блоків для навантаження (перед інцидентом, не під час)

Для VM stores обирайте volblocksize свідомо. Для dataset — recordsize, вирівняний з навантаженням. Це не про мікрооптимізацію для бенчмарків;
це про зменшення метаданих і кількості блоків, щоб робота відновлення масштабувалася розумно.

7) Не «оптимізуйте», відключаючи контрольні суми або вірячи у магію

Контрольні суми — не опціональні ремені безпеки. Саме при відновленні вам потрібна цілісність кінця в кінець.
ZFS не дає підтримуваного розумного шляху «пропустити верифікацію заради швидкості», і це не недолік, а особливість.

Жарт №2: Крутити ручки під час відновлення без вимірювань — як додавати більше кави, щоб полагодити зламаний принтер — емоційно заспокоює, технічно не пов’язано.

Одна цитата, яку варто пам’ятати під час інциденту

«Надія — не стратегія.» — перефразована ідея, часто цитована в інженерії та експлуатації

Операційна версія: спочатку вимірюйте, змініть одну річ, виміряйте знову. Все інше — перформанс-косплей.

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

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

Середня SaaS-компанія працювала з ZFS-backed VM кластером на широкому RAIDZ2 vdev. Він «працював нормально» роками. Один диск впав у вівторок.
On-call швидко поміняв його і почав replace. Всі розслабилися.

Припущення: «Відновлення копіює тільки використані дані, тож буде швидше за повне відновлення.» Пул був близько 60% заповнений.
Вони зробили класичні підрахунки на серветці, використовуючи послідовну швидкість, і вирішили, що все завершиться за ніч.

Ніч пройшла, прогрес застряг в одно-цифрових відсотках. Латентність для клієнтських VM періодично підскакувала, і гіпервізор почав логувати таймаути I/O гостей.
Команда відреагувала, додавши більше навантаження — зокрема, міграції VM, щоб «збалансувати». Міграції були випадковими читаннями і записами. Це підлило оливи у вогонь.

Справжня проблема: пул був старий, з великою кількістю снапшотів і сильно фрагментований. Відновлення було обмежене IOPS, а не пропускною здатністю. Кожне «швидке» рішення робило патерн гіршим.
Через 36 годин другий диск почав давати помилки. Тепер це вже не повільне відновлення; це інцидент з ризиком втрати даних.

Вони відновилися, але урок закарбувався: час відновлення — це не функція лише «використаних ТБ». Це функція історії виділення, форми навантаження і конкуренції.
Післямова включала прості і неприємні пункти: забезпечити резерв ємності, обмежити кількість снапшотів і припинити будувати широкі RAIDZ vdev для latency-sensitive VM кластерів.

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

Інша організація вирішила, що відновлення займають забагато часу. Хтось знайшов налаштування в інтернеті і агресивно підняв конкуренцію сканування/відновлення по всьому флоту.
У тихих стендових середовищах це виглядало чудово: відновлення стали швидшими. Всі похлопали один одному по спині. Зміни розгорнули.

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

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

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

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

Фінансова компанія (так, та, що любить change control) використовувала mirrored vdev для критичних dataset і RAIDZ для холодніших шарів.
Вони також дотримувалися простої політики: пули залишаються під визначеним порогом заповнення, а зберігання снапшотів обмежене регулярним прибиранням.

Диск впав під час закриття кварталу. Звісно. On-call замінив його, і відновлення почалося. Вони не чіпали налаштувань спочатку.
Натомість виконали runbook: призупинити неважливі пакетні джоби, перевірити, що scrub не йде, перевірити швидкість лінку, dmesg на предмет скидань і спостерігати панелі латентності.

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

«Нудна» робота була зроблена місяці раніше: резерв ємності, розумна конструкція vdev і операційна дисципліна.
Це той тип історії про надійність, який ніхто не розповідає на конференціях, бо він не підходить для футболки. Але це саме те, що вам потрібно.

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

1) Симптом: Швидкість відновлення початкова добра, потім колапсує

Коренева причина: Внутрішня пауза запису замінного диска (часто SMR або GC прошивки), або переговори лінку вниз, або пул зайшов у більш фрагментовані регіони.

Виправлення: Перевірте iostat -x на зростання await і падіння MB/s; перевірте dmesg на скидання/швидкість лінку. Замініть порт/кабель/HBA або модель диска.

2) Симптом: «Scanned» швидко росте, «issued» мізерний

Коренева причина: Обхід метаданих з малою фактичною реконструкцією, часто через фрагментацію і багато снапшотів; інколи — через throttling налаштування.

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

3) Симптом: Додатки таймаутять під час відновлення, хоча пропускна здатність не висока

Коренева причина: Скачок хвостової латентності через конкуренцію випадкового I/O; кілька черг насичені, тоді як середня пропускна здатність виглядає скромною.

Виправлення: Слідкуйте за await, глибиною черги та p99 затримкою додатків. Зменшіть навантаження або підвищте idle відновлення, щоб віддати пріоритет продукції.

4) Симптом: Відновлення ніколи не закінчується; прогрес повзе і потім «перезапускається»

Коренева причина: Флаппінг пристрою, транзитні відключення або повторні помилки, що змушують повтори; інколи маргінальний бекплейн.

Виправлення: Перевірте лічильники помилок zpool status; інспектуйте dmesg. Виправте апарат. Жоден налаштування не компенсує кабель, що вас ненавидить.

5) Симптом: CPU завантажений під час відновлення на «I/O системі»

Коренева причина: Робота з контрольними сумами/шифруванням на багатьох дрібних блоках плюс метадані. Може посилюватися dedup.

Виправлення: Підтвердьте за top/vmstat і ARC-статами; зменшіть churn дрібних блоків (припиніть міграції VM) і плануйте оновлення CPU для зашифрованих пулів.

6) Симптом: Відновлення повільне лише на одному пулі, не на інших на тому ж обладнанні

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

Виправлення: Порівняйте zfs list використання, кількість снапшотів і властивості dataset. Обладнання не «повільне» — ваша історія алокації.

7) Симптом: Швидкість відновлення покращилася після «налаштування», потім пул став дивним

Коренева причина: Постійні зміни sysctl/налаштувань, застосовані глобально без обмежень; підвищений I/O спричиняє таймаути і вторинні відмови.

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

Чек-листи / поетапний план

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

1. Підтвердіть стан: zpool status. Переконайтеся, що це відновлення, а не scrub, і визначте уражений vdev.
2. Зупиніть конкуренцію по обслуговуванню: Якщо scrub йде — зупиніть його, якщо це не вимога політики прямо зараз.
3. Аппаратна санітарія: Перевірте модель замінника (CMR vs SMR), швидкість лінку і відсутність скидань у dmesg.
4. Виміряйте конкуренцію: iostat -x і панелі латентності додатків. Вирішіть, чи є запас, щоб трохи підштовхнути відновлення.
5. Перевірте тиск пам’яті: vmstat і ARC-стати. Переконайтеся, що немає свопінгу.
6. Визначте пріоритет: Якщо ризик високий (другий диск хиткий, критичні дані), пріоритет — відновлення. Якщо робочі години критичні — віддавайте перевагу SLO.
7. Застосовуйте налаштування обережно (опціонально): Підвищуйте агресивність відновлення невеликими кроками, моніторячи p95/p99 затримку.
8. Комунікуйте: Повідомте очікування. «Деградовано до X» — це бізнес-ризик, а не технічний факт для гіків.
9. Після завершення: Перевірте, що пул здоровий, потім відкотіть тимчасові налаштування. Заплануйте scrub після відновлення резервності.

Чек-лист: безпечні пришвидшення, які можна виправдати у постмортемі

• Призупинити неважливі пакетні I/O і завдання, що споживають снапшоти.
• Зупинити одночасні scrubs під час відновлення (якщо тільки комплаєнс не вимагає інакше).
• Виправити транспортні проблеми (скидання лінку, знижені SATA-режими) перед налаштуваннями.
• Підвищувати конкуренцію відновлення помірно лише коли диски мають запас і латентність додатків стабільна.
• Тимчасово зменшити idle сканування лише в контрольованому вікні інциденту.
• Віддавати перевагу дзеркалам для шарів, де ризик відновлення важливіший за ємність.
• Підтримувати резерв ємності політикою, а не пропозицією.

Чек-лист: чого не робити під час відновлення

• Не вмикайте dedup «щоб заощадити місце» під час інциденту.
• Не починайте великі міграції, ребалансинг або масові перезаписи, якщо ви не свідомо обмінюєте час відновлення на більший ризик.
• Не продовжуйте нарощувати налаштування, коли латентність вже погана; ви просто робите відмову гучнішою.
• Не ігноруйте логи ядра. Якщо бачите скидання або помилки I/O — ви вже у сфері апаратури.

FAQ

1) Чи має відновлення бути швидшим за scrub?

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

2) Чому «scanned» не збігається з «resilvered»?

«Scanned» відображає, скільки процес сканування пройшов через вказівники блоків і метадані пулу.
«Resilvered» — це фактичні реконструйовані дані, записані на замінник. Багато сканування з малим «resilvered» зазвичай означає роботу, тяжку на метадані, або throttling/IOPS обмеження.

3) Чи копіює ZFS відновлення лише використаний простір?

ZFS прагне відновлювати лише алоковані (referenced) блоки, а не весь сирий пристрій. Ось чому вільний простір не завжди коштує часу.
Але «алоковані блоки» можуть бути розкидані у мільйони дрібних екстентів, що робить операцію повільною.

4) Чи можна призупинити і відновити відновлення пізніше?

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

5) Чи слід запускати scrub відразу після заміни диска?

Зазвичай: спочатку відновлення, потім scrub. Поки пул деградував, ви хочете якнайшвидше відновити резервність.
Після завершення відновлення і перевірки здоров’я пулу scrub — гарне продовження для валідації цілісності; заплануйте його на низьке навантаження.

6) Який єдиний найбезпечніший спосіб скоротити час відновлення?

Зменшити конкуренцію I/O і тримати пули менш заповненими. Налаштування допомагають на краях; базове визначає навантаження і фрагментацію.
«Найбезпечніше» пришвидшення — прибрати тиск з пулу, щоб відновлення могло використовувати IOPS, не шкодячи продукції.

7) Чи завжди дзеркала кращі за RAIDZ для відновлення?

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

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

Така сама ємність — не означає така сама продуктивність. Ви могли ввести SMR-поведінку, нижчі стійкі швидкості запису, гіршу прошивку під випадкові записи або лінк, що домовився на нижчій швидкості.
Перевірте модель і транспортні помилки.

9) Чи робить стиснення відновлення швидшим чи повільнішим?

Зазвичай швидше для I/O-обмежених систем, бо менше байтів рухається. Може бути повільніше, якщо CPU стає вузьким місцем, особливо з шифруванням і дрібними блоками.
Вимірюйте CPU під час відновлення; не робіть припущень.

10) Якщо відновлення повільне, чи під загрозою мої дані?

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

Наступні кроки, які можна зробити сьогодні

Якщо ви зараз у середині болісно повільного відновлення, зробіть це по порядку:

1. Запустіть zpool status і підтвердіть, що ви випадково не робите scrub під час деградації.
2. Перевірте dmesg на предмет скидань лінку і помилок I/O; виправте фізичні проблеми перш ніж чіпати налаштування ZFS.
3. Використайте iostat -x, щоб вирішити, чи ви обмежені IOPS або пропускною здатністю.
4. Зменшіть конкуренцію I/O: призупиніть бекапи, міграції, пакетні джоби і будь-який інтенсивний churn снапшотів.
5. Якщо латентність дозволяє, помірно налаштуйте агресивність відновлення і моніторьте p95/p99 затримки; відкатайте після відновлення пулу.

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