Forcer zpool à utiliser / dev / disk / by-id dans Ubuntu Xenial

J'essaie OpenZFS fourni sur Ubuntu 16.04 Xenial.

Lors de la création de pools, je référence toujours les disques par leurs séries dans /dev/disk/by-id/(ou /dev/disk/gptsur FreeBSD) pour la résilience. Les lecteurs ne sont pas toujours dans le même ordre /devlors du redémarrage d'une machine, et si vous avez d'autres lecteurs dans la machine, le pool peut ne pas se monter correctement.

Par exemple, en cours zpool statusd' exécution sur une boîte 14.04, j'obtiens ceci:

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

Mais quand je crée un nouveau pool le 16.04 avec ceci (en abrégé):

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

Je reçois ceci avec 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

Il semble que zpool ait suivi les liens symboliques, plutôt que de les référencer.

Existe-t-il un moyen de forcer zpool sur 16.04 à respecter mes références de lecteur lors de la création d'un pool? Ou bien, mes réticences à propos de ce qu'il fait ici sont-elles déplacées?

Mise à jour: solution de contournement

J'ai trouvé un fil pour zfsonlinux sur Github qui a suggéré une solution de contournement. Créez d'abord votre zpool avec des /dev/sdXappareils, puis procédez comme suit:

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

Je préférerais quand même pouvoir le faire avec l'initiale zpool createsi possible.

ubuntu zfs

— Ruben Schade
source

Peu importe comment vous les créez. S'il revient à / dev / sd? les noms des appareils, zfs exportet zfs import -dfonctionneront quand même. BTW, sauf si vous avez vraiment besoin de chaque octet d'espace, utilisez deux paires en miroir plutôt que raidz. Les performances de raidz sont meilleures que raid-5 mais toujours bien pires que les paires miroir raid-10 ou zfs. il est également plus facile d'étendre un pool composé de paires en miroir, ajoutez simplement deux disques à la fois ... avec raidz, vous devez remplacer chacun des disques par des disques plus grands, et ce n'est que lorsque vous les aurez tous remplacés que votre la piscine a plus d'espace disponible.

— cas

J'ai encore quelques pools de raid-z, et je regrette de les avoir créés. Lorsque je pourrai acheter des disques de remplacement, je créerai de nouveaux pools avec des paires en miroir et les utiliserai zfs sendpour copier mes données dans les nouveaux pools. En fait, raid-z est OK pour ma boîte mythtv où les performances ne sont pas critiques à moins que j'exécute 6 ou 8 travaux de transcodage à la fois. Le passage à des paires en miroir serait très visible sur le pool où réside mon /home répertoire.

— cas

La mise en miroir de ZIL vous permet de vous en sortir en utilisant des SSD ordinaires bon marché plutôt que des SSD coûteux avec de grands condensateurs pour vous protéger contre la perte de puissance. IMO, la mise en miroir du ZIL n'est pas facultative, quel que soit le type de SSD que vous avez - si votre ZIL meurt, vous perdez toutes les données encore à écrire et potentiellement corrompez votre pool. En ce qui concerne L2ARC, j'ai dit spécifiquement de ne pas les refléter ... la mise en miroir du cache L2ARC est une perte de temps, d'argent et de bon espace SSD (et ne ferait rien pour éviter de perdre le cache - d'où vous est venue cette idée?)

— cas

:) BTW, mon cerveau ne fonctionnait pas bien quand j'ai expliqué la raison de la mise en miroir de ZIL. Ce n'est pas pour se prémunir contre la perte de puissance, c'est un non-sens complet et je n'aurais jamais dû le dire. C'est pour se prémunir contre une panne du lecteur ZIL. ie miroir raid-1 pour le ZIL. Deux SSD à un prix raisonnable valent généralement mieux qu'un SSD extrêmement cher (sauf si le SSD le plus cher a une interface beaucoup plus rapide, comme PCI-e vs SATA). et un onduleur est essentiel ... une protection bon marché contre les coupures de courant.

— cas

@cas Mirrored ZIL protège contre les pannes de périphérique SLOG en même temps qu'un arrêt inattendu. Dans des opérations normales, le ZIL est en écriture seule et les écritures sur le stockage persistant proviennent de la RAM (ARC). Si le système s'arrête de façon inattendue, le journal d'intention (ZIL, SLOG) est utilisé pour terminer les écritures qui ont été interrompues. Ce n'est que si l'arrêt inattendu coïncide avec la défaillance d'un périphérique SLOG que vous avez besoin d'un SLOG redondant pour récupérer les écritures interrompues. Pour la plupart des charges de travail non-serveur (et de nombreux serveurs), un SLOG est excessif, car le ZIL n'entre vraiment en jeu qu'avec les écritures synchrones.

— un CVn le

De temps en temps, zpool import -d /dev/disk/by-idça ne marche pas.

J'ai remarqué cela sur plus d'un environnement. J'ai un script d'importation qui, au-delà de la logique magique et de l'affichage des périphériques ZFS physiquement connectés, fait également ceci:

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

La deuxième fois, même sans le -dcommutateur, les importations par ID de périphérique, même si ce n'est pas le cas la première fois avec la commande explicite.

Il est possible que cela soit simplement dû à un bogue ZFS pendant quelques semaines ou mois (il y a un an ou deux), et ce n'est plus nécessaire. Je suppose que j'aurais dû déposer un rapport de bogue, mais c'était trivial à contourner.

— Jim
source

Je sais que ce fil est en quelque sorte périmé, mais il y a une réponse. Vous devez mettre à jour votre fichier cache après l'importation. Cet exemple montre l'emplacement par défaut du fichier cache.

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