teste de injeção de falha mdadm com blocos inválidos ou outros erros irrecuperáveis

2

Eu recentemente perdi uma unidade na minha matriz RAID (e recebi um e-mail do sistema me avisando sobre isso, o que foi muito bom) e depois de uma movimentação embaralhada e trocado em uma nova unidade, estou segura e protegida. Mas ao longo do caminho, eu encontrei este tópico , que obteve pensando em como você poderia realmente testar erros de disco e outras coisas ruins sem que elas realmente ocorressem. Quando eu corri o comando tar sugerido:

tar c /my/raid/device/mount/point > /dev/null

Ele foi concluído em poucos segundos, o que claramente não é o suficiente para o sistema ter realmente lido todos os arquivos (bem mais do que um TiB) - então eu acho que minha primeira pergunta é por que isso pode não ter funcionado. Se eu fizer algo assim:

find . -type f | xargs md5sum

Esse comando funciona muito bem, e leva muito tempo para ser concluído ... mas também carrega a CPU fazendo toda a soma. Isso pode ou não ser mais rápido ou mais fácil do que "tar" - estou mais curioso para saber por que o comando tar não funcionou como eu esperava.

De qualquer forma - segunda pergunta e, mais geralmente: existe uma maneira de fazer algo ao longo destas linhas para fazer testes de injeção de falhas:

  1. encontre (ou crie) um arquivo que não me interessa ...
  2. determine que um bloco no disco é usado para armazenar esse arquivo específico ...
  3. finge que o software / sistema operacional está pensando que esse bloco é "ruim" (suponho que, ao marcá-lo de alguma forma, é aqui que meu conhecimento se esgota)
  4. executar meus scripts de teste e / ou rotinas de verificação de erros
  5. confirme se a matriz relata o erro e realiza qualquer outra ação corretiva necessária ...
  6. marque esse bloco / setor como "bom" novamente para que o sistema / SO o use normalmente.

Isso parece algo que poderia ser feito, mas eu não tenho conhecimento detalhado suficiente das ferramentas do Linux que me permitiriam marcar um bloco tão ruim no nível do dispositivo sem que ele realmente seja um bloco ruim ...

pensamentos sobre isso? Ou, se há uma maneira muito mais elegante de resolver isso, fico feliz em ouvir isso também ...

    
por ljwobker 06.09.2015 / 04:14

3 respostas

5

Existe muita infraestrutura útil de injeção de falhas no Linux. Um deles pode ser útil para seus esforços de teste.

A página 7 desta apresentação mostra um exemplo de falsificação de um problema de dispositivo de bloco com dmsetup .

link

O próprio md (4) tem um modo chamado FAULTY que você pode usar para simular leitura / gravação erros.

Faulty

The FAULTY md module is provided for testing purposes. A faulty array has exactly one component device and is normally assembled without a superblock, so the md array created provides direct access to all of the data in the component device.

The FAULTY module may be requested to simulate faults to allow testing of other md levels or of filesystems. Faults can be chosen to trigger on read requests or write requests, and can be transient (a subsequent read/write at the address will probably succeed) or persistent (subsequent read/write of the same address will fail). Further, read faults can be "fixable" meaning that they persist until a write request at the same address.

Fault types can be requested with a period. In this case, the fault will recur repeatedly after the given number of requests of the relevant type. For example if persistent read faults have a period of 100, then every 100th read request would generate a fault, and the faulty sector would be recorded so that subsequent reads on that sector would also fail.

There is a limit to the number of faulty sectors that are remembered. Faults generated after this limit is exhausted are treated as transient.

The list of faulty sectors can be flushed, and the active list of failure modes can be cleared.

As opções que o controlam estão listadas em mdadm (8) em -p, --layout= .

When setting the failure mode for level faulty, the options are: write-transient, wt, read-transient, rt, write-persistent, wp, read-persistent, rp, write-all, read-fixable, rf, clear, flush, none.

Each failure mode can be followed by a number, which is used as a period between fault generation. Without a number, the fault is generated once on the first relevant request. With a number, the fault will be generated after that many requests, and will continue to be generated every time the period elapses.

Multiple failure modes can be current simultaneously by using the --grow option to set subsequent failure modes.

"clear" or "none" will remove any pending or periodic failure modes, and "flush" will clear any persistent faults.

Há exemplos dos arquivos da lista de correspondências linux-raid na injeção de erros Isso deve ajudá-lo a começar com as opções de injeção de falhas md também. =)

    
por 06.09.2015 / 11:16
1

Para sua primeira pergunta:

tar c /my/raid/device/mount/point > /dev/null

Vai depender de como o tar da sua distribuição se comporta na ausência do parâmetro "f". Eu tentei isso em um sistema Debian (wheezy) e ele se comportou como você poderia esperar - o arquivo foi escrito para stdout. No entanto, em um sistema FreeBSD. ele retorna um erro:

tar: Failed to open '/dev/sa0'

Uma abordagem mais universal seria especificar explicitamente o stdout como o arquivo:

tar cf - /my/raid/device/mount/point > /dev/null

Edit: Doh! Ou simplesmente esqueça de redirecionar:

tar cf /dev/null /my/raid/device/mount/point 

Além da excelente resposta de Kassandry, eu também recomendaria o uso do SMART se suas unidades físicas o suportassem para falhas preditivas.

    
por 06.09.2015 / 16:34
0

Tar tem uma "otimização", onde (quase) nada faz se a saída for / dev / null

Você pode tentar fazer isso para fazer o trabalho de qualquer maneira:

tar c /my/raid/device/mount/point | cat > /dev/null

    
por 14.06.2018 / 01:28