Come corrompere un file system

8

Proverò "xfs_repair" su alcuni file system di grandi dimensioni (circa 50 TB) poiché in passato l'utilizzo della memoria è elevato. Mentre potrei testare il programma solo su file system corretti, sarebbe bene testarli su un sistema corrotto.

Quindi quale sarebbe il modo migliore per corrompere un file system. Credito extra se il metodo fornisce ripetutamente la stessa corruzione ogni volta ....

Dare alla gente un'idea di cosa intendo nel 2006

"Per controllare o eseguire correttamente la riparazione su un file system multi-terabyte, è necessario:

una macchina a 64 bit
un binario di controllo xfs _ repair / xfs _ a 64 bit
~ 2 GB di RAM per terabyte di filesystem
100-200 MB di RAM per milione di inode nel filesystem.

xfs_repair userà di solito meno memoria di questa, ma questi numeri ti danno una figura a sfera per ciò che un grande filesystem pieno> 80% può richiedere di riparare.

FWIW, l'ultima volta che questo è emerso internamente, il filesystem da 29 TB in questione ha richiesto ~ 75 GB di RAM + swap per la riparazione. "

— Giacomo
fonte

Domanda interessante, ma è possibile migliorare la formulazione della citazione?

— Coops

Se è così non so come?

— James,

Prova a circondarlo con `

— Brad Gilbert

Questo è un test interessante. Ho intenzione di pubblicare i risultati ovunque?

— 3dinfluence

Bene, probabilmente posterò nella mailing list di xfs e potrei sempre modificare questa domanda con i risultati.

— James,

12

xfs_db ha un'opzione blocktrash che

Cestino blocchi di metadati del filesystem selezionati casualmente. Il cestino si verifica su bit selezionati casualmente nei blocchi scelti. Questo comando è disponibile solo nelle versioni di debug di xfs_db. È utile per i test xfs_repair(8)e xfs_check(8).

Per esempio

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

— Giacomo
fonte

2

dd si blocca sul dispositivo in cui risiede il filesystem. Puoi scrivere questo script in modo che sia ripetibile. Solo alcuni blocchi casuali in posizioni casuali, quindi andare avanti.

— Posipiet
fonte

In un file system da 50 TB che è per lo più vuoto sicuramente dovresti essere abbastanza fortunato da corrompere il sistema?

— James,

Bene, devi solo usare abbastanza blocchi casuali :-). Ad ogni modo, una "collisione" è probabilmente più probabile di quanto si pensi, a causa del paradosso del compleanno: en.wikipedia.org/wiki/Birthday_Paradox .

— sleske,

0

È possibile provare a sovrascrivere i primi 512 byte (MBR e tabella delle partizioni) del dispositivo a blocchi.

Eseguire prima il backup:

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

E azzeralo più tardi:

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

Dopo di ciò il computer non dovrebbe avviarsi, è possibile testare la riparazione XFS utilizzando il CD live.

— Karolis T.
fonte

Voglio avere una corruzione relativamente piccola poiché il tempo di esecuzione e l'utilizzo della memoria dipendono dal numero di file e dalle dimensioni del filesystem

— James

Sono solo 512 byte di corruzione. Questo controlla solo se il filesystem è in grado di recuperare senza alcuna informazione su come dovrebbe apparire il filesystem - se xfs non ha riposto da qualche parte alcuni superblocchi di riserva.

— towo