Simulando corrupção de arquivos no Linux programaticamente? (para teste de durabilidade de DB)

Question

Basicamente, eu quero fwrite() n bytes e ter < n bytes escritos no disco atual, ou quaisquer outros artefatos de inconsistência que possam surgir (como setores sendo escritos fora de ordem).

Sei que posso fazer isso em um nível de hardware com:

• bare metal puxando o cabo de alimentação OU
• com o SO virtualizado apenas emitindo uma reconfiguração por meio do hipervisor.

.. mas eu não gosto dos casos acima porque:

• Eu não quero danificar meu hardware com perda real de energia.
• A simulação de perda de energia real é manual e / ou difícil & feio para automatizar.
• A simulação de perda de energia de virtualização é melhor, mas acho que seria muito lento executar 100 execuções no banco de dados aguardando que as inicializações de VMs e feias tivessem que criar lógica para tentar novamente fazer logon via SSH até que a VM seja inicializada. / li>

.. então eu estou procurando uma solução mais rápida e fácil para construir automação para.

Eu tive algumas ideias:

1) Mate o processo com $ kill -9 dbms_pid

Isso provavelmente não funcionará, como eu acho que tudo dado a fwrite() é adicionado atomicamente a buffers gerenciados pelo kernel (isso é especulação), e após o processo de matar o kernel provavelmente apenas libera os buffers normalmente para o disco? / p>

2) Desmonte o sistema de arquivos mid-write

Eu não acho que a desmontagem funcione enquanto houver arquivos abertos no sistema de arquivos.

3) Faça com que o sistema de arquivos resida em um dispositivo de loopback respaldado por um arquivo e pare de gravar nesse arquivo no ponto de corte de energia

Eu não acho que haja um mecanismo para isso. Renomear o arquivo provavelmente não interrompe as gravações no sistema de arquivos, já que o driver de loopback provavelmente se refere apenas a um inode ou a alguma referência interna.

Desmontar o dispositivo de loopback provavelmente tem o mesmo problema de não poder fazer quando alguém tem arquivos abertos nele.

Copiar do block-device-as-a-file pode funcionar (a menos que seja bloqueado exclusivamente para gravação, o que provavelmente é), mas como copiar o conteúdo não é uma operação atômica, ele provavelmente traria artefatos não relacionados ao desligamento.

4) Tenha o sistema de arquivos hospedado em cima do LVM e faça um snapshot

Esta é provavelmente a minha ideia mais funcional. Tirar um instantâneo do volume do LVM é atômico e poderia simular a perda de energia? Eu acho que buffers / páginas não-preenchidos não são levados em conta para o snapshot (o que é bom para minha simulação) e eu espero introduzir os mesmos artefatos como uma perda de energia, como fwrite() sendo apenas metade escrita?

Haverá gravações fora de ordem ou páginas escritas em volumes LVM sempre serão aplicadas em ordem?

Você tem alguma outra ideia? O que você acha das opções? Você concorda que 4) é a melhor ideia?

Por que estou fazendo isso: basicamente, estou desenvolvendo um banco de dados cuja durabilidade eu gostaria de testar construindo um script automatizado que o levaria a uma grande rodada de testes de tortura, fornecendo dados para salvar, enquanto simulava um perda de energia contra o disco, pelo menos, e, em seguida, verificar que nenhum dado confirmado foi perdido e que o banco de dados pode se recuperar com segurança.

    

Answer 1

Presumivelmente, eles são drives SATA, que são potencialmente "hot swappable".

Então, faça o seu dever de casa: a troca de velocidade do seu sistema para que você não libere {fumaça mágica} e, em seguida, puxe a unidade durante os testes de tortura.

Eu olharia para um caddy de unidade de troca hot swap, em vez de tentar desconectá-los manualmente.

Algumas leituras adicionais: link