Версії модулів ZFS: як уникнути конфліктів між ядром і ZFS

Що означає «ядро проти ZFS» насправді

У Linux ZFS — це модуль ядра плюс інструменти користувача. Модуль ядра виконує реальну роботу: ARC, групи транзакцій, планування вводу/виводу,
контрольні суми, стиснення, стан vdev, імпорт/експорт пулу. Інструменти користувача (zpool, zfs, zdb,
zed) — це плоскость керування.

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

• Модуль не завантажується після оновлення ядра (класичний збій DKMS, відсутні заголовки, несумісні символи).
• Модуль завантажується, але пул не імпортується через очікування щодо прапорів функцій або несумісні формати на диску.
• Інструменти показують одну версію, ядро працює з іншою, що призводить до дивних помилок на кшталт «unsupported pool version» або відсутніх властивостей.
• Помилки під час завантаження, бо initramfs не містить потрібного модуля, і кореневий пул ніколи не з’являється.

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

Жарт №1: Оновлення ядра — це як несподівана тривога пожежної безпеки — тільки пожежа це ваше зберігання, а вихідні покажчики підтримує DKMS.

Цікаві факти та історичний контекст (те, що люди забувають)

1. ZFS почався у Sun Microsystems (середина 2000-х) і ввів наскрізну перевірку контрольних сум, copy-on-write і пулове зберігання, коли більшість файлових систем ще покладалися на «fsck і надію».
2. Linux не постачає ZFS у ядрі переважно через ліцензійні несумісності (CDDL проти GPL). Саме тому ви живете в країні модулів.
3. «Версії пулів» були замінені на «прапори функцій» у сучасному OpenZFS. Прапори функцій дозволяють інкрементальну угоду про можливості замість монолітних номерів версій.
4. FreeBSD та illumos інтегрують ZFS по-іншому. На Linux ви маєте справу з модулем ядра поза деревом; у FreeBSD це ближче до рідної частини системи.
5. DKMS популяризував робочий процес «перезбирати після оновлення ядра», щоб сторонні модулі (ZFS, NVIDIA тощо) не вимагали ручної перекомпіляції щоразу.
6. Включення до initramfs — це питання доступності зберігання, а не «оптимізації завантаження». Якщо ZFS не в initramfs і ваш корінь на ZFS, ви отримаєте запам’ятовувальний досвід.
7. OpenZFS — кросплатформений проєкт. Це означає, що рішення щодо функцій часто обмежені «працює на Linux/FreeBSD/macOS», а не лише вашою дистрибуцією.
8. Версія модуля ядра не те саме, що версія формату пулу. Люди плутають ці поняття. Потім вони «оновлюють» пул і виявляють, що відкотити назад неможливо.

Три рівні сумісності, які потрібно відрізняти

1) Ядро ↔ модуль ZFS (сумісність збірки/ABI)

Запущене ядро експортує символи. Модуль ZFS очікує певні символи й структури. Якщо ядро змінюється, а модуль не відповідає, modprobe zfs зазнає невдачі або завантажиться з відсутніми частинами.

У багатьох дистрибутивах ZFS пакується в одній з двох загальних форм:

• Збірки DKMS: встановлено джерело ZFS; модуль збирається локально для кожного ядра. Гнучко, але тепер ви — конвеєр збірки.
• Попередньо зібрані kmod: пакети модулів, зібрані дистрибутивом для конкретних ядер. Менш гнучко, зазвичай передбачуваніше.

2) Інструменти користувача ZFS ↔ модуль ZFS (сумісність ioctl/API)

Інструменти zfs/zpool спілкуються з ядром через ioctl і інтерфейси sysfs/proc. Якщо userland новіший за модуль
(або навпаки), ви можете отримати дивну поведінку: відсутні властивості, «unknown command» або оманливі підказки «pool is outdated».

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

3) Пул на диску ↔ реалізація ZFS (сумісність прапорів функцій)

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

Небезпечна команда не zpool import. Це zpool upgrade. Перша веде переговори. Друга робить незворотні зміни.

Один корисний принцип на стікері: ось перефразована ідея від Werner Vogels (CTO Amazon): Будуйте системи так, ніби щось зламається, і робіть відновлення рутинним. — перефразована ідея

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

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

Перше: чи завантажений модуль і чи саме той, який ви думаєте?

• Перевірте uname -r, потім підтвердіть, що модулі ZFS завантажені для цього ядра.
• Перегляньте журнали ядра на предмет «Unknown symbol» або невідповідності vermagic.
• Підтвердіть, що інструменти користувача та модуль ядра мають узгоджені версії.

Друге: чи видно пул і чи його можна імпортувати?

• zpool import без імпорту: чи перелічує він пул?
• Спробуйте zpool import -N (не монтувати), щоб відокремити імпорт від проблем з монтуванням/властивостями.
• Шукайте прапори функцій, які не підтримуються на цьому хості.

Третє: чи це проблема завантаження/initramfs?

• Якщо корінь на ZFS і ви опинилися в оболонці initramfs: перевірте, чи /lib/modules/$(uname -r) містить ZFS, перегенеруйте initramfs.
• Підтвердіть, що завантажено правильне ядро (не fallback-ядро без відповідних пакунків kmod ZFS).

Четверте: інциденти продуктивності, що виглядають як «проблеми версій»

Іноді система завантажується нормально, а проблеми з’являються лише під навантаженням. Якщо ZFS тихо перейшов на іншу збірку модуля, або ви запустили
комбінацію ядра/ZFS з відомою регресією, симптом — «ZFS повільний» або «довге txg», а не «несумісність модуля».

• Перевірте статистику ARC і тиск пам’яті.
• Перегляньте часи синхронізації txg та насичення I/O.
• Перевірте, чи ви на новому оновленому ядрі без відповідного попередньо зібраного ZFS kmod (DKMS щось зібрав, але чи вдало?).

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

Нижче — реальні завдання, які можна виконати на типовому хості Linux з пакетами OpenZFS. Команди показані з репрезентативним виводом; ваше
середовище відрізнятиметься. Суть — що означає вивід і що робити далі.

Завдання 1: Підтвердіть запущене ядро (ціль, яку потрібно відповідати)

cr0x@server:~$ uname -r
6.8.0-52-generic

Значення: Модуль ZFS має бути зібраний саме для 6.8.0-52-generic.
Рішення: Будь-які кроки зі збірки/встановлення модуля ZFS мають посилатися на цю версію ядра. Якщо ви налагоджуєте, запам’ятайте це значення.

Завдання 2: Перевірте, чи завантажений модуль ZFS

cr0x@server:~$ lsmod | grep -E '^zfs|^spl'
zfs                  6340608  6
spl                   131072  1 zfs

Значення: У ядрі завантажені ZFS і SPL (SPL — Solaris Porting Layer).
Рішення: Якщо нічого не відображається, спробуйте завантажити модуль і дивіться помилки в наступних завданнях.

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

cr0x@server:~$ sudo modprobe zfs
modprobe: ERROR: could not insert 'zfs': Unknown symbol in module, or unknown parameter (see dmesg)

Значення: Бінарний модуль не відповідає експортованим символам ядра (класична розбіжність після оновлення ядра).
Рішення: Негайно перевірте dmesg, потім перевірте/перевстановіть/перезберіть модулі ZFS для цього ядра або завантажте попереднє сумісне ядро.

Завдання 4: Прочитайте журнали ядра на предмет vermagic/symbol mismatch

cr0x@server:~$ dmesg | tail -n 30
[  112.941230] zfs: disagrees about version of symbol module_layout
[  112.941251] zfs: Unknown symbol spl_kmem_cache_alloc (err -22)
[  112.941260] zfs: Unknown symbol spl_kmem_cache_free (err -22)

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

Завдання 5: Підтвердіть встановлені пакети ZFS (userland і kmods)

cr0x@server:~$ apt-cache policy zfsutils-linux zfs-dkms libzfs4linux
zfsutils-linux:
  Installed: 2.2.2-0ubuntu9
  Candidate: 2.2.2-0ubuntu9
zfs-dkms:
  Installed: 2.2.2-0ubuntu9
  Candidate: 2.2.2-0ubuntu9
libzfs4linux:
  Installed: 2.2.2-0ubuntu9
  Candidate: 2.2.2-0ubuntu9

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

Завдання 6: Перевірте стан DKMS (чи він справді зібрав для поточного ядра?)

cr0x@server:~$ dkms status
zfs/2.2.2, 6.8.0-52-generic, x86_64: installed

Значення: DKMS стверджує, що збірка модуля ZFS існує для запущеного ядра.
Рішення: Якщо написано «added» або «built», але не «installed», ймовірно, збірка напівготова. Перезберіть і встановіть.

Завдання 7: Примусово перезібрати DKMS для поточного ядра (коли підозрюєте зламану збірку)

cr0x@server:~$ sudo dkms remove -m zfs -v 2.2.2 --all
Deleting module zfs-2.2.2 completely from the DKMS tree.

cr0x@server:~$ sudo dkms install -m zfs -v 2.2.2 -k 6.8.0-52-generic
Building module:
Cleaning build area...
make -j8 KERNELRELEASE=6.8.0-52-generic...
Installing module...
DKMS: install completed.

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

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

cr0x@server:~$ modinfo -F vermagic zfs
6.8.0-52-generic SMP preempt mod_unload modversions

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

Завдання 9: Переконайтеся, що інструменти й модуль повідомляють узгоджені версії ZFS

cr0x@server:~$ zfs version
zfs-2.2.2-0ubuntu9
zfs-kmod-2.2.2-0ubuntu9

Значення: Інструменти та модуль ядра синхронізовані.
Рішення: Якщо вони відрізняються (наприклад, userland новіший за kmod), очікуйте відсутніх властивостей і дивних помилок. Вирівняйте пакети; не «ліпіть» тимчасові обхідні шляхи.

Завдання 10: Перелік пулів доступних для імпорту (без фактичного імпорту)

cr0x@server:~$ sudo zpool import
   pool: tank
     id: 1283947562198834211
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        tank        ONLINE
          mirror-0  ONLINE
            sda3    ONLINE
            sdb3    ONLINE

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

Завдання 11: Імпортуйте без монтування датасетів (відокремити імпорт від проблем з монтуванням)

cr0x@server:~$ sudo zpool import -N tank
cr0x@server:~$ zpool status -x
all pools are healthy

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

Завдання 12: Перегляньте прапори функцій і сумісність перед тим, як «оновлювати» щось

cr0x@server:~$ zpool get all tank | grep feature@
tank  feature@async_destroy          enabled   local
tank  feature@encryption             enabled   local
tank  feature@project_quota          active    local

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

Завдання 13: Подивіться, які оновлення доступні (підтримка рішення «тільки для читання»)

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

The following pools are formatted with legacy version numbers and can be upgraded to use feature flags:
  none

The following pools can be upgraded:
  pool 'tank' has the following supported feature flags:
    spacemap_histogram
    extensible_dataset
    bookmarks
    filesystem_limits

Значення: «Can be upgraded» означає «ви можете зробити зміни на диску, які ця система розуміє».
Рішення: Виконуйте zpool upgrade -a лише якщо ви готові зробити пул потенційно неімпортованим на старіших системах. Більшість середовищ не має автооновлювати пул.

Завдання 14: Визначте, чи використовуєте ви попередньо зібрані kmod чи DKMS (форма пакування важлива)

cr0x@server:~$ dpkg -l | grep -E 'zfs-dkms|zfs-kmod|spl-dkms' | awk '{print $1, $2, $3}'
ii zfs-dkms 2.2.2-0ubuntu9

Значення: Цей хост покладається на DKMS для компіляції модуля для кожного ядра.
Рішення: Сприймайте оновлення ядра як «подію зборки». Переконайтеся, що заголовки, компілятор і гачки DKMS працюють перед перезавантаженням.

Завдання 15: Перевірте, чи initramfs містить модулі ZFS (перевірка надійності завантаження)

cr0x@server:~$ lsinitramfs /boot/initrd.img-6.8.0-52-generic | grep -E '/zfs\.ko|/spl\.ko' | head
usr/lib/modules/6.8.0-52-generic/updates/dkms/spl.ko
usr/lib/modules/6.8.0-52-generic/updates/dkms/zfs.ko

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

Завдання 16: Перегенеруйте initramfs після змін модуля ZFS (щоб завантаження бачило нову реальність)

cr0x@server:~$ sudo update-initramfs -u -k 6.8.0-52-generic
update-initramfs: Generating /boot/initrd.img-6.8.0-52-generic

Значення: Образ initramfs згенеровано з поточними модулями та гачками.
Рішення: Після перезборки DKMS завжди оновлюйте initramfs на хостах, що імпортують пули під час завантаження (особливо root-on-ZFS).

Завдання 17: Підтвердіть здоров’я пулу і відкиньте «реальні» проблеми з обладнанням, що маскуються під проблему версій

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 00:21:43 with 0 errors on Thu Dec 19 03:11:52 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda3    ONLINE       0     0     0
            sdb3    ONLINE       0     0     0

errors: No known data errors

Значення: Зберігання на рівні ZFS здорове.
Рішення: Якщо бачите помилки контрольних сум або деградовані vdev, не звинувачуйте версії. Виправте апарат/шляхи; постійні зміни версій під час реальної відмови подовжують простій.

Завдання 18: Перевірте події ZED і стан сервісу (іноді справа не в завантаженні політики)

cr0x@server:~$ systemctl status zfs-zed.service
● zfs-zed.service - ZFS Event Daemon (zed)
     Loaded: loaded (/lib/systemd/system/zfs-zed.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2025-12-26 08:14:12 UTC; 10min ago

Значення: ZED працює; він може обробляти hotplug і повідомлення про помилки.
Рішення: Якщо ZED не працює, ви пропустите автоматичну заміну і оповіщення. Це не викличе несумісність модулів, але приховає історію до масштабної проблеми.

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

Інцидент через неправильне припущення: «Оновлення ядра — лише патчі безпеки»

Середня SaaS-компанія використовувала ZFS на Linux для реплік баз даних. У них був тижневий вікно патчів, і оновлення ядра вважали «рутінною гігієною». Збереження даних не було в тикеті змін, бо, цитата, «ZFS вже встановлено».

Ранок патчів оновив ядро і перезавантажив флот вузлів. Частина вузлів повернулась нормально. Декілька — ні. Зламані впали в emergency-mode з відсутніми файловими системами, і на виклику побачили звичний червоний підказ: «cannot import pool».

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

Виправлення не було героїчним. Встановили правильні заголовки, перезібрали DKMS, перегенерували initramfs і перезавантажили. Потім змінили процес патчування: оновлення ядра — це зміни зберігання, якщо ви використовуєте модулі поза ядром. Неправильне припущення полягало в думці, що ОС та зберігання — різні шари. У Linux вони — сусіди.

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

Компанія стандартизувала ZFS для зберігання артефактів збірки. Хтось помітив, що zpool upgrade пропонує безліч функцій і вирішив:
більше функцій = краще. Вони оновили пули по основному кластеру під час тихого періоду. Негайних збоїв не було.

Через місяці тестування аварійного відновлення перемістили реплікований пул на менше стендбай-середовище, що відставало на пару релізів OpenZFS.
Імпорт не пройшов через не підтримувані функції. Стендбай-хост не був «неправильним», він просто був старішим.

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

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

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

Велике підприємство мало змішані навантаження: зберігання VM, аналітика й частково застарілий NFS. У них були бюджет на хороший хардвер і терпіння для процесів.
Їхнє управління змінами не було гламурним, але працювало.

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

Потім вийшло оновлення безпеки ядра, і всі панікували. Вони — ні. Нове ядро спочатку потрапило на стаджинг, перевірили DKMS-збірки,
підтвердили вміст initramfs, провели перезавантажувальні тести і таргетовані I/O перевірки. Лише потім рухались у production.

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

Жарт №2: Єдина річ гірша за несподіване оновлення ZFS — це усвідомити, що ваш план DR був «імпортуй пул і сподівайся».

Як оновлювати, не перетворюючи пул на науковий проєкт

Правило 1: Розділяйте «оновлення програмного забезпечення» і «оновлення формату на диску»

Оновлення пакетів (userland ZFS + kmod) є зворотними: ви можете відкотити пакети, завантажити старе ядро або перевстановити відому добру версію.
Оновлення прапорів функцій пулу практично не відкатується.

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

Правило 2: Намагайтеся парувати ядра і модулі ZFS свідомо

На системах з DKMS оновлення ядра — це подія збірки. Ваш CI/CD може бути ідеальним, а гачки DKMS все одно можуть провалюватися, бо на одному хості немає заголовків або нове ядро змінило внутрішній інтерфейс.

Якщо у вас флот, прагніть до:

• Єдиної серії ядер для кожного класу вузлів (storage vs compute)
• Автоматичної перевірки, що DKMS зібрав модуль для встановлених ядер
• Тестового перезавантаження перед оголошенням оновлення «завершеним»

Правило 3: Ставте переносимість пулу як пріоритет (або офіційно відмовтесь від неї)

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

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

Правило 4: Не змішуйте репозиторії дистрибутива і «довільні збірки» у production-збереженні

Змішування vendor-ядра, HWE-ядра, backports та сторонніх збірок ZFS може працювати — поки не зламається. Тоді ви налагоджуєте екосистему, а не систему. Ви хочете найменшу кількість рухомих частин, яка задовольняє вимоги.

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

Правило 5: Віддавайте перевагу передбачуваним шляхам оновлення, а не максимуму новизни

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

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

1) Симптом: modprobe zfs не вдається після оновлення ядра

Корінна причина: Модуль ZFS не зібраний для нового ядра; відсутні заголовки; збірка DKMS не вдалася; невідповідність vermagic.

Виправлення: Встановіть відповідні заголовки ядра, перезберіть DKMS для цього ядра, підтвердіть, що modinfo -F vermagic zfs збігається, перегенеруйте initramfs, перезавантажтеся.

2) Симптом: zfs version показує userland новіший за kmod (або навпаки)

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

Виправлення: Вирівняйте пакети до однієї версії OpenZFS з одного репо-каналу. Не оновлюйте лише zfsutils-linux без частини для ядра.

3) Симптом: Пул не імпортується на іншому хості; помилка згадує unsupported features

Корінна причина: Прапори функцій, ввімкнені в пулі, не підтримуються реалізацією ZFS на тому хості.

Виправлення: Імпортуйте на хості, що підтримує ці функції, потім мігруйте дані (send/receive, rsync, реплікація на рівні додатку). Щоб уникнути повторення: не вмикайте функції без перевірки сумісності у всьому флоті.

4) Симптом: Система впала в initramfs; кореневий пул не знайдено

Корінна причина: Модулі ZFS відсутні в initramfs або завантажуються занадто пізно; завантажено неправильне ядро; initramfs не перегенеровано після DKMS.

Виправлення: Завантажте старе робоче ядро, перегенеруйте initramfs для бажаного ядра, переконайтеся, що гачки ZFS включені, і протестуйте перезавантаження.

5) Симптом: Після оновлення монтування зависають або імпорт повільний

Корінна причина: Не завжди версії. Може бути зміна шляхів пристроїв, проблеми multipath, відсутність імен by-id або txg-стейл через тайм-аути I/O.

Виправлення: Перевірте dmesg на предмет помилок I/O, підтвердіть стабільність імен пристроїв, перевірте zpool status і результати scrub, потім дослідіть показники продуктивності (ARC, txg, черги vdev).

6) Симптом: Ви «вирішили» перезавантаженням, а потім при наступному запуску знову ламається

Корінна причина: Ви завантажили модуль вручну, але не зробили зміни постійною: не перегенерували initramfs, або DKMS зібрав для одного ядра, а ви завантажуєте інше.

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

7) Симптом: zpool import бачить пул, але імпорт не вдається з помилкою «missing log» або «cannot open» пристроїв

Корінна причина: Зміни в іменах пристроїв між перезавантаженнями (наприклад, /dev/sdX), відсутній розділ, збій HBA або гонка udev; це не першопричина версій модуля.

Виправлення: Використовуйте постійні шляхи пристроїв (by-id), перевірте HBA, підтвердіть розділи, і лише потім звинувачуйте версії ПЗ.

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

Чеклист A: Перед оновленням ядра на хостах з ZFS

1. Підтвердіть, чи цей хост використовує DKMS або попередньо зібрані kmod (Завдання 14).
2. Переконайтеся, що заголовки ядра для нового ядра будуть встановлені разом із ядром.
3. Переконайтеся, що інструменти збірки присутні (компілятор, make) якщо використовується DKMS.
4. Виконайте суху перевірку: після встановлення нового ядра (але перед перезавантаженням) перевірте, що dkms статус показує збірку модуля для нового ядра.
5. Перегенеруйте initramfs для нового ядра (Завдання 16) і підтвердіть, що він містить zfs.ko (Завдання 15).
6. Майте план відкату: переконайтеся, що старе ядро залишається встановленим і можна завантажити.

Чеклист B: Безпечне оновлення пакетів OpenZFS (userland + модуль)

1. Оновлюйте пакети синхронно (не оновлюйте лише zfsutils).
2. Підтвердіть, що zfs version показує однакові userland і kmod (Завдання 9).
3. Підтвердіть, що modinfo -F vermagic zfs збігається з uname -r (Завдання 1 і 8).
4. Перевірте стан пулу (zpool status -v) до і після (Завдання 17).
5. Реєструйте перезавантаження в контрольоване вікно і перевіряйте поведінку імпорту/монтування.

Чеклист C: Як вирішувати, чи запускати zpool upgrade

1. Запишіть причину (конкретна потрібна функція, виправлення продуктивності, операційна необхідність).
2. Підтвердіть, що кожна система, яка може імпортувати пул, підтримує ті функції, які ви ввімкнете.
3. Підтвердіть, що резервні копії/реплікація актуальні.
4. Надавайте перевагу оновленню тестового пулу спочатку, перевірте send/receive, scrub і процедури failover/import.
5. Оновлюйте по одному пулу за раз. Слідкуйте за ним. Потім рухайтесь далі.

Покроково: Коли хост не імпортує пули після перезавантаження

1. Підтвердіть запущене ядро (uname -r).
2. Перевірте завантаження модулів (lsmod, modprobe zfs).
3. Якщо modprobe зазнає невдачі, читайте dmesg на предмет помилок символів/vermagic.
4. Підтвердіть стан DKMS для цього ядра; перезберіть за потреби.
5. Перевірте, що initramfs містить модулі ZFS; перегенеруйте, якщо відсутні.
6. Лише після вирішення проблем з модулем: виконайте zpool import і спробуйте zpool import -N.
7. Перевірте прапори функцій і обмеження переносимості при імпорті на іншому хості.

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

1) У чому різниця між «версією ZFS» і «версією пулу»?

«Версія ZFS» зазвичай означає реліз програмного забезпечення (userland і модуль ядра). «Версія пулу» раніше була монолітним числом; сучасний OpenZFS використовує прапори функцій.
Програмне забезпечення можна оновити без змін на диску. Ввімкнення нових функцій пулу змінює сумісність на диску.

2) Якщо zfs version показує розбіжність між userland і kmod, чи завжди це фатально?

Не завжди негайно фатально. Це завжди погана ознака. Можуть виникнути відсутні властивості, дивні помилки або тонкі відмінності в поведінці.
У production вирівняйте їх. «Працює у мене» — це саме те, як виводяться майбутні простої.

3) Чому ZFS ламається після оновлення ядра, коли ext4 — ні?

ext4 знаходиться в дереві ядра. ZFS — ні. Оновлення ядра можуть змінювати внутрішні інтерфейси, і модулі поза деревом мають бути перебудовані (DKMS) або замінені на відповідні попередньо зібрані модулі.

4) Що обирати: DKMS чи попередньо зібрані kmod?

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

5) Чи можна понизити пул після запуску zpool upgrade?

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

6) Чи безпечно запускати zpool upgrade -a під час рутинних оновлень?

Ні. Це еквівалент форматування накопичувача під приводом «очистки». Оновлюйте пули свідомо й рідко, після перевірки оточення відновлення/імпорту.

7) Мій пул імпортується вручну, але не під час завантаження. У чому справа?

Зазвичай це initramfs або порядок запуску. Модуль ZFS може бути відсутній в initramfs, або порядок сервісів неправильний (ключі недоступні, пристрої не готові).
Перевірте вміст initramfs і systemd-юнити, і тестуйте з zpool import -N під час налагодження завантаження.

8) Чому dkms status каже «installed», але modprobe все одно не працює?

DKMS може бути «installed» для іншого ядра, ніж те, яке ви завантажили, або у вас може бути кілька ядер і ви завантажуєте модулі з невірного дерева.
Перевірте uname -r, modinfo -F vermagic і шлях модуля під /lib/modules/$(uname -r).

9) Чи є невідповідність ядра/ZFS лише проблемою завантаження?

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

10) Яка найнадійніша стратегія переносимості для DR?

Тримайте DR-хости на рівні або новішому OpenZFS, ніж production, і уникайте ввімкнення прапорів пулу, поки DR не підтверджено.
Якщо переносимість критична, стандартизуйте прапори функцій і документуйте їх як контракт API.

Висновок: наступні кроки, що дійсно зменшують шум дзвінків

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

Зробіть це далі:

1. Обирайте модель оновлень (DKMS vs prebuilt) і стандартизуйте її за класом вузла.
2. Додайте перевірку перед перезавантаженням: підтвердіть, що DKMS зібрав для цільового ядра і initramfs містить модулі ZFS.
3. Припиніть автоматичні оновлення пулів. Вимагається явне рішення і перевірка сумісності переносимості.
4. Документуйте односторінковий «Швидкий план діагностики» і змусьте on-call слідувати йому. Послідовність перемагає креативність о 02:00.