Estratégias para detectar corrupção em piscinas Greyhole [fechadas]

1

Existem boas estratégias para detectar proativamente a corrupção de dados em um pool da Greyhole?

Suponha que a seguinte cadeia de eventos aconteça.

c:\> copy swiss_bank_account.txt \greyhole\safe_documents

Greyhole does its thing and replaces:
  safe_documents/swiss_bank_account.txt with -> /mnt/pool1/safe_documents/swiss_bank_account.txt
and creates a backup file:
  /mnt/pool2/safe_documents/swiss_bank_account.txt

/mnt/pool2 suffers a random failure, corrupting swiss_bank_account.txt - It goes un-noticed because it's the secondary.
/mnt/pool1 suffers a random failure - Crap... now both my redundant copies are corrupt.

Quais são as boas estratégias para detectar proativamente a corrupção em uma matriz de duplicação no estilo JBOD como Greyhole?

A menos que eu esteja enganado, a replicação de 3 vias não é à prova de erros. No caso de um disco catastroficamente falho, você só poderia detectar, e não resolver discrepâncias entre as duas cópias sobreviventes.

Os sistemas viáveis em que posso pensar são:

  1. Replicação de 3 vias em um sistema de arquivos de soma de verificação, como o btrfs.
  2. Replicação de 3 vias e espero que todas as suas falhas não sejam correlacionadas.
  3. Aplicação chron-job de ferramentas de paridade.
  4. Engatando o Greyhole para executar ferramentas de paridade ao escrever.
  5. Chron-job procura contrato de dados.

Além da opção 1 e 2, todas essas opções parecem mais trabalhos do que eu gostaria de colocar no meu servidor doméstico. Alguém tem alguma sugestão?

    
por Kennet Belenky 11.05.2012 / 22:32

2 respostas

2

Você está assumindo que a corrupção irá se infiltrar silenciosamente, o que é uma forma de perda de integridade de dados que os desenvolvedores de hardware de sistema de arquivos e armazenamento ativamente trabalham para evitar. As chances são muito boas de que o motorista do bloco perceberá que algo deu errado com uma leitura / gravação e gritaria sobre isso, e nesse ponto cabe ao software de nível mais alto (Greyhole) lidar com a falha. Ou se o driver de bloco não perceber, o driver do sistema de arquivos irá.

O caso em que eu acho que você está preocupado é se raios cósmicos ou algo distorcem os bits de um arquivo em dispositivos diferentes, como a Greyhole lida com esse problema?

Você está praticamente ferrada, então você deve ir para uma redundância 3x se estiver preocupado com isso. No entanto, as chances de três dispositivos ficarem ruins ao mesmo tempo são muito menos do que apenas um indo mal, por isso é um caso muito distante.

    
por 11.05.2012 / 22:39
2

Respondendo com uma solução específica da Greyhole: use a opção --checksums para --fsck :

-k, --checksums
      Read  ALL  files  in  your  storage  pool,  and  check  that file copies 
      are identical. This should identify any problem you might have with your 
      file-systems.
      NOTE: this can take a LONG time to complete, since it will read everything
      from all your drives!

Você desejará garantir que seu servidor possa enviar e-mails e usar a opção --email-report ao mesmo tempo para receber um relatório quando ele for concluído. (O relatório também é salvo no disco, se você preferir. Em /usr/share/greyhole/ eu acho ...)

    
por 12.05.2012 / 03:19