☰

Dois pools ZFS emaranhados?

tag-icon • tag-icon ubuntu zfs
Dois pools ZFS emaranhados?

Estou tentando limpar uma bagunça em um sistema de servidor Ubuntu 12.04 LTS usando ZFS. Aqui está o que o status do zpool mostra:

  pool: TB2
 state: UNAVAIL
status: One or more devices could not be used because the label is missing
        or invalid.  There are insufficient replicas for the pool to continue
        functioning.
action: Destroy and re-create the pool from
        a backup source.
   see: http://zfsonlinux.org/msg/ZFS-8000-5E
  scan: none requested
config:

    NAME        STATE     READ WRITE CKSUM
    TB2         UNAVAIL      0     0     0  insufficient replicas
      sdd       ONLINE       0     0     0
      sde       ONLINE       0     0     0
      sdf       ONLINE       0     0     0
      sdg       ONLINE       0     0     0
      sdh       ONLINE       0     0     0
      sdi       ONLINE       0     0     0
      sdj       ONLINE       0     0     0
      sds       ONLINE       0     0     0
      sdt       UNAVAIL      0     0     0

  pool: TB4
 state: DEGRADED
status: One or more devices could not be used because the label is missing or
        invalid.  Sufficient replicas exist for the pool to continue
        functioning in a degraded state.
action: Replace the device using 'zpool replace'.
   see: http://zfsonlinux.org/msg/ZFS-8000-4J
  scan: resilvered 2.52T in 16h41m with 0 errors on Tue Feb  6 09:27:46 2018
config:

    NAME                                              STATE     READ WRITE CKSUM
    TB4                                               DEGRADED     0     0     0
      raidz2-0                                        DEGRADED     0     0     0
        ata-Hitachi_HDS724040ALE640_PK1331PAG9MBVS    ONLINE       0     0     0
        ata-Hitachi_HDS724040ALE640_PK2311PAG8G71M    ONLINE       0     0     0
        ata-Hitachi_HDS724040ALE640_PK1331PAGH0LHV    ONLINE       0     0     0
        ata-Hitachi_HDS724040ALE640_PK2331PAG8MV3T    ONLINE       0     0     0
        spare-4                                       DEGRADED     0     0     0
          ata-Hitachi_HDS724040ALE640_PK2311PAG614MM  UNAVAIL      0     0     0
          ata-Hitachi_HDS724040ALE640_PK1331PAGH0EAV  ONLINE       0     0     0
        ata-Hitachi_HDS724040ALE640_PK2331PAGH2XRW    ONLINE       0     0     0
        ata-Hitachi_HDS724040ALE640_PK1331PAG7TGDS    ONLINE       0     0     0
        ata-Hitachi_HDS724040ALE640_PK1331PAGG3K0V    ONLINE       0     0     0
        ata-Hitachi_HDS724040ALE640_PK2311PAG59PYM    ONLINE       0     0     0
    spares
      ata-Hitachi_HDS724040ALE640_PK1331PAGH0EAV      INUSE     currently in use

errors: No known data errors

Quero fazer duas coisas: 1. Substituir a unidade com defeito no pool TB4. Isso eu sei fazer. 2. Destrua e recrie completamente o pool TB2.

Normalmente, eu apenas faria um zpool, destruiria o TB2 e começaria de novo. No entanto, o administrador anterior usou nomes sd* para TB2 e IDs de disco para TB4. Ao examinar /dev/disk/by-id, descobri que duas das unidades TB4 (...71M e ...EAV) estão vinculadas simbolicamente a /dev/sdj e /dev/sds respectivamente. Mas esses sdj e sds estão listados como parte do pool TB2. Receio que fazer um zpool destroy TB2 corrompa as unidades no pool TB4, já que os documentos dizem que destroy grava nos discos membros. Existe alguma maneira de fazer com que o ZFS simplesmente esqueça o TB2 sem realmente escrever?

Perguntei ao administrador anterior por que ele usou dois métodos diferentes (/dev/sd* e by-id). Ele disse que a atribuição de letras de unidade a discos rígidos específicos não parecia ser repetível de inicialização a inicialização, então, quando criou o TB4, ele usou by-id. Acho que esse emaranhado de TB2 e TB4 é resultado disso.

Meu pensamento atual é fazer isso:

  1. desligue a máquina
  2. puxe todas as unidades.
  3. Reinício.
  4. zpool destruir -f TB2
  5. desligue e reinstale as unidades TB4
  6. reformate as unidades TB2 em outra máquina
  7. Reinstale as unidades TB2 e crie um novo pool usando IDs de disco (não sd*)

Isso parece razoável? Existe uma maneira mais fácil?

Obrigado a quem puder me ajudar a sair dessa bagunça.

Michael

Responder1

Seu método proposto parece funcionar. No entanto, também é desnecessariamente complexo. Em vez disso, eu sugeriria:

  1. zpool export TB2. Isso desmontará todos os recursos associados ao pool e seu sistema não tentará remontá-los (e possivelmente gravá-los) a menos que você execute zpool importprimeiro.
  2. Reparar TB4. (Ou você pode fazer isso mais tarde.)
  3. zpool create <new pool> ...(referenciando os discos por id para evitar sobreposição novamente). Talvez seja necessário forçar a criação, pois pode perceber que esses discos estavam em uso por um pool não importado.

Se você quiser fazer um teste do procedimento, acho que você pode criar alguns volumes no TB4 ( zfs create -V 5gb TB4/volume1) e fazer dois “pools aninhados” daqueles ( zpool create testpool1 ...) com um volume sobreposto. Todo o resto deve funcionar da mesma forma que acima.

informação relacionada