Como corromper um sistema de arquivos

8

Vou testar o 'xfs_repair' em alguns sistemas de arquivos grandes (cerca de 50 TB), pois no passado o uso de memória era alto. Embora eu pudesse testar o programa apenas em sistemas de arquivos corretos, seria bom testá-los em um sistema corrompido.

Então, qual seria a melhor maneira de corromper um sistema de arquivos. Crédito extra se o método repetidamente fornecer a mesma corrupção todas as vezes ....

Para dar às pessoas uma idéia do que quero dizer em 2006, ish

"Para verificar ou executar o reparo em um sistema de arquivos com vários terabytes, é necessário:

  • uma máquina de 64 bits
  • um xfs de 64 bits _ repair / xfs _ check binary
  • ~ 2 GB de RAM por terabyte de sistema de arquivos
  • 100-200MB de RAM por milhão de inodes no sistema de arquivos.

O xfs_repair geralmente usa menos memória que isso, mas esses números fornecem uma estimativa aproximada do que um sistema de arquivos grande com mais de 80% de capacidade pode exigir para reparar.

FWIW, na última vez em que isso ocorreu internamente, o sistema de arquivos de 29 TB em questão levou ~ 75 GB de RAM + swap para reparar ".

linux filesystems testing corruption xfs James
fonte
Pergunta interessante, mas a formatação da cotação pode ser melhorada?
Coops
Se sim, não sei como?
James
Tente cercá-lo com `
Brad Gilbert
Este é um teste interessante. Você planeja publicar os resultados em algum lugar?
3dinfluence
Bem, provavelmente vou postar na lista de discussão xfs e sempre posso editar essa pergunta com os resultados.
James

Respostas:

12

xfs_db tem uma opção de blocktrash que

Lixeira aleatoriamente selecionados blocos de metadados do sistema de arquivos. O lixo ocorre nos bits selecionados aleatoriamente nos blocos escolhidos. Este comando está disponível apenas nas versões de depuração do xfs_db. É útil para testar xfs_repair(8)e xfs_check(8).

Por exemplo

xfs_db -x -c blockget -c "blocktrash -s 512109 -n 1000" /dev/xfstest/testfs

James
fonte
2

O dd bloqueia no dispositivo em que o sistema de arquivos reside. Você pode criar um script para que seja repetível. Apenas alguns blocos aleatórios em locais aleatórios, depois siga em frente.

Posipiet
fonte
Em um sistema de arquivos de 50 TB que está quase vazio, certamente você teria que ter a sorte de corromper o sistema?
James
Bem, você só precisa usar blocos aleatórios suficientes :-). De qualquer maneira, uma "colisão" é provavelmente mais provável do que você pensa, devido ao Paradoxo do Aniversário: en.wikipedia.org/wiki/Birthday_Paradox .
sleske
0

Você pode tentar sobrescrever os primeiros 512 bytes (MBR e tabela de partição) do dispositivo de bloco.

Faça o backup primeiro:

dd if=/dev/device bs=512 count=1 of=backup.bin

E zere-o depois:

dd if=/dev/zero bs=512 count=1 of=/dev/device

Sua máquina não deve inicializar depois disso; você pode testar o reparo do XFS usando o Live CD.

Karolis T.
fonte
Quero ter uma relativamente pequena corrupção como tempo de execução e uso de memória são dependentes do número de arquivos e o tamanho do sistema de arquivos
James
Isso é apenas 512 bytes de corrupção. Isso apenas verifica se o sistema de arquivos é capaz de se recuperar sem nenhuma informação sobre a aparência do sistema de arquivos - se o xfs não tiver guardado alguns super-blocos de reposição em algum lugar.
14/07/09