Портативність фіч-флагів ZFS: уникнення помилок «неможливо імпортувати»

December 21, 2025 • February 3, 2026 • Читання: 5 хв • Views: 10

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

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

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

Що таке фіч-флаги (і чому вони ламають імпорт)

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

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

Enabled vs active: дрібниця, що псує вихідні

ZFS відстежує стани фіч, які зазвичай виглядають так: disabled, enabled, active.
Точне відображення дещо різниться від платформи до платформи, але ідея однакова:

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

Ризик переносимості різко зростає, коли фіча стає active. Іноді достатньо лише enabled, щоб блокувати імпорт на старішому ZFS;
інколи значення має тільки active. Ви не захочете дізнаватися, яке з них коли під час вікна міграції.

Чому ви не можете просто «вимкнути» її

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

Це перший пункт прийняття рішення, до якого ця стаття вас підштовхне: переносимість — це те, що ви проектуєте й тестуєте.
Це не властивість, яку ви відкриваєте пізніше, дивлячись на помилки zpool import.

Сухувато-смішна реальність

Жарт №1: Пул ZFS переносний так само, як рояль «пересувається». Так, технічно — просто не дивуйтеся, коли він вимагатиме планування.

Цитата, яку варто приклеїти біля монітора

«Надія — це не стратегія.» — генерал Гордон Р. Салліван

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

Факти та коротка історія: як ми сюди потрапили

Деталі важливі, бо люди часто повторюють стару народну мудрість про ZFS, яка була правдивою лише в певну епоху.
Ось конкретні факти та контекстні пункти, які допоможуть вам міркувати про переносимість сьогодні.

«Версії» пулу були одним лічильником. Раніше ZFS використовував номер версії пулу; оновлення підвищувало його й могло блокувати імпорт на старих системах.
Фіч-флаги ввели, щоб уникнути моделі «все або нічого».
Фіч-флаги записуються на диск. Це не перемикач часу виконання; це частина самодекларування пулу після перезавантажень.
Це добре для відновлення — доки ви не змінили опис на діалект, якого інші хости не розуміють.
OpenZFS об’єднав те, що раніше було розрізненим. Solaris/Illumos-похідні реалізації і різні даунстрими розійшлися; OpenZFS зробив координацію фіч-флагів реалістичнішою, але не досконалою в контексті пакувань постачальників.
Linux ZFS (нині OpenZFS на Linux) популяризував змішані парки. Багато організацій тепер запускають ZFS на Linux, FreeBSD та в аплайенсах одночасно,
і переносимість між ними — це щоденна операційна задача, а не цікавинка.
«zpool upgrade» змінює контракт. На багатьох системах zpool upgrade не лише включає фічі; воно може включити набір,
який старіші системи не зможуть імпортувати. Люди ставляться до цього як до «встановити оновлення» і жалкують.
Деякі фічі відносяться до датасетів, деякі — до пулу, але блокування імпорту — на рівні пулу. Якщо пул потребує фічі, то імпорт ускладнюється для всього пулу, навіть якщо тільки один датасет її використав.
Шифрування змінило дискусію про переносимість. Вбудоване шифрування ZFS додало відмінності в управлінні ключами та інтеграції сховища ключів між ОС,
а також фічі, необхідні для зашифрованих датасетів.
Аплайенси постачальників інколи відстають. Системи з «ZFS всередині» можуть постачатися з консервативним набором фіч або відсталими версіями OpenZFS,
що робить їх найменш сумісним елементом вашого парку.
Імпорт тільки для читання теж може провалитися. Дехто вважає, що zpool import -o readonly=on обійде вимоги фіч. Ні, якщо формат на диску не можна безпечно інтерпретувати.

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

Режими відмов, що призводять до «неможливо імпортувати»

1) Пул оновили на одному хості, потім перенесли на старіший хост

Класичний сценарій: пул інколи імпортують на Хості A (новий OpenZFS), інколи на Хості B (старіший). Хтось виконав
zpool upgrade на Хості A, бо здалося, що це безпечний крок обслуговування. Тепер Хост B не може імпортувати.

2) Фіча стала active через зміну властивості датасету

Певні властивості датасетів можуть опосередковано активувати фічі пулу. Ви не запускали upgrade; ви «просто включили xattr=sa» або «увімкнули шифрування»
чи «увімкнули special_small_blocks». Це може активувати фічі. Тепер ваш DR не може імпортувати, або ваш реплікаційний приймач відмовляється приймати.

3) Гетерогенні версії OpenZFS у парку з різним пакуванням

Навіть у межах «OpenZFS» дистрибутиви та постачальники можуть постачати різні версії, бекпорти або набори фіч. Можуть бути дві системи «2.1.x», де одна підтримує
фічу, а інша — ні через набір патчів. Вважати, що семантична версія гарантує паритет фіч — відмінний спосіб написати інцидентний звіт.

4) Хтось використав зручний шлях snapshot/replication, який «притягнув» фічі

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

5) Пул створили з ігноруванням «сумісності»

Сучасний OpenZFS має властивість compatibility (на деяких платформах), яка може обмежити фічі при створенні пулу відповідно до цільового набору.
Якщо ви її не встановили і пізніше виявили, що вона була потрібна, ви опинитесь у ситуації перебудови.

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

Коли пул не імпортується і люди дивляться, у вас немає часу заново вивчати ZFS. Потрібен швидкий шлях триажу, який звузить варіанти:
«непідтримувані фічі» vs «пристрої/шляхи» vs «пошкодження». Ось порядок, який зазвичай найшвидше приводить до істини.

Перш за все: підтвердіть, що це проблема фіч-флагів, а не відсутніх дисків

Запустіть zpool import і уважно прочитайте весь вивід. Якщо там написано «unsupported feature(s)», припиняйте гадати і починайте збирати дані.
Перевірте, що ОС бачить усі диски (шляхи by-id). Якщо пул неповний, ви отримаєте оманливий шум у виводі.

По-друге: ідентифікуйте, які фічі потрібні і який ZFS у вас

Дізнайтеся реалізацію ZFS і версію локальної системи (zfs version на Linux; uname/kldstat і інформація про пакети на BSD).
Витягніть список фіч, які потрібні пулу з виводу import, і порівняйте з локальними підтримуваними фічами.

По-третє: вирішіть, чи можна імпортувати десь, навіть тимчасово

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

По-четверте: оберіть безпечний шлях відновлення

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

Жарт №2: Фраза «ми просто імпортуємо на іншій машині» закінчувала більше вікон змін, ніж кофеїн.

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

Ці завдання написані так, ніби ви на чергуванні: команда, реалістичний вивід і яке рішення з нього витікає.
Приклади припускають Linux з встановленими утилітами OpenZFS. Ті самі концепції застосовні на FreeBSD/Illumos, але деякі команди відрізняються.

Завдання 1: Перелічити імпортовані пули і відразу помітити «unsupported features»

cr0x@server:~$ zpool import
   pool: data
     id: 13462978123456789012
  state: UNAVAIL
status: The pool was last accessed by another system.
action: The pool cannot be imported due to missing or damaged devices.
   see: zpool import -F for recovery
config:

        data        UNAVAIL  insufficient replicas
          raidz1-0  UNAVAIL  insufficient replicas
            sda     UNAVAIL  cannot open
            sdb     UNAVAIL  cannot open
            sdc     UNAVAIL  cannot open

   pool: backup
     id: 998877665544332211
  state: UNAVAIL
status: The pool uses the following feature(s) not supported on this system:
        com.delphix:spacemap_histogram
        com.delphix:extensible_dataset
action: The pool cannot be imported. Access the pool on a system that supports
        the required feature(s), then migrate the data.
config:

        backup      UNAVAIL  unsupported feature(s)

Рішення: «data» виглядає як проблема видимості пристроїв/реплік. «backup» — це проблема сумісності фіч-флагів.
Не марнуйте час на пересування кабелів для «backup»; знайдіть новіший хост ZFS.

Завдання 2: Спроба імпорту тільки для читання (щоб підтвердити, що фічі блокують)

cr0x@server:~$ sudo zpool import -o readonly=on backup
cannot import 'backup': unsupported version or feature
unsupported feature(s): com.delphix:spacemap_histogram com.delphix:extensible_dataset

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

Завдання 3: Перевірити, які фічі підтримує ваш поточний ZFS

cr0x@server:~$ zpool get -H -o property,value all | grep feature@
feature@async_destroy                         enabled
feature@empty_bpobj                           active
feature@lz4_compress                          active
feature@spacemap_histogram                    -
feature@extensible_dataset                    -
feature@embedded_data                         -
feature@bookmarks                             enabled

Значення виводу: Фічі з - невідомі/непідтримувані цією реалізацією.

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

Завдання 4: Ідентифікувати локальну версію OpenZFS (Linux)

cr0x@server:~$ zfs version
zfs-2.1.5-1
zfs-kmod-2.1.5-1

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

Завдання 5: Подивитися, який хост останнім імпортував пул (допомагає знайти «новіший» бокс)

cr0x@server:~$ zdb -C backup | head -n 25
MOS Configuration:
        version: 5000
        name: 'backup'
        state: 0
        txg: 925331
        pool_guid: 998877665544332211
        hostid: 0x3f2a9c10
        hostname: 'stor-ops-07'
        vdev_tree:
            type: 'root'
            id: 0
            guid: 1234567890123456789

Значення виводу: Пул записує hostname/hostid, який останнім записував у нього.

Рішення: Знайдіть stor-ops-07 (або його заміну). Це ваш найкращий кандидат для сумісного імпорту.

Завдання 6: На «новішому» хості перелічити стани фіч для пулу

cr0x@server:~$ sudo zpool get -H -o property,value all backup | grep feature@
feature@async_destroy                         enabled
feature@empty_bpobj                           active
feature@lz4_compress                          active
feature@spacemap_histogram                    active
feature@extensible_dataset                    active
feature@embedded_data                         active
feature@bookmarks                             enabled

Значення виводу: Ті Delphix-orig інфо тепер active, отже пул реально від них залежить.

Рішення: Пониження нереалістичне. Ваш шлях — оновити стару систему або мігрувати дані в новий сумісний пул.

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

cr0x@server:~$ sudo zpool get -H compatibility backup
compatibility    off

Рішення: Якщо у вас змішані цільові ОС — «off» пахне проблемою. Для нових пулів слід встановлювати профіль сумісності відповідно до
найстарішої системи, на якій ви повинні імпортувати.

Завдання 8: Створити новий «портативний» пул з обмеженими фічами (приклад)

cr0x@server:~$ sudo zpool create -o ashift=12 -o compatibility=openzfs-2.1 portable mirror /dev/disk/by-id/wwn-0x5000c500a1b2c3d4 /dev/disk/by-id/wwn-0x5000c500a1b2c3d5
cannot set property for 'portable': invalid property 'compatibility'

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

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

Завдання 9: Показати стан пулу і підтвердити, що ви не маєте справи з відсутніми vdev

cr0x@server:~$ sudo zpool status -v backup
  pool: backup
 state: ONLINE
status: Some supported features are not enabled on the pool.
action: The pool can be upgraded using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(7) for details.
config:

        NAME                                            STATE     READ WRITE CKSUM
        backup                                           ONLINE       0     0     0
          raidz2-0                                       ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000c50011111111      ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000c50022222222      ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000c50033333333      ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000c50044444444      ONLINE       0     0     0

Рішення: Опирайтеся спокусі виконати zpool upgrade лише тому, що воно пропонується.
Це повідомлення — чемна пропозиція ZFS підкласти вам портативну рушницю.

Завдання 10: Аудит властивостей датасетів, що часто активують непереносимі фічі

cr0x@server:~$ sudo zfs get -r -o name,property,value -s local encryption,keystatus,special_small_blocks,xattr,recordsize backup
NAME                     PROPERTY              VALUE
backup                    encryption            off
backup                    keystatus             -
backup                    special_small_blocks  0
backup                    xattr                 sa
backup                    recordsize            128K
backup/vm                 encryption            aes-256-gcm
backup/vm                 keystatus             available
backup/vm                 special_small_blocks  16K
backup/vm                 xattr                 sa
backup/vm                 recordsize            16K

Значення виводу: У вас є зашифровані датасети й особлива поведінка алокації. Це типові тригери активації фіч.

Рішення: Якщо приймач/DR сайт не підтримує шифрування або спеціальні vdev-функції, потрібен план міграції, який їх уникає
(нова схема датасетів або оновлення приймача).

Завдання 11: Визначити, чи вимагатиме ваш реплікаційний стрім нові фічі (dry run)

cr0x@server:~$ sudo zfs send -nP backup/vm@daily-2025-12-25
size	26.4G
incremental	backup/vm@daily-2025-12-24	backup/vm@daily-2025-12-25

Рішення: Dry run підтверджує існування стріму і дає його розмір. Далі вирішіть, чи потрібно використовувати raw send для шифрування
(що припускає підтримку фіч на приймачі) або реплікувати/plaintext (що змінює вашу модель загрози).

Завдання 12: Використати контрольований приймач і протестувати імпорт на «старій» системі

cr0x@server:~$ sudo zfs send -R backup/vm@daily-2025-12-25 | ssh dr-old 'sudo zfs receive -uF drpool/test-vm'
receiving full stream of backup/vm@daily-2025-12-25 into drpool/test-vm@daily-2025-12-25
received 26.4G stream in 00:12:41 (35.4M/sec)

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

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

Завдання 13: Перевіряти дрейф активації фіч з часом (виявити «хтось це ввімкнув»)

cr0x@server:~$ sudo zpool get -H -o property,value all backup | awk -F'\t' '/feature@/ && $2=="active"{print $1}' | sort | head
feature@allocation_classes
feature@embedded_data
feature@extensible_dataset
feature@spacemap_histogram

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

Завдання 14: Підтвердити підтримувані фічі «старого» хоста, перш ніж обіцяти щось

cr0x@server:~$ zpool get -H -o property,value all | grep feature@ | head
feature@async_destroy                         enabled
feature@empty_bpobj                           active
feature@lz4_compress                          active
feature@spacemap_histogram                    -
feature@extensible_dataset                    -
feature@embedded_data                         -

Рішення: Якщо ви бачите - для фіч, які active на пулі, який потрібно перемістити — зупиніться.
Або оновіть цей хост, або прийміть, що він не годиться як ціль імпорту.

Завдання 15: Експортуйте безпечно перед переміщенням апаратури (щоб уникнути плутанини «використовується»)

cr0x@server:~$ sudo zpool export backup
cr0x@server:~$ zpool import | grep -A2 'pool: backup'
   pool: backup
     id: 998877665544332211
  state: ONLINE

Значення виводу: Export чисто від’єднує пул, щоб наступний import був свідомою дією, а не хаотичним захопленням.

Рішення: Зробіть «export перед рухом» вимогою зміни. Це зменшує невизначеність відновлення і полегшує пізнішу діагностику.

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

cr0x@server:~$ sudo zpool import -f backup
cannot import 'backup': unsupported version or feature

Рішення: -f може переважити перевірки «використовується». Воно не скасує «непідтримувані фічі».
Якщо хтось пропонує «спробуйте -f ще раз», ви маєте право закінчити нараду.

Три корпоративні історії з полі бою

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

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

Під час вікенду обслуговування продукційний хост замінили на новіший образ ОС. Хтось помітив безпечне попередження:
«Some supported features are not enabled on the pool». Вони виконали zpool upgrade, щоб «прибрати попередження».
Пул залишився онлайн. Нічого не вибухнуло. Всі пішли додому і вважали себе відповідальними дорослими.

Два тижні потому в продукції вийшла з ладу материнська плата. Команда пересунула диски в лабораторний хост, щоб відновити сервіси.
Імпорт не вдався з помилкою «unsupported feature(s)». У лабораторного хоста стек ZFS був старішим і не знав фіч, які активували.
План не був невірним через впертість ZFS. План помилявся, бо спирався на неписьмове припущення: «пули ZFS переносні між нашими хостами».

Виправлення було неефектним: вони оновили ZFS у лабораторії, імпортували пул і запланували реальний DR rebuild, де реплікація, а не перекладання дисків, була методом відновлення.
Найкраща частина: постмортем показав, що початкове zpool upgrade не було необхідним для бізнес-фіч. Це був косметичний крок, що перетворився на помножувач відмов.

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

Група інженерів даних працювала на кластері з ZFS. Вони любили оптимізації продуктивності як деякі люди — нові кухонні ножі.
Один інженер ввімкнув кілька властивостей для покращення метаданих і дрібних I/O: xattr=sa, менші recordsize для VM-подібних датасетів,
а згодом спеціальний vdev для метаданих і малих блоків. Бенчмарки покращились. Чарти p99 латентності нарешті перестали соромити команду.

Потім вони вирішили реплікувати пул на менший, дешевший DR сервер. DR сервер мав іншу дистрибуцію ОС і відставав у версії OpenZFS.
Реплікація працювала для простих датасетів. Але щойно вони включили «оптимізовані» датасети, прийом почав падати дивними способами.
Навіть де реплікація пройшла, тест імпорту на DR провалювався: непідтримувані фічі, пов’язані з allocation classes і поведінкою спеціальних vdev.

Причина провалу — не оптимізація як така, а організаційне припущення, що DR має ті самі можливості, що й продукція.
Інженер підвищив продуктивність продукції, ввімкнувши фічі, які фактично підвищили мінімальний діалект ZFS, потрібний для інтерпретації пулу.
DR не був побудований під цей діалект.

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

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

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

Під час термінового оновлення апаратури інженер помітив, що нові хости на новішому релізі OpenZFS і захотів «оновити все, поки ми тут».
Шаблон зміни вимагав перерахувати фіч-флаги, які стануть включеними, і порівняти з найстарішою резервною системою.
Аудит показав, що оновлення активує фічі, яких не підтримує система відкату.

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

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

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

1) Симптом: «cannot import ‘POOL’: unsupported version or feature»

Причина: Пул має active фічі, які поточний хост не підтримує.

Виправлення: Імпортуйте на хості з новішим/співпадаючим OpenZFS, який підтримує ці фічі; потім мігруйте через zfs send/receive у сумісний пул або оновіться ZFS на старому хості.

2) Симптом: у списку «unsupported feature(s): …» є кілька com.delphix:* записів

Причина: Система імпорту занадто стара (або має збірку ZFS без цих фіч), часто на старих аплайенсах або консервативних дистрибутивах.

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

3) Симптом: Можете імпортувати в продукції, але не у DR

Причина: DR відстає з фічами ZFS; зміна властивості датасету в продукції активувала фічі.

Виправлення: Або оновіть DR, щоб відповідати продукції, або переробіть реплікацію, щоб приймати дані у сумісному пулі, створеному під можливості DR.

4) Симптом: Хтось каже «просто виконай zpool upgrade, це рекомендовано»

Причина: Плутання «рекомендовано» з «потрібно». ZFS каже вам, що є нові фічі, а не те, що вони вам потрібні.

Виправлення: Робіть zpool upgrade як контрольовану зміну з оцінкою впливу на сумісність і планом відкату.

5) Симптом: Після увімкнення шифрування старі хости не можуть імпортувати або отримувати реплікацію

Причина: Шифрування опирається на фіч-флаги і також вводить відмінності у обробці ключів; реплікація може вимагати raw send і сумісних фіч.

Виправлення: Перевірте підтримку фіч шифрування на всіх кінцях імпорту/прийому перед увімкненням. Якщо потрібно підтримувати старі кінці, шифруйте на іншому рівні або оновлюйте кінці.

6) Симптом: Пул імпортується, але інструменти поводяться по-різному на системах

Причина: Змішані версії юзерленду і модулів ядра, або часткова підтримка фіч/бекпорти.

Виправлення: Вирівняйте версії ZFS юзерленду і kmod; ставтеся до ZFS як до єдиного блоку, а не як до набору пакетів.

7) Симптом: «zpool import» показує пул, але стан UNAVAIL з «unsupported feature(s)» і також відсутні пристрої

Причина: Дві проблеми одночасно: неповна видимість vdev і невідповідність фіч. Люди ганяються за неправильною першою проблемою.

Виправлення: Спочатку підтвердьте видимість дисків (шляхи by-id), потім вирішуйте підтримку фіч. Якщо фічі не підтримуються, жодне підключення кабелів цього не виправить.

8) Симптом: Реплікація вдається, але тест імпорту отриманого пулу в іншому місці провалюється

Причина: Ви довели send/receive між двома системами, а не переносимість до третьої. Отриманий пул міг теж активувати фічі.

Виправлення: Додайте крок тесту імпорту на найстарішій необхідній платформі як ворота у процесі міграції.

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

Контрольний список A: Перед тим як мігрувати пул фізично переміщаючи диски

Визначте найстарішу систему, яка має імпортувати пул.
Якщо ви не можете її назвати — припускайте, що вона старша, ніж вам хотілося б.
На джерельній системі інвентаризуйте активні фічі.
Збережіть вивід zpool get all | grep feature@ у записі зміни.
На цільовій системі інвентаризуйте підтримувані фічі.
Будь-який - для фічі, що active на пулі, означає «імпорт неможливий».
Зробіть контрольований export.
Експортуйте перед переміщенням апаратури, щоб уникнути брудних «використовується» станів і неоднозначності власності.
Підготуйте «відомо-робочий хост імпорту».
Рятувальне середовище з новим OpenZFS може врятувати вас, коли ціль занадто стара.

Контрольний список B: При створенні пулу, який має бути переносним

Визначте базу переносимості. Наприклад: «повинен імпортитись на OpenZFS 2.1 на Linux і FreeBSD» (те, що реально в вашому парку).
Використовуйте профілі сумісності, якщо платформа їх підтримує. Якщо ні — документуйте «не оновлювати фічі» і забезпечте це процесами.
Виділяйте експериментальні фічі в окремі пули. Тримайте їх як бета-міграції схеми: ізольований blast radius.
Уніфікуйте версії ZFS між середовищами. Продукція та DR не повинні запускати різні основні набори фіч, якщо ви не любите ризиків.
Автоматизуйте виявлення дрейфу фіч. Якщо active фічі змінюються — сповіщайте і розслідуйте.

Контрольний список C: План міграції, що уникає пасток фіч-флагів (рекомендовано)

Створіть новий цільовий пул, що відповідає вашій базі.
Використовуйте обмеження сумісності, якщо доступні; інакше створюйте пул на хості з базовим ZFS і ніколи не оновлюйте його.
Реплікуйте за допомогою zfs send/receive і валідуйте.
Відправляйте датасети поетапно; тестуйте монтування й поведінку застосунків.
Протестуйте імпорт на найстарішій потрібній системі.
Експортуйте/імпортуйте новий пул на тій системі як реальний гейт, а не як думковий експеримент.
Переключіться й тримайте старий пул тільки для читання короткий час.
Це дає безпечніший відкат, ніж «реверсну міграцію».
Лише потім розглядайте ввімкнення нових фіч.
Ставте активацію фіч як зміну, що ламає сумісність API.

Контрольний список D: Що робити, коли ви вже застрягли

Не продовжуйте пробувати випадкові прапори імпорту. Непідтримувані фічі не піддаються наполегливості.
Знайдіть сумісний хост (або завантажувальне середовище), що підтримує потрібні фічі. Імпортуйте там.
Поверніть бізнес онлайн, використовуючи сумісний хост при потребі. Спочатку стабілізуйте; мігруйте пізніше.
Заплануйте міграцію в портативний пул через реплікацію. Це фактичний «пониження», який у вас є.
Після відновлення додайте запобіжні заходи. Моніторинг дрейфу фіч і контрольовані оновлення запобігатимуть повторенню.

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

1) Чи те саме фіч-флаг ZFS і «версія пулу»?

Ні. Версії пулу були одним числом сумісності. Фіч-флаги — це окремі можливості, які можна ввімкнути/активувати незалежно.
Проблеми переносимості все ще існують; вони просто стали більш деталізованими.

2) Якщо я ніколи не запускаю `zpool upgrade`, чи я в безпеці?

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

3) Чи можу я відключити фічу після того, як вона стала active?

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

4) Чи обходить імпорт тільки для читання непідтримувані фічі?

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

5) У чому різниця між «enabled» і «active» у списках фіч?

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

6) Чи можу я реплікувати з пулу з новими фічами на старішу систему?

Іноді. Сумісність zfs send/receive залежить від того, які фічі датасету представлені у стрімі та що підтримує приймач.
Шифрування і певні метадані можуть примусити приймач підтримувати нові фічі.

7) Чому в помилці імпорту згадуються команди com.delphix:*?

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

8) Яке найкраще операційне правило для змішаного парку?

Оберіть базовий набір OpenZFS фіч і ставтеся до нього як до контракту API. Будуйте пули під цю базу і не вмикайте фіч, що її перевищують,
поки ви навмисно не ізолювали їх.

9) Чи безпечно переміщати диски між Linux і FreeBSD, якщо обидві системи кажуть «OpenZFS»?

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

10) Що зберігати в записах зміни для переносимості ZFS?

Щонайменше: zfs version, список фіч пулу (zpool get all | grep feature@) і список підтримуваних фіч цільової системи.
Якщо ви не можете показати сумісність у тексті — у вас немає сумісності.

Висновок: наступні кроки, які можна зробити цього тижня

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

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

Якщо ви нічого іншого не зробите: припиніть запускати zpool upgrade лише тому, що статус це пропонує.
Оновлюйте навмисно, з цільовою сумісністю, або приймайте, що ви спалюєте міст позаду. ZFS запам’ятає. І ваш on-call теж.