Início / server / Perguntas / 1089013
Accepted
Greg Nelson
Asked: 2022-01-05 18:49:53 +0800 CST

Usuário iniciante do btrfs: falhas de soma de verificação e erros de entrada/saída em abundância

  • 772

Um colega de casa me sugeriu que eu deveria usar btrfs em vez do que tenho feito até agora, que é usar mdadm com unidades clonadas e adicionar uma unidade extra à matriz para "clonar" um backup. O sistema possui três unidades, todas de modelos fisicamente diferentes:

  • /dev/sda: TOSHIBA HDWQ140
  • /dev/sdb: HGST HUS724040AL
  • /dev/sdc: WDC WDS250G2B0B

Bem, eu instalei o btrfs, mas agora ele está em execução há quase um ano e descubro que deveria ter um trabalho cron semanal em execução para "limpá-lo". Comecei a tentar configurar um script para isso, embora pareça um sistema estupidamente DIY que exige que você pesquise um script no Google (o principal hit que encontrei foi de algo como 2014) e o instale para manter seu sistema de arquivos em execução.

Enquanto eu estava fazendo todas essas coisas administrativas, encontrei alguns arquivos que precisavam ser movidos ... Vou pular os detalhes sangrentos, mas mover os arquivos de um sistema de arquivos btrfs para outro e de volta gerou todos os tipos de "entrada/saída errors" (nunca vi isso com ext4), e até mesmo esta jóia:

Jan  4 21:19:19 host kernel: [9771285.171522] attempt to access beyond end of device
Jan  4 21:19:19 host kernel: [9771285.171522] sda1: rw=1, want=70370535518208, limit=7814035087
Jan  4 21:19:19 host kernel: [9771285.171529] BTRFS error (device sda1): bdev /dev/sda1 errs: wr 1, rd 0, flush 0, corrupt 5, gen 0

Estou assumindo que estes estão relacionados. Mas aqui está a coisa realmente estúpida. Estou recebendo erros de soma de verificação não apenas em arquivos que estão parados há um ano, mas em arquivos que literalmente copiei apenas algumas horas atrás para uma unidade física diferente . Além disso, quase todos eles estão em arquivos enormes (coisas como imagens ISO de DVD) se isso for alguma indicação de alguma coisa?

Então, sim, eu poderia estar vendo uma falha de unidade tripla simultânea ou o btrfs apenas corrompe meus arquivos para mim?

Além disso, cada postagem do pessoal experiente do btrfs inclui um pequeno e fofo "bem, você deve restaurar isso a partir de backups ... você tem backups, não é". Então me digam, o que exatamente você usa para fazer backup de um disco rígido de 4 TB? Porque eu não posso exatamente, você sabe, gravá-lo em um DVD, e se os discos rígidos não são tão confiáveis, então para que servem os backups em discos rígidos?

Perguntas tão sérias:

  1. Esses erros de soma de verificação são realmente normais e esperados?
  2. Por que estou vendo eles em arquivos que só foram copiados hoje?
  3. Esfoliantes regulares serão suficientes para proteger contra isso?
  4. Devo comprar novos discos rígidos e jogar fora todos os que estão atualmente na máquina porque eles realmente estão falhando?
  5. Como você recomenda fazer backup de unidades de dados de vários terabytes?

Atualização 2022-01-07: eu corri smartctlem todas as unidades e elas não estão relatando nenhum problema. Raw UDMA_CRC_Error_Count é 0 para todas as unidades. Tentei restaurar arquivos corrompidos... o arquivo tar copiado para a máquina falhou após alguns arquivos com um erro de E/S. Realmente não faço ideia do que está acontecendo aqui:

  • Se as unidades ou os cabos estivessem ruins, isso apareceria no SMART, certo?
  • Se a CPU ou a memória estivessem ruins, o sistema não estaria funcionando perfeitamente? (Atualmente até 115 dias sem problemas óbvios)?
  • Se isso fosse um bug generalizado com o btrfs, não estaria em toda a internet?

Então, onde poderia estar realmente o problema?

backup ubuntu-20.04 btrfs checksum

1 respostas

  1. Best Answer

    Estou respondendo minha própria pergunta porque acho que isso é interessante e pode ser útil para alguém.

    TL;DR A causa raiz dos problemas relatados parece ter falhado na DRAM, não nos discos rígidos.

    1. Não, essas somas de verificação não são normais e esperadas. Outro sistema rodando a mesma versão do btrfs estava funcionando perfeitamente bem. Eles indicam algo errado, mas não necessariamente com os discos. Veja o próximo item.
    2. Eles estão aparecendo em dados recém-copiados, porque há uma grande falha da DRAM no sistema, confirmada pelo X86MemTest. Apenas um dos dois sticks estava ruim, e aconteceu que era o stick mapeado para a memória mais alta, então somente quando a memória baixa era toda usada (raramente, mas com mais frequência para arquivos maiores) as falhas morderam. É por isso que eles não afetaram o kernel.
    3. Os scrubs regulares podem ter detectado o problema mais cedo. Os scrubs regulares não ajudam quando você tem uma unidade (por exemplo, /dev/sdc) que não faz parte de um espelho, porque embora possa ver um erro de soma de verificação, não há esperança de corrigi-lo - isso é fundamentalmente um limitação do btrfs, onde eles poderiam ter eleito uma função de soma de verificação com uma distância de hamming maior, mas em vez disso elegeu uma que fosse mais rápida de calcular (acredito).
    4. Comprei novos discos rígidos, que podem servir como backups, mas vários testes SMART e outros esforços sugerem que os discos atuais provavelmente estão OK. O "todos os discos falhando ao mesmo tempo" é provavelmente uma boa pista de que o problema não é os discos rígidos.
    5. Como observado, os discos grandes se tornaram baratos... e como os discos em si não parecem ser o ponto de falha, a ideia de usar discos rígidos para backup parece ter validade contínua.
    • 0

relate perguntas