ZFS zpool import -d: пошук пулів при зміні шляхів пристроїв

Що насправді робить zpool import -d

zpool import — це інструмент ZFS для «знайти пули, що існують, але наразі не імпортовані». Коли ви запускаєте його без аргументів, він сканує набір стандартних місць для пристроїв, які можуть містити ZFS-лейбли (метадані на початку/кінці кожного vdev).

zpool import -d <dir> змінює область пошуку. Ви кажете ZFS: «Шукай у цій директорії блокові пристрої (або файли), які можуть містити ZFS-лейбли». Він просканує записи в цій директорії, відкриє пристрої, прочитає лейбли і спробує зібрати кандидатні пули.

Ключові поведінки, які важливі в продакшні

• -d вказує, де шукати, а не що імпортувати. Воно впливає на виявлення. Імпорт все одно слідує звичайним правилам (перевірка hostid/активного пулу, поведінка mountpoint тощо).
• Ви можете вказувати кілька опцій -d. Це золото, коли у вас суміш /dev/disk/by-id, multipath-пристроїв або тимчасових директорій.
• -d може вказувати на директорію з файлами. Так: імпорт пулів з образів файлів (для судової експертизи або лабораторних відновлень) — реальна річ.
• Виявлення може уповільнитися через «занадто велику директорію». Вказання /dev на системі з великою кількістю вузлів пристроїв, застарілими multipath-мапами або дивними контейнерними монтуваннями може перетворити «швидке сканування» в «чому зависло».

Жарт №1: Якщо ви колись довіряли іменам /dev/sdX у продакшні, ви або дуже відважні, або ніколи не перезавантажували сервер.

Чому змінюються шляхи пристроїв (і чому ZFS цим переймається)

Імена блокових пристроїв у Linux, як-от /dev/sda, призначаються на основі порядку виявлення. Порядок виявлення змінюється, бо світ змінюється: різні таймінги прошивки, скидання HBA, оновлення ядра, диск, що сьогодні розкручується повільніше, переобчислення PCIe шини або multipath, який обирає інший маршрут раніше.

ZFS зберігає ідентичність vdev у лейблах, використовуючи стабільні ідентифікатори, коли це можливо, але йому все одно потрібно, щоб ОС представила вузол пристрою, який він може відкрити і прочитати. Якщо ваш пул був створений на /dev/sdb, а пізніше ви налаштували cachefile або systemd-сервіси, які очікують ці шляхи, ви можете отримати завантаження, яке не імпортує пул автоматично, або імпорт, що використовує несподіваний шлях.

Поширені сімейства шляхів, з якими ви зіткнетесь

• /dev/sdX: коротко, зручно і нестабільно при перезавантаженнях та зміні топології.
• /dev/disk/by-id/: стабільно, базується на WWN/серійному номері; переважно для серверів.
• /dev/disk/by-path/: відносно стабільно, описує шлях шини; може змінитись при перестановці кабелів/HBA.
• /dev/mapper/mpath*: multipath-пристрої; стабільні, але потребують правильної конфігурації multipath (і дисципліни).
• /dev/zvol/: ZFS-томи, представлені як блокові пристрої; не стосуються імпорту, але часто плутаються в чатах по інцидентах.

Цікаві факти та історичний контекст

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

1. ZFS зберігає кілька лейблів на пристрої. Лейбли записуються як на початку, так і в кінці кожного члена vdev, що підвищує стійкість до часткових перезаписів і робить можливим виявлення навіть коли один кінець пошкоджено.
2. Ранній дизайн ZFS надавав пріоритет самоописуванню. Пули описують себе: топологію, GUID vdev і конфігурація вкладені на диску, а не в окремій «базі даних менеджера томів».
3. Перевірка «hostid» існує, щоб завадити імпорту активного пулу на іншій системі. Це функція безпеки проти split-brain та подвійного монтування.
4. /dev/sdX іменування спеціально не стабільне. Linux розглядає це як деталь реалізації, а не контракт інтерфейсу. Ось чому існують udev шляхи by-id/by-path.
5. ZFS передує багатьом сучасним очікуванням завантаження Linux. Багато проблем «ZFS не імпортувався при завантаженні» насправді пов’язані з порядком ініціалізації, таймінгом udev або обробкою cachefile — сучасні завантажувачі швидкі, а сховище іноді ні.
6. Multipath може зробити імпорт схожим на «примару». Якщо існують і сирі шляхи, і multipath-мапи, ZFS може бачити дублікати. Ваш пул може бути «імпортованим» двічі, і жоден з варіантів не буде тим, що ви хочете.
7. Імпорт лише для читання — навмисна можливість. Це дозволяє безпечно проводити експертизу та зменшує ризик, коли ви не впевнені, чи був пул коректно експортований.
8. ZFS може імпортувати пули з звичайних файлів. Це не трюк для вечірки; так багато лабораторій тестують оновлення і деякі інцидент-команди роблять швидкі офлайн-перевірки відновлення.

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

Коли пул «зникає» після зміни шляхів, ваша мета — швидко відповісти на три питання: (1) чи видно диски, (2) чи читаються ZFS-лейбли, і (3) чи щось блокує імпорт (hostid, активне використання, multipath, відсутні vdev).

Перше: підтвердьте, що ОС бачить апаратне забезпечення, яке ви очікуєте

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,MODEL,SERIAL,WWN,FSTYPE,MOUNTPOINTS
NAME   TYPE  SIZE MODEL            SERIAL        WWN                FSTYPE MOUNTPOINTS
sda    disk  1.8T HGST_HUS724...    K7J1...       0x5000cca25...             
sdb    disk  1.8T HGST_HUS724...    K7J2...       0x5000cca25...             
nvme0n1 disk 3.6T SAMSUNG_MZ...     S4EV...       0x0025385...               

Інтерпретація: якщо очікувані WWN/серійні номери відсутні, це ще не проблема ZFS. Це кабелювання, HBA, експандер, multipath або мертвий диск. Якщо диски присутні, але імена змінилися, продовжуйте далі.

Друге: перевірте, що ZFS вважає імпортованим

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

        tank                          ONLINE
          raidz1-0                    ONLINE
            /dev/sdb                  ONLINE
            /dev/sdc                  ONLINE
            /dev/sdd                  ONLINE

Інтерпретація: якщо тут показані шляхи /dev/sdX, яким ви більше не довіряєте, ви все ще можете імпортувати — але ви повинні виправити постійні імена одразу після. Якщо нічого не відображається, вам ймовірно потрібно вказати -d, щоб скерувати ZFS у правильний простір імен.

Третє: шукайте в стабільному просторі імен і перевіряйте дублікати

cr0x@server:~$ sudo zpool import -d /dev/disk/by-id
   pool: tank
     id: 12345678901234567890
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        tank                                            ONLINE
          raidz1-0                                      ONLINE
            wwn-0x5000cca25abcd001                      ONLINE
            wwn-0x5000cca25abcd002                      ONLINE
            wwn-0x5000cca25abcd003                      ONLINE

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

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

cr0x@server:~$ sudo zpool import tank
cannot import 'tank': pool may be in use from other system
use '-f' to import anyway

Інтерпретація: не додавайте -f рефлекторно. Переконайтеся, що пул не дійсно імпортовано десь ще (або не був некоректно експортований) і переконайтеся, що ви не бачите ті ж LUN через два шляхи (помилки SAN zoning трапляються).

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

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

Завдання 1: Показати імпортовані пули і шляхи пристроїв, які зараз бачить ZFS

cr0x@server:~$ sudo zpool import
   pool: backup
     id: 8811223344556677889
  state: DEGRADED
status: One or more devices could not be opened.
action: The pool can be imported despite missing devices.
   see: http://zfsonlinux.org/msg/ZFS-8000-2Q
 config:

        backup                         DEGRADED
          mirror-0                     DEGRADED
            /dev/sda                   ONLINE
            15414153927465090721       UNAVAIL

Інтерпретація: ZFS повідомляє, що пристрій за GUID відсутній. Це не «перейменування пристрою»; це «пристрій відсутній» (або присутній у іншому просторі імен, який ви не сканували).

Завдання 2: Шукати у конкретній директорії пристроїв (основи -d)

cr0x@server:~$ sudo zpool import -d /dev/disk/by-id
   pool: backup
     id: 8811223344556677889
  state: ONLINE
action: The pool can be imported using its name or numeric identifier.
 config:

        backup                                           ONLINE
          mirror-0                                       ONLINE
            wwn-0x5000c500a1b2c3d4                        ONLINE
            wwn-0x5000c500a1b2c3e5                        ONLINE

Інтерпретація: «втрачений» диск насправді був присутній; ви просто не дивилися в потрібне місце.

Завдання 3: Використовувати кілька -d для покриття змішаних середовищ

cr0x@server:~$ sudo zpool import -d /dev/disk/by-id -d /dev/mapper
   pool: sanpool
     id: 4000111122223333444
  state: ONLINE
action: The pool can be imported using its name or numeric identifier.
 config:

        sanpool                                          ONLINE
          mirror-0                                       ONLINE
            mpatha                                       ONLINE
            mpathb                                       ONLINE

Інтерпретація: якщо ваше сховище multipath-оване, віддавайте перевагу імпорту через /dev/mapper/mpath* або через by-id для multipath-пристрою, а не через сирі /dev/sdX. Послідовність важливіша за смак.

Завдання 4: Виявити дублікати представлення пристроїв (сирі шляхи vs multipath)

cr0x@server:~$ ls -l /dev/disk/by-id | grep -E 'wwn|dm-uuid|mpath' | head
lrwxrwxrwx 1 root root  9 Dec 25 09:10 dm-uuid-mpath-3600508b400105e210000900000490000 -> ../../dm-2
lrwxrwxrwx 1 root root  9 Dec 25 09:10 mpath-3600508b400105e210000900000490000 -> ../../dm-2
lrwxrwxrwx 1 root root  9 Dec 25 09:10 wwn-0x600508b400105e210000900000490000 -> ../../sdb

Інтерпретація: якщо той самий LUN відображається як dm-* і як sd*, ви повинні вирішити, який з них має використовувати ZFS. Імпорт за сирими sd* пристроями при активному multipath — це запрошення для переривчастих I/O помилок і флапів шляхів у ваш пул.

Завдання 5: Подивитися ZFS-лейбли напряму (перевірка здорового глузду)

cr0x@server:~$ sudo zdb -l /dev/disk/by-id/wwn-0x5000cca25abcd001 | head -n 25
------------------------------------
LABEL 0
------------------------------------
    version: 5000
    name: 'tank'
    state: 0
    txg: 1234567
    pool_guid: 12345678901234567890
    vdev_guid: 11112222333344445555
    top_guid: 66667777888899990000
    guid: 11112222333344445555

Інтерпретація: якщо zdb -l може прочитати лейбл, виявлення має працювати. Якщо не може — можлива проблема з дозволами на пристрій, помираючий диск або ви вказали не те (розділ vs весь диск, mapper vs сирий).

Завдання 6: Імпорт за числовим ID пулу (корисно коли імена збігаються або плутанина)

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

cr0x@server:~$ sudo zpool import -d /dev/disk/by-id 12345678901234567890

Інтерпретація: імпорт за ID запобігає помилкам, коли хтось перейменував пули непослідовно між середовищами (так, таке буває).

Завдання 7: Імпорт лише для читання, щоб безпечно перевірити

cr0x@server:~$ sudo zpool import -o readonly=on -d /dev/disk/by-id tank
cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            ONLINE       0     0     0
          raidz1-0                                      ONLINE       0     0     0
            wwn-0x5000cca25abcd001                      ONLINE       0     0     0
            wwn-0x5000cca25abcd002                      ONLINE       0     0     0
            wwn-0x5000cca25abcd003                      ONLINE       0     0     0

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

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

cr0x@server:~$ sudo zpool import -N -d /dev/disk/by-id tank
cr0x@server:~$ zfs list -o name,mountpoint,canmount -r tank | head
NAME            MOUNTPOINT  CANMOUNT
tank            /tank       on
tank/home       /home       on
tank/pg         /var/lib/pg on

Інтерпретація: -N імпортує пул, але не монтує датасети. Це чудово, коли ви хочете встановити властивості, перевірити ключі шифрування або уникнути автоматичного запуску бази даних, яка одразу впаде через відсутні мережеві залежності.

Завдання 9: Показати шляхи vdev, які ZFS використовуватиме після імпорту (і виправити їх)

cr0x@server:~$ zpool status -P tank
  pool: tank
 state: ONLINE
config:

        NAME                       STATE     READ WRITE CKSUM
        tank                       ONLINE       0     0     0
          raidz1-0                 ONLINE       0     0     0
            /dev/sdb               ONLINE       0     0     0
            /dev/sdc               ONLINE       0     0     0
            /dev/sdd               ONLINE       0     0     0

Інтерпретація: -P показує повні шляхи. Якщо ви бачите /dev/sdX, вирішіть, чи можете ви це терпіти. У більшості середовищ — ні.

Щоб мігрувати до стабільних імен by-id, зазвичай експортують і повторно імпортовують пул використовуючи бажані шляхи:

cr0x@server:~$ sudo zpool export tank
cr0x@server:~$ sudo zpool import -d /dev/disk/by-id tank
cr0x@server:~$ zpool status -P tank | sed -n '1,25p'
  pool: tank
 state: ONLINE
config:

        NAME                                      STATE     READ WRITE CKSUM
        tank                                      ONLINE       0     0     0
          raidz1-0                                ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000cca25abcd001 ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000cca25abcd002 ONLINE       0     0     0
            /dev/disk/by-id/wwn-0x5000cca25abcd003 ONLINE       0     0     0

Інтерпретація: це найпростіша стабілізація шляхів: змінюєте виявлення при імпорті і даєте ZFS записати обрані шляхи.

Завдання 10: Безпечно обробляти «pool may be in use» (hostid / примусовий імпорт)

cr0x@server:~$ sudo zpool import -d /dev/disk/by-id tank
cannot import 'tank': pool may be in use from other system
use '-f' to import anyway

Інтерпретація: поширено після переміщення дисків на новий хост, відновлення VM із снапшоту або після некоректного вимкнення, коли стара система так і не експортувала пул.

Якщо ви впевнені, що пул не активний десь ще, імпортуйте примусово:

cr0x@server:~$ sudo zpool import -f -d /dev/disk/by-id tank

Інтерпретація: прапорець -f обходить перевірку host. Використовуйте його як бензопилу: ефективно, але тільки коли ви тримаєте її правильно.

Завдання 11: Відновлення після відсутнього cachefile / неправильних припущень про cachefile

cr0x@server:~$ sudo zpool get cachefile tank
NAME  PROPERTY  VALUE     SOURCE
tank  cachefile /etc/zfs/zpool.cache local

cr0x@server:~$ ls -l /etc/zfs/zpool.cache
ls: cannot access '/etc/zfs/zpool.cache': No such file or directory

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

Після імпорту пулу відновіть cachefile:

cr0x@server:~$ sudo zpool set cachefile=/etc/zfs/zpool.cache tank
cr0x@server:~$ sudo zpool export tank
cr0x@server:~$ sudo zpool import -d /dev/disk/by-id tank

Інтерпретація: експорт і імпорт оновлюють cachefile у узгоджений спосіб на багатьох системах. (Точна інтеграція з завантаженням варіює, але патерн працює.)

Завдання 12: Імпорт коли задіяні розділи (плутанина диск vs розділ)

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE /dev/sdb
NAME   SIZE TYPE FSTYPE
sdb    1.8T disk
sdb1  1.8T part zfs_member

cr0x@server:~$ sudo zpool import -d /dev/disk/by-id tank

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

Завдання 13: Імпорт пулу з образів файлів (ліаб/слідство)

cr0x@server:~$ sudo mkdir -p /srv/zfs-images
cr0x@server:~$ sudo losetup -fP /srv/zfs-images/disk0.img
cr0x@server:~$ sudo losetup -fP /srv/zfs-images/disk1.img
cr0x@server:~$ losetup -a | grep zfs-images
/dev/loop0: [2065]:12345 (/srv/zfs-images/disk0.img)
/dev/loop1: [2065]:12346 (/srv/zfs-images/disk1.img)

cr0x@server:~$ sudo zpool import -d /dev/ tanklab
cannot import 'tanklab': no such pool available

cr0x@server:~$ sudo zpool import -d /dev/loop tanklab

Інтерпретація: loop-пристрої все ще є пристроями. Скануйте там, де вони живуть. Це показує, чому -d концептуально — «де шукати», а не «який тип диска».

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

cr0x@server:~$ time sudo zpool import -d /dev
^C

cr0x@server:~$ time sudo zpool import -d /dev/disk/by-id
real    0m1.214s
user    0m0.084s
sys     0m0.190s

Інтерпретація: сканування /dev — це рух «я панікую». Воно може спрацювати, але за це доводиться платити. Стабільні простори імен швидші і менш схильні до помилок.

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

Міні-історія 1: Інцидент, викликаний неправильним припущенням

Аутейдж не почався з ZFS. Він почався з доброзичливого апаратного оновлення: нові HBA з новішою прошивкою, встановлені під час вікна обслуговування, яке «безумовно мало достатньо часу». Система повернулася, ОС завантажилася, і панель моніторингу стала червоною, бо основний пул ніколи не імпортувався.

Інженер на виклику зайшов і побачив, що диски присутні. Вони більше не були /dev/sd[bcd...]; вони були /dev/sd[fgh...]. Це нормально. Неправильне припущення було в тому, що «нормально» також означало «безпечно». Блок автoімпорту був побудований навколо застарілих очікувань: cachefile, який посилався на старі шляхи, плюс кастомний скрипт, який грепив конкретні вузли /dev/sdX, як ніби був 2009 рік.

Під тиском хтось запустив zpool import -f tank без вказання -d, що імпортувало через перший набір пристроїв, які знайшов ZFS. На жаль, multipath також був увімкнений у новому складанні, і пул потрапив імпортований через сирі шляхи /dev/sdX, хоча команда SAN очікувала /dev/mapper/mpath*. Все виглядало нормально, поки не сталося переключення шляху — тоді латентність I/O різко зросла і почалися помилки контрольних сум, тому що система тепер жонглювала невідповідними шарами пристроїв.

Виправлення було нудне: export пулу, імпорт його використовуючи потрібний простір імен (/dev/mapper в тому середовищі), регенерація cachefile і видалення кастомного скрипту. Постмортем зробив висновок гострішим: якщо ваша автоматизація залежить від /dev/sdX, у вас немає автоматизації; у вас таймер зворотного відліку.

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

Інша команда хотіла швидших завантажень. Їм сказали, що імпорт ZFS може додавати секунди, а секунди нібито неприйнятні, коли ви запускаєте мікросервіси, які стають корисними за хвилини. Тому вони «оптимізували» шлях, вирізавши правила disk-by-id з initramfs і покладаючись на спрощене виявлення пристроїв, припускаючи, що пул завжди з’явиться під передбачуваним шляхом.

Це працювало — поки не перестало. Невелике оновлення ядра змінило таймінг нумерації пристроїв. Члени пулу з’явилися, але не встигли до стадії імпорту. Завантаження продовжилося без пулу, сервіси піднялися і вказували на порожні директорії, а вузол зареєструвався як «здоровий», бо перевірки були на рівні додатків, а не сховища. Ви могли відчути радіус ураження: контейнери охоче писали в кореневу файлову систему, заповнюючи її, а справжній датасет лежав немонтований як мовчазний свідок.

Коли команда намагалася це виправити, вони запустили zpool import -d /dev, бо це «покриває все». На тому хості «все» включало сотні вузлів пристроїв від рантаймів контейнерів і купу застарілих mapper-записів. Сканування імпорту стало повільним, таймаути накопичувалися, а рунбук відновлення перетворився на choose-your-own-adventure.

Зрештою вирішили скасувати оптимізацію: відновити стабільні udev-імена в ранньому середовищі завантаження, імпортувати через /dev/disk/by-id і додати жорстку перевірку, щоб сервіси не стартували, поки ZFS-датасети не змонтовані. Завантаження стали на кілька секунд повільніші; інциденти — на кілька годин коротші. Компроміс став очевидним після того, як хтось через це пережив.

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

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

Під час міграції дата-центру шасі було вимкнено, диски переміщені і знову увімкнено. Як і передбачалося, імена пристроїв змінились. Також передбачувано, ніхто не нервував. Рунбук казав: перевірити диски за WWN, виконати zpool import -d /dev/disk/by-id, імпортувати з -N, перевірити статус, потім змонтувати датасети. Вони так і зробили.

Виникла одна проблема: пул повідомляв «may be in use from other system». Замість негайного примусовго імпорту вони перевірили, чи старий вузол все ще має доступ через залишкову SAN-зону. Мав. Вони видалили зону, дочекалися зникнення шляхів і потім імпортували чисто — без -f.

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

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

Помилка 1: Сканувати /dev і сподіватися на краще

Симптом: zpool import -d /dev повільний, зависає або повертає заплутані дублікати.

Виправлення: скануйте лише стабільні простори імен: /dev/disk/by-id для локальних дисків, /dev/mapper для multipath. Використовуйте кілька -d якщо потрібно.

cr0x@server:~$ sudo zpool import -d /dev/disk/by-id -d /dev/mapper

Помилка 2: Імпорт через сирі шляхи коли ввімкнено multipath

Симптом: пул імпортується, але пізніше показує переривчасті I/O помилки, флапи шляхів або дивні коливання продуктивності під час відмови контролера.

Виправлення: забезпечте, щоб ZFS бачив тільки multipath-пристрої (заблокуйте сирі шляхи у конфігурації multipath за потреби), потім export/import використовуючи /dev/mapper/mpath* (або відповідний by-id для dm).

Помилка 3: Використовувати -f як першу реакцію

Симптом: з’являється повідомлення pool may be in use from other system; оператор примусово імпортує без перевірки виключності.

Виправлення: підтвердіть, що старий хост вимкнений або більше не має доступу до дисків/LUN. Якщо це SAN — перевірте zoning/masking. Якщо це VM — переконайтеся, що ті ж віртуальні диски не приєднані до двох гостьових ОС.

Помилка 4: Плутати «відсутній диск» з «не та директорія для сканування»

Симптом: zpool import показує vdev як UNAVAIL за GUID, але lsblk показує, що диск існує.

Виправлення: скануйте простір імен, який містить фактичний вузол з ZFS-лейблами (розділ vs весь диск). Спробуйте -d /dev/disk/by-id і перевірте через zdb -l.

Помилка 5: Імпортувати й одразу монтувати все

Симптом: після імпорту сервіси стартують занадто рано або датасети монтуються в несподіваних місцях, що призводить до корупції додатків або інцидентів «записали в кореневу FS».

Виправлення: імпортуйте з -N, перевірте, встановіть потрібні властивості, потім змонтуйте навмисно.

cr0x@server:~$ sudo zpool import -N -d /dev/disk/by-id tank

Помилка 6: Вірити, що cachefile — це остаточна істина

Симптом: пул імпортується вручну, але не при завантаженні; або імпортується з дивними шляхами після оновлень/переміщень.

Виправлення: регенеруйте cachefile після імпорту з бажаними шляхами пристроїв; переконайтеся, що init-система використовує правильне місце розташування cachefile для вашого дистрибутива.

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

Покроково: відновлення «пул відсутній після перезавантаження»

1. Підтвердьте видимість апаратного забезпечення: перевірте очікувані WWN/серійні номери.
2. Скануйте стабільний простір імен: використайте zpool import -d /dev/disk/by-id.
3. Якщо multipath: переконайтеся, що імпортуєте через /dev/mapper, а не сирі шляхи.
4. Спочатку імпортуйте безпечно: використовуйте -o readonly=on або -N в залежності від ситуації.
5. Перевірте здоров’я: zpool status, переконайтеся, що немає несподівано відсутніх vdev.
6. Закріпіть шляхи: export і ре-імпорт через by-id/mapper; регенеруйте cachefile.
7. Монтуйте датасети навмисно: потім запускайте сервіси.

Контрольний список: перед переміщенням дисків на новий хост

1. Експортуйте пул коректно (zpool export) і підтвердьте, що його немає (zpool list не має його показувати).
2. Збережіть макет пулу: вивід zpool status -P додайте у ваш тикет.
3. Зафіксуйте WWN: lsblk -o NAME,SERIAL,WWN.
4. На цільовому хості переконайтеся, що ці WWN з’являються перед спробою імпорту.
5. Імпортуйте з явним -d, вказавши обраний простір імен.

Контрольний список: вирішити вашу політику «єдиний правильний шлях»

• Локальний SATA/SAS: віддавайте перевагу /dev/disk/by-id/wwn-* або by-id на основі серійного номера.
• SAN з multipath: віддавайте перевагу /dev/mapper/mpath* або dm-uuid-based by-id, що вказує на dm-пристрої.
• Уникайте: сирих /dev/sdX в будь-якому середовищі, де вікно змін довше ніж перерва на каву.

Часті питання

1) Що саме сканує zpool import -d?

Воно сканує вузли пристроїв (або файли), знайдені в директорії, яку ви вказуєте, шукаючи ZFS-лейбли. Думайте про це як «шлях пошуку потенційних членів vdev». Воно не рекурсивно сканує всю вашу файлову систему — лише записи в цій директорії простору імен.

2) Чи завжди я повинен використовувати /dev/disk/by-id?

Для локальних дисків — так, в більшості продакшн середовищ. Це стабільно при перезавантаженнях і зміні порядку контролерів. Для SAN/multipath зазвичай коректним шаром є /dev/mapper. Важливо — обрати один підхід і дотримуватися його послідовно.

3) Чому zpool import іноді показує GUID замість імен пристроїв?

Коли vdev не можна відкрити, ZFS повертається до GUID vdev з on-disk конфігурації. Це підказка: ZFS знає, чого хоче, але ОС не представляє його за шляхом, який вона спробувала (або взагалі не представляє).

4) Чи безпечно запускати zpool import -f?

Може бути безпечно, якщо ви впевнені, що пул не активний десь ще. Це небезпечно, якщо ті самі диски/LUN доступні з іншого хоста, який також може їх імпортувати. Спочатку підтвердіть виключність доступу.

5) Чому імпорт працює вручну, але не при завантаженні?

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

6) Чи можу я використовувати zpool import -d щоб імпортувати пул, побудований на розділах?

Так, якщо директорія, яку ви скануєте, включає вузли/симлінки на розділи (наприклад, ...-part1 під by-id). Якщо ви скануєте директорію з лише вузлами для цілих дисків, а пул живе на розділах, виявлення може провалитися.

7) У чому різниця між zpool import -d і фіксацією імен пристроїв назавжди?

-d — це підказка для цього спроби виявлення. Постійна стабільність досягається послідовним імпортом з використанням стабільних шляхів (by-id/mapper) і гарантуванням, що процес завантаження і cachefile узгоджені з цим.

8) Чому іноді імпорт показує той самий пул двічі?

Тому що те саме підлягаюче сховище видно через кілька шарів пристроїв (сирий шлях і multipath, або кілька прострaів з симлінками). Це сигнал — зупиніться і оберіть потрібний шар перед імпортом.

9) Як підтвердити, що конкретний диск належить пулу перед імпортом?

Використайте zdb -l проти кандидатного пристрою, щоб прочитати лейбл і підтвердити, що ім’я пулу і GUID відповідають очікуваному.

Висновок

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

Коли шляхи пристроїв змінюються, не метушіться. Підтвердьте, що диски існують, скануйте правильний простір імен, імпортуйте безпечно (-N або лише для читання), а потім закріпіть виправлення, стандартизувавши стабільні шляхи і підтримуючи чесність вашого завантаження/імпорт-пайплайна. Якщо ви так робите, перейменування пристроїв стануть приміткою, а не заголовком.