zfs erro checksum no raidz1 vdev mas não no disco

6

Eu estou fazendo backup de dados armazenados em um zpool que consiste em um único raidz vdev com 2 discos rígidos. Durante esta operação, recebi erros de soma de verificação e agora o status é o seguinte:

  pool: tmp_zpool
 state: ONLINE
status: One or more devices has experienced an error resulting in data
    corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
    entire pool from backup.
   see: http://zfsonlinux.org/msg/ZFS-8000-8A
  scan: none requested
config:

    NAME                  STATE     READ WRITE CKSUM
    tmp_zpool             ONLINE       0     0     2
      raidz1-0            ONLINE       0     0     4
        tmp_cont_0        ONLINE       0     0     0
        tmp_cont_1        ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        /some/file

O que eu acho confuso é que o erro de checksum aparece no nível vdev, mas não no nível do disco. Talvez eu deva observar que um dos discos rígidos é interno e o outro é externo (esta é uma situação temporária). Isso pode ser um problema com os controladores de disco rígido?

Existe algo que eu possa tentar fazer para recuperar o arquivo afetado? Como limpar o erro e importar o vdev degradar com apenas um dos discos? Eu nem tentei ler o arquivo novamente para ver o que acontece. (Não tenho certeza se isso afetaria qualquer coisa.)

Atualização : Eu desisti de esperar por uma explicação do que poderia dar errado se eu limpar os erros e tentar novamente, então eu fui em frente e tentei isso. Primeiro fiz zpool clear , depois zpool status não mostrou erros. Então, tentei ler os arquivos com erros (2 deles no final), mas os respectivos blocos ainda estavam sendo reportados como ruins / ilegíveis. Desta vez, zpool status não exibiu mais erros de soma de verificação. Em seguida, tentei desligar um dos discos do raidz1 vdev e repetir o processo, mas os resultados não mudaram. No total, perdi 2 128K de 1,6T.

Status da resposta : Atualmente, acho que não há uma resposta abrangente para essa pergunta. Se alguém quiser escrever um ou editar um já existente, por favor, responda ao seguinte:

  1. O que poderia ter causado essa situação.
  2. O que poderia ser feito sobre isso?
  3. Como isso poderia ter sido evitado.

Para 1, as teorias e seus problemas parecem ser:

  • Escolha de raidz1 over raidz2 . Problema: é necessário um mínimo de 4 discos para raidz2 . Embora a necessidade de redundância seja clara, não é útil sugerir repetidamente que a cura para a redundância com falha é mais redundância. Seria muito mais útil entender como usar melhor a redundância que você possui.

  • Escolha de raidz1 over mirror . Problema: À primeira vista, a diferença entre estes parece ser eficiência, não redundância. Isso pode estar errado, no entanto. Por que: O zfs salva uma soma de verificação com cada bloco em cada disco, mas nenhum disco relatou erros de soma de verificação individuais. Isso parece sugerir que, para cada bloco defeituoso, os dois discos continham diferentes cargas de bloco, cada um com uma soma de verificação correspondente, e o zfs não sabia dizer qual estava correto. Isso sugere que havia dois cálculos de soma de verificação diferentes e que a carga útil de alguma forma mudou entre eles. Isso pode ser explicado pela corrupção da RAM e talvez (precisar de confirmação) com a opção mirror over raidz1 , somente uma soma de verificação teria sido necessária.

  • Corrupção da RAM durante a escrita, não leitura. Como explicado acima, isso parece plausível. Problema: por que isso não foi detectado como um erro no momento da gravação? Pode ser que o zfs não verifique o que escreve? Ou melhor, que as cargas de bloco escritas nos discos diferentes são as mesmas?

Para 2:

  • Como os discos não têm erros de soma de verificação individuais, existe alguma maneira de baixo nível no zfs para obter acesso às duas cópias diferentes de tais blocos defeituosos?

Para 3:

  • Está claro que mirror over raidz1 teria evitado essa situação?

  • Eu assumo que uma limpeza deste zpool detectou o problema. No meu caso, eu estava movendo alguns dados, e eu destruí os dados de origem antes de realmente ler este zpool, pensando que eu tenho uma redundância de 2 discos. A moral aqui seria esfregar um zool antes de confiar em seu conteúdo? Certamente esfregar é útil, mas é necessário? Por exemplo, seria necessário um scrub com mirror em vez de raidz1 ?

por Matei David 07.08.2015 / 21:22

2 respostas

3

Este é o problema com o raidz1 (e também o RAID5). Se os dados no disco mudarem, mas não ocorrer nenhuma falha na unidade, para permitir que o ZFS ou o controlador RAID saiba qual unidade causou o erro, ele não poderá saber qual unidade está correta. Com o raidz2 (e superior) ou o RAID6, você obtém um quorum de unidades que podem decidir qual unidade ignorar para a reconstrução.

Sua única solução aqui é sobrescrever o arquivo, restaurando uma cópia de backup ou escrevendo /dev/null no arquivo.

    
por 07.08.2015 / 22:51
0

Estou com um problema semelhante. Não tenho certeza se é útil, mas encontrei este post relevante sobre erros de soma de verificação no nível do vdev de um desenvolvedor do FreeBSD.

link

The checksum errors will appear on the raidz vdev instead of a leaf if vdev_raidz.c can't determine which leaf vdev was responsible. This could happen if two or more leaf vdevs return bad data for the same block, which would also lead to unrecoverable data errors. I see that you have some unrecoverable data errors, so maybe that's what happened to you.

Subtle design bugs in ZFS can also lead to vdev_raidz.c being unable to determine which child was responsible for a checksum error. However, I've only seen that happen when a raidz vdev has a mirror child. That can only happen if the child is a spare or replacing vdev. Did you activate any spares, or did you manually replace a vdev?

Eu mesmo estou pensando em excluir meu arquivo zpool.cache e importar meu pool para gerar novamente o arquivo zpool.cache .

    
por 02.09.2016 / 03:16