ZFS проти btrfs: де btrfs зручний, а де підводить

Моя позиція: де я що розгортаю

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

Якщо вам потрібна щільна інтеграція з Linux, легкі знімки root‑файлової системи, швидка ітерація і ви готові вивчити режими відмов btrfs:
btrfs справді зручний — особливо для робочих станцій, машин для збірки та деяких однодомових сервісів з добрими бекапами.

Якщо ви думаєте «я зроблю btrfs RAID5/6, бо це вбудовано й зручно», не робіть так. Використовуйте mdraid під ним, або ZFS, або
апаратний RAID, якщо мусите (і приймаєте компроміси). btrfs RAID5/6 покращився з роками, але все ще має достатньо застережень:
ставтеся до нього як до експериментального ліки — тільки з усвідомленою згодою і другою думкою.

Цікаві факти та історичний контекст (те, що пояснює сучасні гострі кути)

• ZFS розпочався в Sun Microsystems як інтегрований менеджер томів + файлова система, задуманий щоб усунути тиху корупцію і проблеми «RAID write hole».
• btrfs створили в Oracle як файлову систему наступного покоління для Linux з пулінгом, знімками та контрольними сумами, з подібними цілями, але в екосистемі Linux.
• ZFS на Linux став OpenZFS, крос‑платформним проєктом, який стандартизував можливості та поведінку на illumos, Linux та інших платформах.
• btrfs увійшов до ядра Linux і розвивався публічно, що добре для доступності, але також означає, що ви успадковуєте версії ядра + інструментів як частину операційної реальності.
• Copy-on-write — спільний інгредієнт, але транзакційні групи ZFS та B‑дерева й стратегії алокації btrfs приводять до різної фрагментації й патернів затримок.
• ZFS має сильну репутацію щодо scrub/resilver, включно з «ремонтом через надлишковість», який простіший, коли дзеркала/RAIDZ налаштовані правильно.
• btrfs RAID1 не є «двохдисковим RAID1» у класичному сенсі; це «дві копії по пристроях» на рівні chunk, і ця нюансність важлива для ємності та очікувань при відмові.
• Ліцензування ZFS (CDDL) не дозволило включити його в ядро Linux, що впливає на пакування й інтеграційні рішення в підприємствах.
• btrfs send/receive дозрів разом із workflow, що тяжіє до знімків (думаємо: майже незмінні розгортання ОС і швидкий відкат), через що деякі дистрибутиви люблять його для root‑файлових систем.

Ментальні моделі, що запобігають помилкам

1) ZFS хоче контролювати історію блочних пристроїв

ZFS очікує бачити диски (або партиції) і управляти надлишковістю, кешуванням і цілісністю end‑to‑end. Ви можете накладати його
поверх апаратного RAID, але тоді ви свідомо позбавляєте ZFS видимості на поведінку окремих дисків і ускладнюєте своє життя,
коли щось іде не так. Найкращі можливості ZFS проявляються, коли ZFS має реальну видимість.

2) btrfs прагне бути «файловою системою Linux, що багато чого вміє»

btrfs в ядрі, добре взаємодіє з systemd‑інструментами, інсталяторами дистрибутивів і workflow знімків root‑файлової системи. Воно також
щасливіше, коли його використовують як файлову систему насамперед. Менеджмент томів потужний, але не завжди те місце, де варто ризикувати.

3) Обидві — CoW; обидві можуть карати «випадкові перезаписи в масштабі»

Бази даних, VM‑образи та інтенсивні журнальні навантаження можуть викликати write amplification і фрагментацію в будь‑якій CoW‑системі.
ZFS має регульовані параметри як recordsize, logbias, спеціальні vdev‑и та зрілу історію ARC/L2ARC. btrfs має
опції стиснення, параметри монтування і можливість відключити CoW для файлу (chattr +C). Безкоштовного обіду не існує.

Один перефразований вислів від John Allspaw: надійність походить від підходу до операцій як до задачі проєктування, а не як до гасіння пожеж.

Де btrfs відчувається зручно

Знімки root‑файлової системи, що не здаються науковим проєктом

btrfs фантастичний, коли ваша ОС — набір субвольюмів і знімки — частина щоденного життя. Відкат після невдалого оновлення пакета?
Легко. Створити тимчасове тестове середовище шляхом знімка @home або дерева збірки? Легко.

Дистрибутиви, що роблять ставку на btrfs, роблять це не заради новизни. Вони прагнуть атомарних оновлень і швидких відкатів без додаткового
менеджера томів. У реальному світі «я можу швидко відкотитися» — це фіча для доступності.

Send/receive зручний для багатьох workflow

btrfs send/receive — практичний примітив реплікації. Для цілей бекапу, лабораторій або налаштувань «відправляти знімки на інший сервер»
це доступно і достатньо швидко. Можна прикрутити до таймерів, робити просте збереження політик і рухатися далі по своїх справах.

Онлайн‑збільшення і керування пристроями без перекроювання всього стека

Додавання диска, видалення диска, конвертація профілів (наприклад single → RAID1), онлайн‑зміна розмірів — btrfs дає інструменти для цього
без примусу до окремого LVM‑шару. Це зручно, коли ви керуєте флотом невеликих нод, що змінюють форму.

Стиснення, яке зазвичай «варте того»

Прозоре стиснення (особливо zstd) — тихий суперсила. Воно може зменшити I/O записів і продовжити ресурс SSD. На змішаних навантаженнях
це часто виграш. На вже стиснених даних — марна трата CPU, тому міряйте, а не вмикайте на відчування.

Субвольюми корисні в операціях

Субвольюми поводяться як окремі файлові системи для знімків і квот, але ділять той самий пул. Це полегшує ізоляцію політик збереження:
тримайте агресивні знімки для @, менше для @var, і обробляйте директорії з великим обміном окремо.

Жарт №1: субвольюми btrfs роблять вас організованими — аж поки ви не зрозумієте, що політика збереження знімків перетворилася на музейну експозицію.

Де btrfs підводить (і чому)

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

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

Виправлення зазвичай — комбінація очищення знімків, запуск цілеспрямованого balance і іноді конвертації профілів метаданих.
Профілактика — моніторинг btrfs filesystem df і збереження запасу вільного простору.

Balance — це інструмент обслуговування, а не магічна кнопка «дефрагментуй моє життя»

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

RAID‑семантика може здивувати людей, які вчили RAID у 2005

btrfs RAID1 — це реплікація на рівні чанків, а не обов’язково симетричне «половина ємності» дзеркалу у всіх умовах відмови. RAID10 має
свої власні реалізації. А RAID5/6 — це зона, де слід бути максимально обережним: саме тут з’являються крайові випадки і складні шляхи відновлення,
і те, що «працювало в тесті», може перетворитися на «чому scrub знайшов некоректовані помилки».

Фрагментація та CoW‑ампліфікація: VM‑образи та бази даних — звичні жертви

CoW чудовий, поки ви не перезаписуєте великі файли in‑place знову і знову (QCOW2 образи, файли баз даних, поштові спули). btrfs справляється,
але часто потрібно відключити CoW для певних шляхів, вибрати правильні опції монтування і уникати знімання високочастотних файлів без плану.

Інструменти відновлення покращуються, але інколи все ще нагадують печерні роботи

Коли btrfs здоровий — приємно. Коли ні — ви проведете час з btrfs check попередженнями, режимами рятування і дуже
обережними рішеннями про те, чи намагатися ремонтувати офлайн. Інструментарій реальний, але крива довіри оператора крутіша.

Жарт №2: «Немає місця на пристрої» у btrfs іноді означає «місце є, але воно в метаданих, а метадані емоційні».

Де ZFS перемагає, прямо

Передбачувана модель цілісності: контрольні суми, scrub, самовідновлення (якщо є надлишковість)

Фірмовий аргумент ZFS — це end‑to‑end контрольні суми з автоматичним ремонтом за рахунок надлишковості. Scrub — першокласна функція.
Коли диск бреше або кабель мигтить, ZFS із більшою ймовірністю скаже вам чітко, що сталося і що було зроблено.

Операційна ясність: пул, vdev‑и і правила, які можна показово навчити

ZFS змушує думати у термінах vdev. Звучить нудно, поки ви не опинилися на виклику. Модель послідовна: mirrors — дзеркалить, RAIDZ — RAIDZ,
і у вас немає «майже‑так» для макетування. Така жорсткість запобігає багатьом творчим катастрофам.

ARC/L2ARC і SLOG — зрілі та добре зрозумілі

Кешування ZFS не магічне, але узгоджене. Налаштування ARC, спеціальні vdev‑и для метаданих/малих блоків і окремі пристрої журналу мають багато
операційного фольклору — іншими словами, багато людей вже зробили помилки замість вас.

Реплікація — «нудна» у хорошому сенсі

zfs send/receive — відточена. Інкрементальні стріми надійні. Краї випадків відомі. Якщо ви побудували політику знімків і збереження, вона, як правило,
працює, поки ви не зміните щось велике (наприклад recordsize чи шифрування) без роздумів.

Компроміс: ZFS важчий і більше «про стек зберігання»

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

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

Підбір під навантаження важливіше за мікрооптимізації

Почніть з патерну доступу. Великі послідовні записи? Випадкові синхронні записи? Мільйони дрібних файлів? VM‑образи? Ваш вибір файлової системи
й налаштувань повинен відповідати реальності. Якщо ви не знаєте реальність — виміряйте її спочатку. Вгадування — шлях до «оптимізації»
неправильного шару.

Ручки btrfs, що змінюють результати

• Стиснення: compress=zstd часто виграш; тестуйте витрати CPU. Для відлагодження чутливих до затримки навантажень
  розгляньте compress=zstd:1.
• NOCOW для файлів, що часто перезаписуються: встановіть chattr +C на директорії для VM‑образів/баз даних (і переконайтесь, що жодні знімки не залежать від семантики CoW там).
• Autodefrag: допомагає при деяких дрібних випадкових навантаженнях; може зашкодити при великих послідовних I/O. Використовуйте обережно і валідуйте.
• Кешування простору/дерево вільного простору: сучасні ядра краще це обробляють; несумісні версії інструментів все ще можуть створювати дивні ефекти після апгрейдів.

Ручки ZFS, що змінюють результати

• recordsize: підбирайте під навантаження. Великі файли хочуть більший recordsize; бази даних часто потребують менших блоків.
• Стиснення: lz4 — «за замовчуванням розумне»; іноді zstd вартий уваги, якщо підтримується і є CPU
• sync behavior: не вимикайте синхронні записи, щоб «стати швидше», якщо ви не готові втратити дані, які вважали безпечними.
• special vdev: може змінити поведінку метаданих важких навантажень, але це також проєктне зобов’язання: його втрата може втратити pool.

Нотатка про SSD, TRIM і write amplification

Обидва стеки потребують розумної поведінки discard/TRIM. Занадто агресивно — може нашкодити затримкам; занадто рідко — погіршити довготривалу продуктивність.
Для ZFS періодичний trim і якість прошивки пристроїв мають значення. Для btrfs вибір між опціями discard при монтуванні і періодичним fstrim
— це тюнінгова опція, яку слід виміряти на вашому обладнанні.

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

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

Завдання 1: швидка перевірка стану btrfs

cr0x@server:~$ sudo btrfs filesystem show
Label: 'rootfs'  uuid: 6d3b3fe1-0a9e-4e8d-9bf0-73a55c6a8f2f
	Total devices 2 FS bytes used 412.31GiB
	devid    1 size 931.51GiB used 520.00GiB path /dev/nvme0n1p2
	devid    2 size 931.51GiB used 520.00GiB path /dev/nvme1n1p2

Що це означає: пристрої, розміри і «used» на рівні алокації чанків, а не те саме, що df.

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

Завдання 2: btrfs — використання даних vs метаданих (класичний детектор пастки)

cr0x@server:~$ sudo btrfs filesystem df /
Data, RAID1: total=480.00GiB, used=402.10GiB
Metadata, RAID1: total=16.00GiB, used=15.72GiB
System, RAID1: total=32.00MiB, used=16.00KiB

Що це означає: метадані майже заповнені. Так ви отримуєте ENOSPC з вільним простором для даних.

Рішення: призупиніть створення знімків, видаліть старі знімки, потім запустіть цілеспрямований balance для метаданих (не повний).

Завдання 3: цілеспрямований btrfs balance при навантаженні на метадані

cr0x@server:~$ sudo btrfs balance start -musage=50 /
Done, had to relocate 12 out of 32 chunks

Що це означає: він перемістив метадані‑чанки, що були менш ніж на 50% заповнені, консолідувавши і звільнивши місце.

Рішення: перевірте btrfs filesystem df. Якщо ще тісно — повторіть із трохи вищим порогом або зменшіть кількість знімків і дрібнофайловий churn.

Завдання 4: статус scrub в btrfs і що означає «corrected»

cr0x@server:~$ sudo btrfs scrub status /
UUID:             6d3b3fe1-0a9e-4e8d-9bf0-73a55c6a8f2f
Scrub started:    Sat Dec 21 02:11:03 2025
Status:           finished
Duration:         0:32:44
Total to scrub:   410.23GiB
Rate:             213.45MiB/s
Error summary:    read=0, csum=2, verify=0, corrected=2, uncorrectable=0

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

Рішення: сприймайте corrected як сигнал обладнання. Перевірте SMART, кабелі/бэкплейн та журнали ядра; не просто святкуйте і забувайте.

Завдання 5: постійні лічильники пристроїв у btrfs

cr0x@server:~$ sudo btrfs device stats /
[/dev/nvme0n1p2].write_io_errs   0
[/dev/nvme0n1p2].read_io_errs    0
[/dev/nvme0n1p2].flush_io_errs   0
[/dev/nvme0n1p2].corruption_errs 2
[/dev/nvme0n1p2].generation_errs 0
[/dev/nvme1n1p2].write_io_errs   0
[/dev/nvme1n1p2].read_io_errs    0
[/dev/nvme1n1p2].flush_io_errs   0
[/dev/nvme1n1p2].corruption_errs 0
[/dev/nvme1n1p2].generation_errs 0

Що це означає: на одному шляху пристрою сталися помилки корупції.

Рішення: запустіть розширені тести SMART і перегляньте dmesg на предмет NVMe‑ресетів; плануйте проактивну заміну, якщо це повторюється.

Завдання 6: Вимкнути CoW для директорії з VM‑образами (btrfs)

cr0x@server:~$ sudo mkdir -p /var/lib/libvirt/images
cr0x@server:~$ sudo chattr +C /var/lib/libvirt/images
cr0x@server:~$ lsattr -d /var/lib/libvirt/images
---------------C------ /var/lib/libvirt/images

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

Рішення: робіть це перед створенням великих файлів; існуючі файли не перепишуться автоматично. Також: не робіть знімків цих образів, розраховуючи на ефективність CoW.

Завдання 7: список субвольюмів btrfs і рішення щодо збереження знімків

cr0x@server:~$ sudo btrfs subvolume list -t /
ID 256 gen 19234 top level 5 path @
ID 257 gen 19233 top level 5 path @home
ID 890 gen 19110 top level 256 path .snapshots/2025-12-01
ID 891 gen 19140 top level 256 path .snapshots/2025-12-02
ID 892 gen 19170 top level 256 path .snapshots/2025-12-03

Що це означає: знімки накопичуються швидко; кожен фіксує extents і може збільшувати тиск на метадані.

Рішення: встановіть політику збереження, яку можете обґрунтувати (щодня 7–14 днів, щотижня кілька тижнів), і примусово її виконувати.

Завдання 8: стан пулу ZFS і триаж помилок

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.
action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear'.
  scan: scrub repaired 0B in 0 days 00:41:12 with 0 errors on Sat Dec 21 03:02:11 2025
config:

	NAME                         STATE     READ WRITE CKSUM
	tank                         ONLINE       0     0     0
	  mirror-0                   ONLINE       0     0     0
	    ata-SAMSUNG_SSD1         ONLINE       0     0     1
	    ata-SAMSUNG_SSD2         ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
/tank/vmstore/qemu/win10.qcow2

Що це означає: ZFS виявив помилку контрольної суми, прив’язану до файлу. Це золото для інцидент‑респонсу.

Рішення: відновіть/відремонтуйте уражений файл з бекапу; запустіть SMART на диску з інкрементом CKSUM; розгляньте заміну.

Завдання 9: властивості dataset ZFS, що часто пояснюють продуктивність

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

Що це означає: ці налаштування часто різниця між «нормально» і «чому мої VM підгальмовують».

Рішення: для VM‑образів розгляньте менший recordsize і, можливо, logbias=throughput в залежності від синхронного патерну; змінюйте лише після вимірювань.

Завдання 10: перевірка тиску ARC у ZFS

cr0x@server:~$ sudo arcstat -f time,read,miss,arcsz,c
    time  read  miss   arcsz      c
03:12:01   842    71   19.2G   24.0G
03:12:02   901    88   19.2G   24.0G
03:12:03   877    92   19.2G   24.0G

Що це означає: розмір ARC (~19G) проти цілі (~24G), пропуски зростають. Якщо misses високі під стабільним навантаженням,
можливо, бракує RAM.

Рішення: додайте RAM або відрегулюйте навантаження/налаштування dataset; не поспішайте додавати L2ARC без розуміння робочого набору.

Завдання 11: scrub у ZFS і що робити з результатами

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Sat Dec 21 03:20:10 2025
	12.3G scanned at 1.02G/s, 1.4G issued at 118M/s, 480G total
	0B repaired, 0.29% done, 1:17:44 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 йде; «repaired» і «errors» — ключові рядки для цілісності.

Рішення: якщо бачите repairs або CKSUM‑помилки, корелюйте з SMART і плануйте заміну пристрою; якщо чисто — рухайтеся вгору по стеку.

Завдання 12: btrfs — виявити, чи вільний простір фрагментований по чанках

cr0x@server:~$ sudo btrfs filesystem usage -T /
Overall:
    Device size:                   1.82TiB
    Device allocated:              1.04TiB
    Device unallocated:          816.00GiB
    Device missing:                  0.00B
    Used:                        824.20GiB
    Free (estimated):            496.10GiB      (min: 248.05GiB)
    Data ratio:                       2.00
    Metadata ratio:                   2.00
    Global reserve:               512.00MiB      (used: 0.00B)

Що це означає: «Free (estimated)» проти «min» показує невизначеність через алокацію чанків; «min» — консервативне число.

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

Завдання 13: ZFS — ідентифікувати, який dataset споживає місце і знімки

cr0x@server:~$ sudo zfs list -o name,used,avail,refer,usedbysnapshots -S used
NAME                USED  AVAIL  REFER  USEDBYSNAPSHOTS
tank                3.21T  5.07T   192K            0B
tank/vmstore        1.84T  5.07T  1.02T          820G
tank/backups        1.12T  5.07T  1.10T          18G
tank/home           256G  5.07T   241G          15G

Що це означає: знімки фіксують 820G у tank/vmstore.

Рішення: відрегулюйте політику знімків або виключіть датасети з великою волатильністю VM зі строгих графіків; розгляньте частоту реплікації окремо.

Завдання 14: btrfs — замінити дефектний пристрій (концептуальний хід «зробіть це до того, як він помре»)

cr0x@server:~$ sudo btrfs replace start /dev/nvme1n1p2 /dev/nvme2n1p2 /
Started on Sat Dec 21 03:40:11 2025, estimated time: 2:10:00
cr0x@server:~$ sudo btrfs replace status /
Status: finished

Що це означає: btrfs скопіював дані на замінний пристрій онлайн.

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

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

По‑перше: вирішіть, чи це ємність/метадані, цілісність чи затримки

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

По‑друге: перевірте «свою правду» шару зберігання

Для btrfs: btrfs filesystem df, btrfs filesystem usage -T, btrfs scrub status і журнали ядра.
Для ZFS: zpool status -v, zpool iostat -v 1 і властивості датасетів.

По‑третє: ізолюйте, чи ви обмежені CPU, RAM чи пристроями

• Високий iowait + низька завантаженість диска: часто чергам, проблемам прошивки/контролера або затримкам sync.
• Високий CPU у kswapd або пам’ятевий тиск: розмір ARC у ZFS або загальний дефіцит RAM.
• Один пристрій насичений: нерівномірна алокація/balance у btrfs або вузьке місце дизайну ZFS vdev (один повільний диск отруює затримки дзеркала/RAIDZ).

По‑четверте: тільки тоді налаштовуйте

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

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

1) «Немає місця на пристрої», хоча є сотні GiB вільних

Симптом: створення знімка не вдається, записи падають, видалення іноді не проходить.

Корінна причина: метадані btrfs заповнені; вільний простір заблокований в data‑чанках або погано розподілений по пристроях.

Виправлення: видаліть знімки, зменшіть churn, запустіть btrfs balance start -musage=50 (або подібне) і моніторте btrfs filesystem df. Тримайте запас.

2) Ігнорування «scrub corrected errors»

Симптом: поодинокі corrected checksum‑помилки під час scrub; система здається працюючою інакше.

Корінна причина: нестабільність пристрою або шляху: ненадійний NVMe, кабелі, HBA, бэкплейн або баги прошивки.

Виправлення: сприймайте corrected як попередження. Запустіть SMART‑тести, перевірте dmesg, розгляньте проактивну заміну.

3) Падіння продуктивності btrfs після періоду з інтенсивними знімками

Симптом: зростає випадкова write‑латентність, повільні операції з метаданими, збільшуються часи commit.

Корінна причина: фрагментація + pinned extents від багатьох знімків, плюс накладні витрати на метадані.

Виправлення: скоротіть політику знімків; винесіть дані з високим churn в NOCOW‑директорії або окремі субвольюми, які рідко знімкуються.

4) «Оптимізація» ZFS шляхом вимкнення sync, потім втрата даних після відключення живлення

Симптом: навантаження швидке; після падіння/втрати живлення база даних або VM‑образ пошкоджуються.

Корінна причина: sync=disabled (або додаток залежить від fsync) порушило гарантії довговічності.

Виправлення: встановіть sync=standard (або always там, де потрібно), використайте SLOG, якщо проблема — затримка sync.

5) Припущення «btrfs RAID1 означає я можу втратити будь‑який диск коли завгодно»

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

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

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

6) Проєкт ZFS з одним широким RAIDZ vdev для випадкового I/O

Симптом: жахливі випадкові IOPS у порівнянні з очікуваннями.

Корінна причина: vdev — це одиниця IOPS; один великий RAIDZ vdev має обмежені IOPS порівняно з кількома дзеркалами.

Виправлення: для IOPS‑інтенсивних навантажень віддавайте перевагу дзеркальним vdev (striped mirrors) або більшій кількості vdev; не очікуйте, що ширина RAIDZ створить IOPS.

Три корпоративні міні‑історії (анонімні, правдоподібні й болісно знайомі)

Історія 1: інцидент через хибне припущення

Середня SaaS‑компанія перенесла build‑агенти на btrfs, бо знімки полегшували очищення. Кожна збірка запускалась у тимчасовому знімку,
потім відкотувалась. Команді це сподобалось. Сховище залишалось чистим. Розгортання прискорились.

Потім кластер збірки почав падати з «Немає місця на пристрої». df -h показував сотні гігабайтів вільних. На чергуванні
припустили, що це проблема overlay контейнера і перезапустили купу агентів, що допомогло рівно на нуль відсотків.

Хибне припущення: «вільний простір — це вільний простір». У btrfs метадані можуть бути вашим реальним обмеженням. У них було велике
число дрібних файлів плюс агресивна політика знімків «на всякий випадок», і метадані в RAID1‑чанках були насичені.

Виправлення не було героїчним. Видалили старі знімки, запустили цілеспрямований metadata balance і зменшили частоту знімків.
Також вони винесли кеші артефактів збірки в окремий субвольюм, який взагалі не знімкувався. Кластер знову став нудним.

Урок: btrfs дружній, поки ви не почнете ставитися до нього як до ext4 з суперсилами. Це не так. Слідкуйте за метаданими як за ресурсом першої черги.

Історія 2: оптимізація, що обернулась фіаско

Компанія з фінансовими нахилами використовувала ZFS для зберігання VM. Хтось помітив затримки sync‑записів і запропонував класичне «тимчасове»
рішення: поставити sync=disabled на VM‑dataset. Графіки одразу покращились. Люди потиснули руки. Було створено тікет «переглянути пізніше».
Тікет прожив довге і поважне життя у беклозі.

За кілька тижнів сталася подія з живленням — нічого драматичного, просто PDU перезавантажився довше, ніж очікували. Декілька VM повернулись
з пошкодженими файловими системами. Одна база даних стартувала, але мала тихі невідповідності даних, що виявились як помилки додатку — найгірший варіант.

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

Виправлення було дорогим: відновлення з бекапів, валідація даних і відновлення довіри. Насправді ж рішення для продуктивності було нудним:
невеликий надійний SLOG‑пристрій для синхронних dataset і налаштування recordsize для VM‑навантаження. Затримка зменшилась без азарту щодо надійності.

Урок: «виграші» продуктивності, що міняють семантику довговічності, — це ставки, а не оптимізації. Продакшн пам’ятає ваші ставки.

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

Компанія, пов’язана з охороною здоров’я, керувала кластером ZFS зі строгою рутиною: щотижневі scrubs, алерти при будь‑якому інкременті контрольних сум
і політика «corrected errors потребують тікета». Люди закочували очі, бо більшість тижнів нічого не траплялося.

Один scrub зафіксував невелику кількість corrected errors на одному диску в дзеркальному vdev. Система залишилась онлайн; користувачі нічого не помітили.
На чергуванні відкрили обов’язковий тікет і запланували вікно для заміни диска.

Під час заміни виявили диску borderline SMART‑атрибути і періодичні скидання лінку в логах. Він не був мертвим, але недовіреним. Через тиждень
схожий диск в іншому шасі впав назавжди. Оскільки вони замінили «попереджувальний» диск раніше, уникнули подвійного збою, який міг перетворитись
на довготривале відновлення.

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

Урок: scrubs, алерти і дисциплінована політика заміни — нудні. Нудне — це звук аптайму.

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

Вибір між ZFS і btrfs (чекліст для рішення)

1. Визначте домен відмов: один вузол чи мульти‑вузол з реплікацією? Якщо один вузол і високі наслідки — тягніться до ZFS.
2. Визначте навантаження: VM‑образи, бази даних чи CI з дрібними файлами? Плануйте поведінку CoW явно.
3. Визначте надлишковість: дзеркала/RAIDZ проти профілів btrfs або mdraid під btrfs. Уникайте btrfs RAID5/6 у серйозних середовищах.
4. Визначте політику знімків: ретеншн, частота і де знімки заборонені (бази даних/VM‑образи без плану).
5. План моніторингу: результати scrub, помилки контрольних сум, використання метаданих (btrfs), стан пулу (ZFS), SMART скрізь.
6. Працюйте workflows заміни: замініть диск у тестовому середовищі. Заміряйте час. Задокументуйте. Зробіть це нудним.

Операційна база btrfs (щотижня/щомісяця)

1. Щотижневий scrub (з рознесенням по хостах).
2. Щотижнева перевірка: btrfs filesystem df і btrfs filesystem usage -T на предмет тиску метаданих.
3. Примусова політика збереження знімків з жорстким лімітом.
4. Щоквартально: тест btrfs replace workflow у staging.

Операційна база ZFS (щотижня/щомісяця)

1. Регулярні scrubs (часто щомісяця для великих пулів, щотижня для малих або більш схильного до відмов обладнання).
2. Алерти на будь‑який інкремент CKSUM у zpool status і на будь‑які «permanent errors» з шляхами файлів.
3. Знімки + реплікація з періодичними відпрацюваннями відновлення.
4. Політика ємності: не тримайте пули гарячими; тримайте запас для resilver і фрагментації.

Питання й відповіді

1) Чи btrfs «готовий до продакшну»?

Для багатьох випадків — так: одно‑дискові конфігурації, RAID1/10, root‑файлові системи, workflow, що тяжіють до знімків, і цілі
резервних копій. Але «готовність до продакшну» залежить від того, чи команда розуміє поведінку метаданих, balance і обмеження обраного RAID‑профілю.

2) Чи ZFS завжди безпечніший за btrfs?

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

3) Чи варто запускати btrfs RAID5/6?

Якщо вам потрібна нудна надійність — уникайте. Використовуйте ZFS RAIDZ, або mdraid (5/6) з простішою файловою системою, або переосмисліть
архітектуру з дзеркалами. Зручність — не фіча під час відбудови.

4) Чому btrfs показує оцінки вільного простору з «min»?

Через алокацію чанків і профілі впливають на те, скільки простору реально доступно для нових алокацій. Консервативне «min» — те значення,
якому слід довіряти при плануванні.

5) Чи можна використовувати ZFS як root‑файлову систему на Linux?

Так, але це залежить від підтримки дистрибутива, інтеграції initramfs і пакування. Операційно це здійсненно, але btrfs зазвичай відчувається
більш «рідним» для root‑snapshot‑workflow на Linux.

6) Який найшвидший спосіб поліпшити продуктивність VM на btrfs?

Розмістіть VM‑образи в NOCOW‑директоріях (створіть до створення файлів), уникайте агресивного створення знімків для них і валідуйте латентність.
Також перевірте стиснення і autodefrag; вони можуть допомогти або нашкодити в залежності від патернів доступу.

7) Який найшвидший спосіб поліпшити продуктивність VM на ZFS?

Використовуйте дзеркала для IOPS, налаштуйте властивості датасету (recordsize, compression), зберігайте коректну поведінку sync і додайте SLOG
тільки якщо у вас реальна проблема з sync‑латентністю і пристрій, якому ви довіряєте.

8) Чи потрібні бекапи, якщо у мене є знімки?

Так. Знімки не є бекапом; вони живуть в тому самому домені відмов. І ZFS, і btrfs полегшують реплікацію на основі знімків — використайте це
і перевіряйте відновлення.

9) Скільки вільного простору слід тримати?

Більше, ніж ви хочете. Для btrfs запас зменшує кризи з метаданими і робить можливим balance/relocation. Для ZFS запас покращує продуктивність
і безпеку при resilver. Робота «на межі» перетворює технічні роботи на інциденти.

10) Що легше експлуатувати невеликій команді?

Якщо команда орієнтована на Linux і хоче root‑знімки та прості інструменти: btrfs може бути простішим. Якщо команда хоче строгу модель і
передбачувані семантики відновлення: ZFS менше підносить сюрпризів, але вимагає вивчення свого словника.

Наступні кроки (практичний висновок)

Обирайте ZFS, коли хочете, щоб стек зберігання поводився як дорослий: чіткі сигнали відмови, сильні дефолти цілісності і дизайн, що примушує
до хорошої архітектури. Обирайте btrfs, коли хочете Linux‑нативні workflow зі знімками, гнучкі субвольюми і готові моніторити метадані та
виконувати balance/scrub як рутинний догляд.

Потім зробіть нудку роботу:

• Запишіть політику збереження знімків. Примусово її виконуйте автоматично.
• Плануйте scrubs. Алертуйте про corrected errors. Сприймайте їх як дим від обладнання.
• Практикуйте заміну диска на некритичному боксі. Заміряйте час. Документуйте.
• Для проблем CoW (VM, бази даних) складіть явний план: NOCOW‑директорії для btrfs, налаштування датасетів і проєктування vdev у ZFS.
• Проведіть drill відновлення. Якщо ви не можете відновити — у вас не бекап, у вас мрія.

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