Zmuszanie zpool do używania / dev / disk / by-id w Ubuntu Xenial

Próbuję w pakiecie OpenZFS na Ubuntu 16.04 Xenial.

Podczas tworzenia pul zawsze odnoszę się do dysków według ich numerów seryjnych w /dev/disk/by-id/(lub /dev/disk/gptna FreeBSD) w celu uzyskania odporności. Dyski nie zawsze są w tej samej kolejności, /devgdy komputer uruchamia się ponownie, a jeśli masz inne dyski w maszynie, pula może nie zostać poprawnie zamontowana.

Na przykład działając zpool statusna polu 14.04 otrzymuję to:

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

Ale kiedy utworzę nową pulę 16.04 z tym (w skrócie):

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_[..]

Dostaję to z 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

Wygląda na to, że zpool podążył za dowiązaniami symbolicznymi, zamiast się do nich odwoływać.

Czy istnieje sposób, aby zmusić zpool w dniu 16.04 do respektowania odniesień do mojego dysku podczas tworzenia puli? Albo alternatywnie, czy moje obawy dotyczące tego, co tu robią, są niewłaściwe?

Aktualizacja: obejście

I znalazłem wątku na zfsonlinux na Github że sugerowane obejście. /dev/sdXNajpierw utwórz swój zpool z urządzeniami, a następnie wykonaj następujące czynności:

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

Nadal wolałbym móc to zrobić z początkowym, zpool createjeśli to możliwe.

ubuntu zfs

— Ruben Schade
źródło

Nie ma znaczenia, jak je utworzysz. Jeśli powróci do / dev / sd? nazwy urządzeń, zfs exporti zfs import -dbędą działać mimo to. BTW, chyba że naprawdę potrzebujesz każdego bajtu miejsca, użyj dwóch par lustrzanych zamiast raidz. Wydajność raidz jest lepsza niż raid-5, ale wciąż znacznie gorsza niż raid-10 lub pary lustrzane zfs. łatwiej jest również rozszerzyć pulę złożoną z par lustrzanych, wystarczy dodać dwa dyski na raz ... w programie raidz każdy z dysków należy wymienić na większy, a dopiero po ich zastąpieniu wszystkie basen ma więcej dostępnego miejsca.

— cas

Nadal mam pule raid-z i żałuję, że je stworzyłem. Kiedy stać mnie na zakup dysków zastępczych, utworzę nowe pule z parami lustrzanymi i użyję zfs senddo skopiowania moich danych do nowych pul. W rzeczywistości raid-z jest OK dla mojego mythtv box, w którym wydajność nie jest krytyczna, chyba że uruchamiam 6 lub 8 zadań transkodowania jednocześnie. Zmiana na pary lustrzane byłaby bardzo zauważalna na puli, w której /home mieszka mój katalog.

— cas

Odbicie lustrzane ZIL pozwala uniknąć zwykłych tanich dysków SSD zamiast drogich z dużymi kondensatorami, aby uchronić się przed utratą zasilania. IMO, dublowanie ZIL nie jest opcjonalne, bez względu na to, jaki rodzaj dysków SSD masz - jeśli Twój ZIL umrze, stracisz wszystkie dane, które mają być jeszcze zapisane, i potencjalnie uszkodzisz pulę. Jeśli chodzi o L2ARC, powiedziałem, że NIE powielanie ich ... kopiowanie pamięci podręcznej L2ARC to strata czasu, pieniędzy i dobrego miejsca na dysku SSD (i nie zrobiłaby nic, aby zapobiec utracie pamięci podręcznej - skąd masz ten pomysł?)

— cas

:) BTW, mój mózg nie działał poprawnie, kiedy wyjaśniłem powód lustrzanego ZIL. To nie jest ochrona przed utratą zasilania, to kompletny nonsens i nigdy nie powinienem był tego mówić. Ma chronić przed awarią napędu ZIL. tj. lustro raid-1 dla ZIL. Dwa niedrogie dyski SSD są ogólnie lepsze niż jeden wyjątkowo drogi (chyba że droższy dysk SSD ma znacznie szybszy interfejs, taki jak PCI-e vs SATA). a UPS jest niezbędny ... tania ochrona przed utratą zasilania.

— cas

@cas Mirrored ZIL chroni przed awarią urządzenia SLOG jednocześnie z nieoczekiwanym zamknięciem. W normalnych operacjach ZIL jest tylko do zapisu, a zapisywanie w pamięci trwałej odbywa się z pamięci RAM (ARC). Jeśli system nieoczekiwanie zostanie zamknięty, dziennik intencji (ZIL, SLOG) służy do zakończenia zapisów, które zostały przerwane. Tylko wtedy, gdy nieoczekiwane zamknięcie zbiega się z awarią urządzenia SLOG, potrzebujesz redogancyjnego SLOG, aby odzyskać przerwane zapisy. W przypadku większości obciążeń innych niż serwerowe (i wiele serwerów) SLOG jest przesadą, ponieważ ZIL naprawdę wchodzi w grę tylko z zapisami synchronicznymi.

— CVn

Raz na jakiś czas zpool import -d /dev/disk/by-idnie działa.

Zauważyłem to w więcej niż jednym środowisku. Mam skrypt importu, który oprócz wykonywania jakiejś magicznej logiki i pokazywania fizycznie podłączonych urządzeń ZFS, robi to w zasadzie:

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

Drugi raz, nawet bez -dprzełącznika, importuje według identyfikatora urządzenia, nawet jeśli nie za pierwszym razem z wyraźnym poleceniem.

Możliwe, że było to spowodowane błędem ZFS w ciągu kilku tygodni lub miesięcy (rok lub dwa lata temu) i nie jest to już konieczne. Przypuszczam, że powinienem był zgłosić błąd, ale obejście tego było trywialne.

— Jim
źródło

Wiem, że ten wątek jest trochę przestarzały, ale jest odpowiedź. Po zaimportowaniu musisz zaktualizować plik pamięci podręcznej. Ten przykład pokazuje domyślną lokalizację pliku pamięci podręcznej.

$> 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

— Steve O
źródło