Змушує zpool використовувати / dev / disk / by-id в Ubuntu Xenial


16

Я намагаюся поставити пакетну OpenZFS на Ubuntu 16.04 Xenial.

Під час створення пулів я завжди посилаю накопичувачі за їхніми серіалами в /dev/disk/by-id/(або /dev/disk/gptна FreeBSD) для стійкості. Приводи не завжди в одному порядку, /devколи машина перезавантажується, і якщо у вас є інші накопичувачі машини, пул може не встановитись належним чином.

Наприклад, працюючи zpool statusна полі 14.04, я отримую це:

NAME                                  STATE     READ WRITE CKSUM
tank                                  ONLINE       0     0     0
  raidz1-0                            ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HUA722020ALA330_[..]  ONLINE       0     0     0

Але коли я створюю новий пул 16.04 із цим (скорочено):

zpool create pool raidz \
    /dev/disk/by-id/ata-Hitachi_HDS723030ALA640_[..] \
    /dev/disk/by-id/ata-Hitachi_HDS723030ALA640_[..] \
    /dev/disk/by-id/ata-Hitachi_HDS723030ALA640_[..] \
    /dev/disk/by-id/ata-Hitachi_HDS723030ALA640_[..]

Я розумію це zpool status:

NAME        STATE     READ WRITE CKSUM
tank        ONLINE       0     0     0
  raidz1-0  ONLINE       0     0     0
    sdf     ONLINE       0     0     0
    sde     ONLINE       0     0     0
    sdd     ONLINE       0     0     0
    sda     ONLINE       0     0     0

Схоже, zpool слідував за посиланнями, а не посилаючись на них.

Чи є спосіб змусити zpool 16.04 дотримуватися моїх дискових посилань під час створення пулу? Або ж мій побоювання з приводу того, що тут робиться?

Оновлення: вирішення

Я знайшов потік для zfsonlinux на Github, який запропонував вирішити. Створіть спочатку свій zpool за допомогою /dev/sdXпристроїв, а потім зробіть це:

$ sudo zpool export tank
$ sudo zpool import -d /dev/disk/by-id -aN

Я все-таки вважаю за краще мати можливість це робити з початковим, zpool createхоча це можливо.


Не має значення, як ви їх створюєте. Якщо він повертається до / dev / sd? назви пристроїв, zfs exportі zfs import -dбуде працювати все одно. BTW, якщо вам дійсно не потрібен кожен байт простору, використовуйте дві дзеркальні пари, а не raidz. Продуктивність raidz краща, ніж raid-5, але все ж набагато гірша за дзеркальні пари raid-10 або zfs. також простіше розширити пул, що складається з дзеркальних пар, просто додайте два диски одночасно ... з raidz, ви повинні замінити кожен з накопичувачів на більші диски, і лише коли ви замінили їх усі, ваш басейн має більше місця.
cas

У мене ще є кілька рейдів-басейнів, і шкодую, що їх зробив. Коли я можу дозволити собі придбати замінні диски, я буду створювати нові пули з дзеркальними парами і використовувати zfs sendдля копіювання своїх даних у нові пули. Насправді, для моєї скриньки mythtv нормально працює raid-z, де продуктивність не є критичною, якщо я не виконую одразу 6 чи 8 завдань перекодування. Перехід на дзеркальні пари було б дуже помітно в басейні, де /home живе мій каталог.
cas

2
Дзеркальне відображення ZIL полягає в тому, що ви можете уникнути використання звичайних дешевих SSD, а не дорогих з великими конденсаторами для захисту від втрати електроенергії. IMO, дзеркальне відображення ZIL не є обов'язковим, незалежно від того, який тип SSD-дисків у вас є - якщо ваш ZIL вмирає, ви втрачаєте всі записані в нього дані і потенційно пошкоджуєте ваш пул. Що стосується L2ARC, я спеціально сказав НЕ дзеркально їх ... дзеркальне відображення кешу L2ARC - це марна трата часу, грошей та хорошого простору SSD (і нічого не зробить, щоб не втратити кеш - звідки ви взяли цю думку?)
cas

1
:) До речі, мій мозок не працював правильно, коли я пояснив причину дзеркального відображення ZIL. Це не захищати від втрати потужності, це повна дурниця, і я ніколи не повинен був цього говорити. Це захищати від відмови накопичувача ZIL. тобто дзеркало рейду-1 для ЗІЛ. Два SSD-накопичувача за розумною ціною в цілому краще, ніж один надзвичайно дорогий (якщо тільки більш дорогий SSD не має набагато швидший інтерфейс, як PCI-e проти SATA). а ДБЖ важливо ... дешевий захист від втрати електроенергії.
cas

1
@cas Mirrored ZIL захищає від несправності пристрою SLOG одночасно з несподіваним відключенням. У звичайних операціях ZIL працює лише для запису, а запис у постійне зберігання відбувається з оперативної пам'яті (ARC). Якщо система несподівано завершиться, журнал намірів (ZIL, SLOG) використовується для завершення записів, які були перервані. Тільки якщо несподіване вимкнення збігається з виходом з ладу пристрою SLOG, вам потрібен редуктор SLOG для відновлення перерваного запису. Для більшості несерверних (і багатьох серверних) навантажень SLOG є надмірним, оскільки ZIL дійсно грає лише з синхронними записами.
CVn

Відповіді:


1

Час від часу zpool import -d /dev/disk/by-idне працює.

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

zpool import -d /dev/disk/by-id POOL
zpool export POOL
zpool import POOL

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

Можливо, це було просто через помилку ZFS протягом декількох тижнів чи місячних періодів (рік-два тому), і це вже не потрібно. Я припускаю, що я повинен був подати звіт про помилку, але обходитись було неважливо.


1

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

$> sudo zpool export POOL
$> sudo zpool import -d /dev/disk/by-id POOL
$> sudo zpool import -c /etc/zfs/zpool.cache
$> sudo zpool status POOL
NAME                                  STATE     READ WRITE CKSUM
POOL                                  ONLINE       0     0     0
  raidz1-0                            ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HDS722020ALA330_[..]  ONLINE       0     0     0
    ata-Hitachi_HUA722020ALA330_[..]  ONLINE       0     0     0
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.