Ubuntu actualizado, todas las unidades en un zpool marcadas como no disponibles

Acabo de actualizar Ubuntu 14.04 y tenía dos grupos de ZFS en el servidor. Hubo algún problema menor conmigo peleando con el controlador ZFS y la versión del kernel, pero eso ha funcionado ahora. Un grupo entró en línea y se montó bien. El otro no. La principal diferencia entre la herramienta es que uno era solo un grupo de discos (almacenamiento de video / música), y el otro era un conjunto raidz (documentos, etc.)

Ya he intentado exportar y volver a importar el grupo, pero fue en vano; intentar importar me da esto:

root@kyou:/home/matt# zpool import -fFX -d /dev/disk/by-id/
   pool: storage
     id: 15855792916570596778
  state: UNAVAIL
 status: One or more devices contains corrupted data.
 action: The pool cannot be imported due to damaged devices or data.
   see: http://zfsonlinux.org/msg/ZFS-8000-5E
 config:

        storage                                      UNAVAIL  insufficient replicas
          raidz1-0                                   UNAVAIL  insufficient replicas
            ata-SAMSUNG_HD103SJ_S246J90B134910       UNAVAIL
            ata-WDC_WD10EARS-00Y5B1_WD-WMAV51422523  UNAVAIL
            ata-WDC_WD10EARS-00Y5B1_WD-WMAV51535969  UNAVAIL

Los enlaces simbólicos para aquellos en /dev/disk/by-idtambién existen:

root@kyou:/home/matt# ls -l /dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90B134910* /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WMAV51*
lrwxrwxrwx 1 root root  9 May 27 19:31 /dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90B134910 -> ../../sdb
lrwxrwxrwx 1 root root 10 May 27 19:15 /dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90B134910-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 May 27 19:15 /dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90B134910-part9 -> ../../sdb9
lrwxrwxrwx 1 root root  9 May 27 19:15 /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WMAV51422523 -> ../../sdd
lrwxrwxrwx 1 root root 10 May 27 19:15 /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WMAV51422523-part1 -> ../../sdd1
lrwxrwxrwx 1 root root 10 May 27 19:15 /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WMAV51422523-part9 -> ../../sdd9
lrwxrwxrwx 1 root root  9 May 27 19:15 /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WMAV51535969 -> ../../sde
lrwxrwxrwx 1 root root 10 May 27 19:15 /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WMAV51535969-part1 -> ../../sde1
lrwxrwxrwx 1 root root 10 May 27 19:15 /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WMAV51535969-part9 -> ../../sde9

Al inspeccionar los diversos /dev/sd*dispositivos enumerados, parecen ser los correctos (las 3 unidades de 1TB que estaban en una matriz raidz).

He corrido zdb -len cada unidad, volcado en un archivo y ejecutando un diff. La única diferencia en el 3 son los campos guid (que supongo que se espera). Las 3 etiquetas en cada una son básicamente idénticas y son las siguientes:

version: 5000
name: 'storage'
state: 0
txg: 4
pool_guid: 15855792916570596778
hostname: 'kyou'
top_guid: 1683909657511667860
guid: 8815283814047599968
vdev_children: 1
vdev_tree:
    type: 'raidz'
    id: 0
    guid: 1683909657511667860
    nparity: 1
    metaslab_array: 33
    metaslab_shift: 34
    ashift: 9
    asize: 3000569954304
    is_log: 0
    create_txg: 4
    children[0]:
        type: 'disk'
        id: 0
        guid: 8815283814047599968
        path: '/dev/disk/by-id/ata-SAMSUNG_HD103SJ_S246J90B134910-part1'
        whole_disk: 1
        create_txg: 4
    children[1]:
        type: 'disk'
        id: 1
        guid: 18036424618735999728
        path: '/dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WMAV51422523-part1'
        whole_disk: 1
        create_txg: 4
    children[2]:
        type: 'disk'
        id: 2
        guid: 10307555127976192266
        path: '/dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WMAV51535969-part1'
        whole_disk: 1
        create_txg: 4
features_for_read:

Estúpidamente, no tengo una copia de seguridad reciente de este grupo. Sin embargo, el grupo estaba bien antes de reiniciar, y Linux ve bien los discos (tengo smartctl ejecutándose ahora para verificar)

Entonces, en resumen:

• Actualicé Ubuntu y perdí el acceso a uno de mis dos zpools.
• La diferencia entre las piscinas es que la que surgió fue JBOD, la otra fue asustada.
• Todas las unidades en el zpool desmontable están marcadas UNAVAIL, sin notas de datos corruptos.
• Los grupos se crearon con discos a los que se hace referencia /dev/disk/by-id/.
• Los enlaces simbólicos de /dev/disk/by-idlos distintos /dev/sddispositivos parecen ser correctos
• zdb Puede leer las etiquetas de las unidades.
• El grupo ya se ha intentado exportar / importar, y no puede volver a importar.

¿Hay algún tipo de magia negra que pueda invocar a través de zpool / zfs para devolver estos discos a una matriz razonable? ¿Puedo correr zpool create zraid ...sin perder mis datos? ¿Mis datos ya no están?

Después de mucho más buscar en Google este mensaje de error específico que estaba recibiendo:

root@kyou:/home/matt# zpool import -f storage
cannot import 'storage': one or more devices are already in use

(Incluido aquí para la posteridad y los índices de búsqueda) Encontré esto:

https://groups.google.com/a/zfsonlinux.org/forum/#!topic/zfs-discuss/VVEwd1VFDmc

Estaba usando las mismas particiones y las agregaba a mdraid durante cualquier arranque antes de cargar ZFS.

Recordé haber visto algunas líneas mdadm dmesgy, por supuesto:

root@kyou:/home/matt# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md126 : active raid5 sdd[2] sdb[0] sde[1]
      1953524992 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

Estas unidades eran, una vez, parte de una matriz de software raid5. Por alguna razón, durante la actualización, decidió volver a escanear las unidades, y descubrió que las unidades alguna vez formaron parte de una matriz de md, y decidió recrearlo. Esto se verificó con:

root@kyou:/storage# mdadm --examine /dev/sd[a-z]

Esas tres unidades mostraron un montón de información. Por ahora, deteniendo la matriz:

root@kyou:/home/matt# mdadm --stop /dev/md126
mdadm: stopped /dev/md126

Y volver a ejecutar la importación:

root@kyou:/home/matt# zpool import -f storage

ha vuelto a poner en línea la matriz.

Ahora hago una instantánea de ese grupo para hacer una copia de seguridad y corro mdadm --zero-superblocksobre ellos.

Ubuntu parece tener algunos problemas molestos de udev que no vemos en el lado de Red Hat / CentOS. Recomendaría usar los nombres de dispositivos basados ​​en WWN si puede, ya que parecen menos susceptibles a esto.

Has visto: ¿Por qué el reinicio hizo que un lado de mi espejo ZFS se convirtiera en UNAVAIL?

Me encontré con casi este problema exacto al intentar actualizar a los núcleos de la serie 3.13 en Debian Wheezy. Tienes razón en tu comentario; Es un error udev. Desafortunadamente, nunca lo resolví, pero vale la pena explorar otros núcleos, especialmente la serie 3.11, por compatibilidad con la versión 0.6.2 de ZOL. Simplemente use el kernel anterior hasta que salga 0.6.3.