ZFS zpool get feature@*: читання реальних можливостей пулу

October 22, 2025 • February 3, 2026 • Читання: 7 хв • Views: 7

Було корисно?

Є момент у житті кожного адміністратора ZFS, коли він усвідомлює, що пул — це не просто «ZFS». Це конкретний набір можливостей на диску, узгоджений між кодом, який ви запускаєте, і історією оновлень, які ви дозволили. І найчесніший спосіб побачити цю реальність — команда, яка виглядає як опечатка, поки не врятує вам вихідні: zpool get feature@*.

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

Що таке `feature@*` насправді (і чому це важливо)

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

disabled (не доступна і не використовується)
enabled (доступна для використання; пул про неї знає)
active (фактично використовується на диску; ви перетнули лінію сумісності)

Нюанс для операторів такий: «enabled» зазвичай означає, що ви ще можете повернутися назад (на практиці: ви ще не записали несумісні метадані), тоді як «active» означає, що, ймовірно, ви не зможете — принаймні без знищення та відтворення пулу або складних міграцій. Ось чому пул може імпортуватися на старішому хості доти, поки одного разу не перестане: ви не «оновили пул», ви активували функцію, використавши те, що її вимагало.

Ще два терміни, які ви побачите у властивостях прапорців функцій:

local: встановлено безпосередньо на цьому пулі (часто через zpool upgrade або автоматичну поведінку)
received: встановлено тому, що ви отримали реплікований пул або певні метадані через send/receive (рідше на рівні пулу, частіше на рівні dataset, але може з’явитися залежно від інструментів і поведінки платформи)

Жарт №1 (короткий, доречний): Прапорці функцій ZFS як корпоративний документ політик — ніхто їх не читає, доки вони не стануть причиною, через яку ви не можете «просто відкотитися».

Факти та історія: як ми дійшли до цього

Люди, що працюють зі сховищами, люблять вдавати, що ми поза часом, але ZFS має дуже конкретне походження. Ось кілька фактів і історичних контекстів, які змінюють те, як ви інтерпретуєте feature@* у реальному світі:

Версії пулів виявилися безвихіддю. Ранній ZFS відстежував єдине число «версії» пулу. Вендори розходилися; сумісність стала такою ж політичною, як і технічною.
Прапорці функцій зробили сумісність композиційною. Замість «версії 28» ви отримали список: покращення spacemap, класи алокації, підтримка шифрування тощо.
OpenZFS об’єднав розрізнену екосистему. Різні ОС поставляли різні реалізації ZFS; прапорці функцій були механізмом виживання для портативності.
«Enabled» vs «active» — це операційне золото. Це дозволяє поетапно виконувати оновлення, не роблячи одразу несумісних змін на диску.
Деякі функції — це односторонні двері. Після стану «active» зазвичай не повернутися без відтворення. Це не особливість ZFS; це ціна еволюції форматів метаданих з надійними контрольними сумами.
Прапорці функцій впливають на реплікацію. Потоки zfs send можуть вимагати, щоб ціль підтримувала функції, представлені в потоці. Це стає видимим при змішуванні версій ОС чи вендорів пристроїв.
Boot-пули — особливі. На деяких платформах підтримка завантажувача відстає від файлових функцій. Boot-пул може стати незавантажуваним, навіть якщо ОС може імпортувати його без проблем.
Шифрування — це не «тільки властивість dataset». Рідне шифрування ZFS залежить від підтримки функцій; пули, створені на старих стеках, не отримають його «магічно» без наявних прапорців функцій.
Великі блоки змінили економіку послідовних навантажень. Можливість безпечно використовувати більші розміри записів (і відповідні функції великих блоків) може зменшити накладні витрати на метадані і підвищити пропускну здатність — допоки це не зіткнеться з дрібними випадковими IO.

Як читати `zpool get feature@*` вивід як оператор

Розберемо вивід. На системі OpenZFS ви побачите властивості на кшталт:

cr0x@server:~$ sudo zpool get -H -o name,property,value,source feature@* tank
tank	feature@async_destroy	enabled	local
tank	feature@empty_bpobj	active	local
tank	feature@lz4_compress	active	local
tank	feature@spacemap_histogram	active	local
tank	feature@enabled_txg	enabled	local
tank	feature@extensible_dataset	enabled	local
tank	feature@bookmarks	enabled	local
tank	feature@filesystem_limits	enabled	local
tank	feature@device_removal	disabled	-
tank	feature@allocation_classes	enabled	local
tank	feature@embedded_data	active	local
tank	feature@hole_birth	active	local
tank	feature@large_blocks	active	local
tank	feature@sha512	enabled	local
tank	feature@skein	enabled	local
tank	feature@encryption	enabled	local

Три колонки важливі щодня:

property: назва функції, наприклад feature@large_blocks
value: disabled, enabled або active
source: звідки взято це налаштування (local, - тощо)

Операційне читання таке:

disabled: ця функція недоступна в цьому пулі. Або ваша реалізація ZFS її не знає, або пул не оновлено, щоб рекламувати її.
enabled: пул рекламує функцію і може її активувати за потреби. Ви все ще можете бути сумісні зі старішими системами, якщо ніхто не зробив її «active».
active: щось її використало і записало нові метадані. Ваша «поверхня імпорту» звузилася: системи без цієї функції не імпортуватимуть пул.

Є тонка, але критична відмінність: zpool upgrade може перевести багато функцій у стан «enabled», не роблячи їх «active». Але щойно ви виконаєте певні операції — ввімкнете типи стиснення, використаєте bookmarks, створите зашифровані datasets, увімкнете device removal тощо — ви можете перейти в «active». Переключення — це запис метаданих. ZFS не любить драм; він застосовує незворотні формати метаданих з відмінними контрольними сумами.

Жарт №2 (короткий, доречний): Найшвидший спосіб вивчити прапорці функцій — проігнорувати їх один раз; нічого не навчає так, як пул, який відмовляється імпортуватися о 2 ночі.

Практичні завдання (команди + інтерпретація)

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

Завдання 1: Дамп усіх прапорців функцій пулу (базова перевірка)

cr0x@server:~$ sudo zpool get feature@* tank
NAME  PROPERTY                     VALUE     SOURCE
tank  feature@async_destroy         enabled   local
tank  feature@empty_bpobj           active    local
tank  feature@lz4_compress          active    local
tank  feature@spacemap_histogram    active    local
tank  feature@enabled_txg           enabled   local
tank  feature@extensible_dataset    enabled   local
tank  feature@bookmarks             enabled   local
tank  feature@filesystem_limits     enabled   local
tank  feature@device_removal        disabled  -
tank  feature@allocation_classes    enabled   local
tank  feature@embedded_data         active    local
tank  feature@hole_birth            active    local
tank  feature@large_blocks          active    local
tank  feature@sha512                enabled   local
tank  feature@skein                 enabled   local
tank  feature@encryption            enabled   local

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

Завдання 2: Показати тільки «active» функції (лінія сумісності, яку ви перетнули)

cr0x@server:~$ sudo zpool get -H -o property,value feature@* tank | awk '$2=="active"{print}'
feature@empty_bpobj	active
feature@lz4_compress	active
feature@spacemap_histogram	active
feature@embedded_data	active
feature@hole_birth	active
feature@large_blocks	active

Інтерпретація: Цей список — ваш «must support» набір для будь-якої системи, яка має імпортувати пул. Якщо DR-хост не імпортує, почніть із порівняння його підтримуваних функцій з цим списком active.

Завдання 3: Показати тільки «enabled але не active» (що може стати вашою наступною проблемою)

cr0x@server:~$ sudo zpool get -H -o property,value feature@* tank | awk '$2=="enabled"{print}'
feature@async_destroy	enabled
feature@enabled_txg	enabled
feature@extensible_dataset	enabled
feature@bookmarks	enabled
feature@filesystem_limits	enabled
feature@allocation_classes	enabled
feature@sha512	enabled
feature@skein	enabled
feature@encryption	enabled

Інтерпретація: Це «заряджені» можливості. Ви ще не обов’язково їх використовуєте, але майбутня дія адміністратора (або майбутній дефолт) може їх активувати. Якщо ви підтримуєте суворі цілі сумісності (наприклад, старіший приймач реплікації), можливо, варто встановити політику щодо того, які функції дозволено активувати.

Завдання 4: Захопити «знімок можливостей пулу» для огляду змін

cr0x@server:~$ sudo zpool get -H -o property,value,source feature@* tank | sort > /var/tmp/tank.features.$(date +%F).txt
cr0x@server:~$ tail -n 5 /var/tmp/tank.features.$(date +%F).txt
feature@spacemap_histogram	active	local
feature@userobj_accounting	disabled	-
feature@zilsaxattr	disabled	-
feature@zpool_checkpoint	disabled	-
feature@zstd_compress	disabled	-

Інтерпретація: Ставтеся до стану прапорців функцій як до міграцій схем у базі даних. Зберігайте перед оновленнями, перед переміщенням платформи і перед ввімкненням нових можливостей, як шифрування або спеціальні vdev’и.

Завдання 5: Перевірити інформацію про версію пулу/системи функцій разом (щоб зменшити здогадки)

cr0x@server:~$ sudo zpool status -x
all pools are healthy
cr0x@server:~$ modinfo zfs 2>/dev/null | head -n 5
filename:       /lib/modules/6.8.0/kernel/zfs/zfs.ko
version:        2.2.4-1
license:        CDDL
description:    ZFS
author:         OpenZFS

Інтерпретація: Знати «який саме ZFS у вас» важливо при порівнянні підтримки функцій між хостами. Той же пул, різні модулі ZFS — різні підтримувані функції. Уникайте думки «це Linux, тож все гаразд» — доступність функцій OpenZFS залежить від версії, що постачається.

Завдання 6: Подивитися, що зробить `zpool upgrade` перед його виконанням

cr0x@server:~$ sudo zpool upgrade
This system supports ZFS pool feature flags.

All pools are formatted using feature flags.

Some supported features are not enabled on the following pools.
Note that the pool may be upgraded to use these features, but doing so
may prevent the pool from being imported on other systems that do not
support the features.

POOL  FEATURE
tank  project_quota
tank  spacemap_v2

Інтерпретація: Це ваш «diff». Він показує функції, які ваша поточна програма підтримує, але які пул ще не ввімкнув. Якщо ваш DR-сайт або ціль реплікації відстає, цей вивід — попереджувальна позначка, а не рекомендація.

Завдання 7: Навмисно оновити пул (і зрозуміти радіус ураження)

cr0x@server:~$ sudo zpool upgrade tank
This system supports ZFS pool feature flags.

Enabled the following features on 'tank':
  project_quota
  spacemap_v2

Інтерпретація: Зазвичай це переводить функції в стан enabled, а не обов’язково в active. Але ви тепер зробили можливим їхнє майбутнє активування — і могли зменшити сумісність із системами, які навіть не розпізнають ці enabled-функції, залежно від реалізації. Безпечне припущення: після ввімкнення нових функцій протестуйте імпорт на всіх «повинні імпортувати» системах.

Завдання 8: Знайти помилки імпорту, пов’язані з функціями (читайте помилку, не імпровізуйте)

cr0x@drhost:~$ sudo zpool import
   pool: tank
     id: 1234567890123456789
  state: UNAVAIL
status: The pool uses the following feature(s) not supported on this system:
        spacemap_histogram
        embedded_data
action: Upgrade the system to support the pool features, or recreate the pool from backup.
   see: zpool-features(7)
config:

        tank        UNAVAIL  unsupported feature(s)
          raidz2-0  ONLINE
            sda     ONLINE
            sdb     ONLINE
            sdc     ONLINE
            sdd     ONLINE

Інтерпретація: Цей вивід дає вам список винуватців. Зіставте його зі списком «active features» на джерелі. Якщо DR-хост не можна оновити, ваші варіанти: зберігати сумісний пул для реплікації, використовувати копіювання на рівні файлів або відтворити пул без цих функцій (зазвичай потребує міграції даних).

Завдання 9: Зв’язати прапорці функцій пулу з поведінкою dataset, що вас цікавить (приклад шифрування)

cr0x@server:~$ sudo zpool get -H -o value feature@encryption tank
enabled
cr0x@server:~$ sudo zfs create -o encryption=on -o keyformat=passphrase tank/secret
Enter new passphrase:
Re-enter new passphrase:
cr0x@server:~$ sudo zfs get -H -o property,value encryption,keystatus tank/secret
encryption	on
keystatus	available

Інтерпретація: Підтримка функції на пулі — це передумова. Пул може рекламувати feature@encryption як enabled, але вона стає операційно важливою лише коли ви створюєте зашифровані datasets. Це також може вплинути на робочі процеси реплікації та обробку ключів під час завантаження.

Завдання 10: Перевірити відповідність функцій стиснення (zstd проти lz4)

cr0x@server:~$ sudo zpool get -H -o value feature@lz4_compress tank
active
cr0x@server:~$ sudo zpool get -H -o value feature@zstd_compress tank
disabled
cr0x@server:~$ sudo zfs set compression=lz4 tank/data
cr0x@server:~$ sudo zfs get -H -o value compression tank/data
lz4

Інтерпретація: Якщо ви реплікуєте на ціль, яка не підтримує zstd, використання zstd на джерелі може стати пасткою для міграції. Прапорці функцій можуть попередити вас ще до того, як ви почнете «оптимізувати» новим кодеком.

Завдання 11: Виявити, чи використовуються великі блоки (і чому це змінює налаштування)

cr0x@server:~$ sudo zpool get -H -o value feature@large_blocks tank
active
cr0x@server:~$ sudo zfs get -H -o property,value recordsize tank/data
recordsize	128K
cr0x@server:~$ sudo zfs set recordsize=1M tank/data
cr0x@server:~$ sudo zfs get -H -o value recordsize tank/data
1M

Інтерпретація: Великі блоки можуть суттєво допомогти для послідовного IO (бекапи, медіа, аналітика), але вони не безкоштовні. Коли ви починаєте піднімати recordsize, випадкові операції запису можуть карати вас ампліфікацією read-modify-write. Прапорці функцій повідомляють, чи пул може безпечно підтримувати необхідні метадані для великих блоків.

Завдання 12: Підтвердити, що змінилося після ризикованої операції (diff до/після)

cr0x@server:~$ sudo zpool get -H -o property,value feature@* tank | sort > /var/tmp/features.before
cr0x@server:~$ sudo zfs set compression=zstd tank/data
cannot set property for 'tank/data': 'compression' feature is not enabled
cr0x@server:~$ sudo zpool get -H -o property,value feature@* tank | sort > /var/tmp/features.after
cr0x@server:~$ diff -u /var/tmp/features.before /var/tmp/features.after

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

Завдання 13: Зв’язати прапорці функцій зі звітністю по простору та поведінкою аллокатора (spacemap histogram)

cr0x@server:~$ sudo zpool get -H -o value feature@spacemap_histogram tank
active
cr0x@server:~$ sudo zdb -bbbbb tank 2>/dev/null | head -n 20

Інтерпретація: Коли ви глибоко занурюєтесь у продуктивність аллокатора або обговорення фрагментації, пов’язані зі spacemap функції важливі. Якщо ви порівнюєте два пули і в одного активовані нові spacemap-функції, їх поведінка при churn може настільки відрізнятися, що банальний бенчмарк буде недійсний.

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

cr0x@source:~$ sudo zpool get -H -o property,value feature@* tank | awk '$2=="active"{print $1}' | sort > /var/tmp/source.active
cr0x@receiver:~$ sudo zpool get -H -o property,value feature@* backup | awk '$2!="disabled"{print $1}' | sort > /var/tmp/recv.known
cr0x@receiver:~$ comm -23 /var/tmp/source.active /var/tmp/recv.known
feature@embedded_data
feature@spacemap_histogram

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

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

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

Сценарій був типовим для корпоративної «гібридної зрілості». Продукція працювала на новішому Linux з сучасним модулем OpenZFS. DR працював на старішому, вендорно-підтримуваному апараті, який давно не оновлювали, бо «сховище стабільне» і ніхто не хотів знову витягувати питання закупівлі. Реплікація для деяких datasets була на рівні файлів, для інших — з використанням zfs send/receive, і в більшості випадків усе працювало — доки одного дня не перестало.

Рутинна відмова обладнання у продукції переросла у проблему на майданчику. Runbook DR казав: «імпортуйте реплікований пул на DR і піднімайте сервіси». On-call виконав саме це, і імпорт пулу провалився з повідомленням «unsupported feature(s)». Людська реакція була передбачувана: недовіра до DR-боксу, припущення про проблему з кабелем, перестановка дисків, спроби знову, заміна контролерів, знову спроби. Час розчинявся у прірві, куди зникає надія.

Корінь проблеми був нудним: у якийсь момент продукція ввімкнула нові функції під час вікна обслуговування — нічого драматичного, просто «тримати в актуальному стані». Ці функції тихо залишилися ввімкненими і пізніше стали active, коли хтось використав можливість, яка їх вимагала (дія, яка відчувалася як налаштування dataset, а не подія сумісності пулу). DR ніколи не оновлювали, і ніхто не порівнював прапорці функцій між середовищами.

Виправлення не було хитрою лазівкою. Вони оновили платформу DR (після екстреного винятку, який зайняв менше часу, ніж невдала усунення несправностей), знову імпортували і відновили сервіс. Післямова, яка врешті запрацювала — проста: знімки прапорців функцій стали частиною кожного огляду готовності DR. Не як табличка в електронній таблиці, а як фактичний вивід команд, збережений разом із записами змін.

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

Інша організація мала проблему з продуктивністю: нічні аналітичні джоби тривали довго, і команду сховища тиснули «зробіть ZFS швидшим». Хтось запропонував більші recordsize та нові алгоритми стиснення. У лабораторії ідеї виглядали розумно: більша пропускна здатність, менше IO на гігабайт. Команда запланувала зміну і впевнено її розгорнула.

Потім з’явилися звернення в підтримку. Сервіси з чутливою латентністю, що ділили пул, почали пропускати SLO. Аналітичні джоби були щасливі, але змішане навантаження перетворилося на бій: випадкові записи і перезаписи почали платити ціну ампліфікації read-modify-write, і кеш-поведінка стала дивною. На додачу, вони перевелися в новішу функціональну територію, що зробило їхній «план відкату на всяк випадок» утопією. Властивості можна було змінити назад; час ні.

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

Рішення було більш архітектурним, ніж героїчним: розділити навантаження на окремі пули (або принаймні різні класи vdev), використовувати великі записи там, де трафік справді послідовний, і зберігати консервативні дефолти для загальнопотребних datasets. У висновках команда написала просту фразу: «Кожна настройка продуктивності — також і настройка сумісності, навіть якщо так не виглядає».

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

Ця історія не зробила нікого знаменитим, і саме тому вона спрацювала. Команда платформи мала правило: перед будь-яким оновленням, пов’язаним з ZFS — ядро, пакет OpenZFS або оновлення пулу — вони збирали стандартний «bundle стану сховища». Він включав zpool status, zpool get feature@*, ключові властивості dataset і швидкий тест реплікації на staging-приймальник. Ніяких винятків, ніякого «зробимо потім».

Під час оновлення інфраструктури їм потрібно було швидко перемістити пул на нове обладнання. План був експортувати, перенести диски, імпортувати. Просто. Команда запустила свій bundle і помітила неприємну деталь: кілька функцій були enabled, але не active, і один із downstream-споживачів був старішою системою для архіву відповідності. У графіку вона не мала шляху до оновлення.

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

Міграція пройшла, нічого не зламалося, і ніхто поза командою цього не помітив — найвища похвала в операціях. У ретроспективі «геройський хід» був буквально текстовим файлом зі виводом zpool get feature@*, збереженим у потрібний момент.

Швидкий план діагностики

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

Крок 1: Визначте, чи це сумісність чи продуктивність

Якщо проблема — «не імпортується», то майже напевно це сумісність. Якщо проблема — «повільно», прапорці функцій можуть опосередковано впливати (поведінка аллокатора, розміри блоків тощо), але вам усе одно потрібно знайти вузьке місце.

cr0x@server:~$ sudo zpool import
cr0x@server:~$ sudo zpool status -x
cr0x@server:~$ sudo zpool get -H -o property,value feature@* tank | awk '$2!="disabled"{print}' | head

Інтерпретація: Помилки імпорту явно вказують на непідтримувані функції. Якщо імпорт працює, переходьте до перевірки продуктивності.

Крок 2: Для проблем імпорту/реплікації, порівняйте «active» функції з іншим хостом

cr0x@source:~$ sudo zpool get -H -o property,value feature@* tank | awk '$2=="active"{print $1}' | sort
cr0x@target:~$ sudo zpool get -H -o property,value feature@* backup | awk '$2!="disabled"{print $1}' | sort

Інтерпретація: Будь-яка active-функція на source, яку target не розпізнає/не підтримує — це червоний прапор. Не шукайте кабелі, коли метадані говорять чітко.

Крок 3: Для продуктивності, перевірте класичні вузькі місця ZFS у порядку

Здоров’я пулу та помилки vdev (дефектний пул може «працювати», але повільно)
Насичення IO (один vdev завантажений, інші простоюють)
Тиск ARC (промахи кешу викликають активність дисків)
Поведінка sync-записів (SLOG чи його відсутність; додаток робить fsync-шторми)
Невідповідність recordsize/compression (навантаження не вирівняне)

cr0x@server:~$ sudo zpool status -v tank
cr0x@server:~$ sudo zpool iostat -v tank 1 10
cr0x@server:~$ sudo arcstat 1 10
cr0x@server:~$ sudo zpool get -H -o property,value ashift,autotrim,feature@* tank | head -n 20
cr0x@server:~$ sudo zfs get -r -H -o name,property,value recordsize,compression,atime,sync tank/data | head -n 20

Інтерпретація: Прапорці функцій не скажуть вам «цей vdev насичений», але вони скажуть, чи ви в світі, де певні оптимізації можливі або вже активні. Комбінуйте обидва підходи: можливості та поточну поведінку.

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

Помилка 1: Ставитися до «enabled» як до «безпечного», не розуміючи активацію

Симптом: «Ми оновили пул тижнями раніше і все було нормально; тепер імпорт на DR провалюється.»

Чому це відбувається: Ви ввімкнули функції, а потім пізніше виконали дію, яка їх активувала. Розрив з’являється відстрочено.

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

Помилка 2: Оновлювати boot-пул як data-пул

Симптом: Система імпортує пул нормально з rescue-середовища, але не завантажується звичайно.

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

Виправлення: Перевірте обмеження завантажувача перед ввімкненням нових функцій на boot-пулах. Тримайте boot-пули консервативними; оновлюйте їх тільки з явним підтвердженням платформи й планом відкату.

Помилка 3: Припускати, що send/receive «просто працюватиме» між змішаними версіями

Симптом: Реплікація падає з помилками про непідтримувані функції, bookmarks або несумісність потоку.

Чому це відбувається: Джерело створює потоки, що вимагають функцій, не підтримуваних приймачем (на рівні пулу і dataset’у).

Виправлення: Уніфікуйте версії приймачів або використовуйте staging-приємник, який може прийняти потік від джерела і потім переслати у сумісному форматі (коли можливо). Більш часте рішення — «оновіть приймача».

Помилка 4: Вмикати блискучі функції під час інциденту

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

Чому це відбувається: Під тиском хтось запускає zpool upgrade -a або змінює властивості для «покращення продуктивності», ненавмисно активуючи функції.

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

Помилка 5: Використовувати прапорці функцій як проксі для тюнінгу продуктивності

Симптом: «Ми ввімкнули все, і все одно повільно», або продуктивність погіршилася після «оновлення».

Чому це відбувається: Функції — це можливості, а не множники пропускної здатності. Продуктивність залежить від макету vdev, навантаження, ARC, поведінки sync, фрагментації тощо.

Виправлення: Використовуйте швидкий план діагностики: спочатку доведіть вузьке місце за допомогою iostat/latency/ARC-статистики, а потім вирішуйте, чи релевантні функції та властивості.

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

Чекліст: Перед тим, як запускати `zpool upgrade` у проді

Захопити поточний стан прапорців.
Визначити всі системи, які повинні імпортувати або отримувати від цього пулу.
Підтвердити їхні версії ZFS/OpenZFS та підтримувані функції.
Запустити zpool upgrade (без аргументів), щоб побачити, що зміниться.
Прийняти рішення: оновлювати зараз, пізніше чи вибірково (по пулах).
Стаджувати й тестувати імпорт/receive на непро- боці, якщо можливо.

cr0x@server:~$ sudo zpool get -H -o property,value,source feature@* tank | sort > /var/tmp/tank.features.pre
cr0x@server:~$ sudo zpool upgrade
cr0x@server:~$ sudo zpool upgrade tank
cr0x@server:~$ sudo zpool get -H -o property,value,source feature@* tank | sort > /var/tmp/tank.features.post
cr0x@server:~$ diff -u /var/tmp/tank.features.pre /var/tmp/tank.features.post | head -n 50

Чекліст: Коли плануєте міграцію платформи

На джерелі: перелічити active-функції.
На цілі: підтвердити, що вона розпізнає/підтримує ці функції.
Підтвердити обмеження boot-пулу, якщо пул критичний для завантаження.
Експортувати/імпортувати у контрольованому вікні; перевірити з розкладом scrub.

cr0x@source:~$ sudo zpool get -H -o property,value feature@* tank | awk '$2=="active"{print $1}' | sort > /var/tmp/tank.active
cr0x@target:~$ sudo zpool get -H -o property,value feature@* tank 2>/dev/null | awk '$2!="disabled"{print $1}' | sort > /var/tmp/target.known
cr0x@target:~$ comm -23 /var/tmp/tank.active /var/tmp/target.known

Чекліст: Побудувати «контракт сумісності» для DR

Визначити найстарішу систему, яка повинна імпортувати пули.
Заморозити активацію функцій пулу понад те, що підтримує ця система.
Планувати оновлення DR разом з продукцією, а не «пізніше».
Аудит щоквартально: порівнювати active-функції і робити тестовий import/receive.

cr0x@prod:~$ sudo zpool get -H -o property,value feature@* tank | awk '$2=="active"{print $1}' | sort > /var/tmp/prod.active
cr0x@dr:~$ sudo zpool import 2>&1 | sed -n '1,30p'

Поширені запитання

1) Що власне показує `zpool get feature@*`?

Він показує властивості прапорців функцій пулу: які можливості на диску disabled, enabled або active. Це найпряміший спосіб побачити, що пул може робити і які формати метаданих він уже використовує.

2) У чому різниця між «enabled» і «active»?

Enabled означає, що пул рекламує функцію і може її використовувати. Active означає, що функція використовується на диску — записано метадані, що вимагають цієї функції. Active — це лінія, яка зазвичай ламає сумісність імпорту зі старими системами.

3) Чи робить запуск `zpool upgrade` функції одразу active?

Зазвичай він переводить їх у enabled, але активація зазвичай відбувається, коли ви виконуєте операції, які вимагають цих функцій. Операційний ризик — відстрочений: ви можете ввімкнути сьогодні і зламати імпорт на DR наступного місяця, коли функція стане active.

4) Чи можу я «понизити» пул або вимкнути active-функцію?

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

5) Чому пул не імпортується на іншу систему?

Бо реалізація ZFS на тій системі не підтримує одну або кілька функцій, що є active на пулі. Помилка імпорту зазвичай перелічує точні назви функцій.

6) Чи однакові прапорці функцій у всіх реалізаціях ZFS?

В екосистемі OpenZFS вони здебільшого узгоджені, але не всі платформи постачають однакову версію OpenZFS, і деякі вендори затримують або обмежують оновлення. Трактуйте «ZFS» як родинне ім’я; підтримка функцій залежить від конкретної збірки.

7) Чи скажуть прапорці функцій, чому повільна продуктивність?

Прямо — ні. Вони говорять, які можливості існують або використовуються, що може впливати на характеристики продуктивності — наприклад, поведінка spacemap або підтримка великих блоків. Для реальних вузьких місць використовуйте zpool iostat, статистику ARC і метрики навантаження.

8) Як прапорці функцій пов’язані з властивостями dataset, як стиснення або шифрування?

Деякі властивості dataset вимагають підтримки на рівні пулу. Якщо пул не має відповідної функції enabled, ZFS відмовить у встановленні властивості (найкращий варіант) або ви активуєте функцію, почавши користуватися можливістю (поширений варіант).

9) Якщо функція «enabled», але не «active», чи варто хвилюватися?

Варто хоча б бути поінформованим. Enabled-функції — це можливість, яку ви можете ненавмисно активувати звичайними операціями. Якщо у вас суворі вимоги сумісності, enabled-but-not-active — пункт у плані керування змінами.

10) Що найкорисніше зберігати для майбутнього розслідування?

Датований знімок виводу zpool get feature@* (плюс zpool status), зроблений до і після оновлень. Це невелика праця, яка рятує від великих здогадок пізніше.

Висновок

zpool get feature@* — це найближче до «серуму правди» в ZFS. Він каже вам, на що здатний ваш пул, до чого він вже зобов’язаний на диску і де проведено лінії сумісності — навмисно чи ні. У виробничому середовищі це не дрібниця; це різниця між контрольованим оновленням і несподіваним проєктом міграції.

Якщо ви візьмете лише одну операційну звичку з цього матеріалу: відстежуйте active функції так само, як версії схем. Зберігайте вивід, робіть diff під час змін і включайте це в готовність DR. ZFS залюбки робитиме свою справу роками — аж доки ви не попросите старішу систему зрозуміти майбутнє, якого вона не вивчала.