Comment corrompre un système de fichiers

8

Je vais tester 'xfs_repair' sur certains gros systèmes de fichiers (environ 50 To) car par le passé, l'utilisation de la mémoire est élevée. Bien que je puisse tester le programme uniquement sur des systèmes de fichiers corrects, il serait bon de les tester sur un système corrompu.

Alors, quelle serait la meilleure façon de corrompre un système de fichiers. Crédit supplémentaire si la méthode donne à chaque fois la même corruption à chaque fois ....

Pour donner aux gens une idée de ce que je veux dire en 2006 ish

"Pour vérifier ou exécuter avec succès la réparation sur un système de fichiers de plusieurs téraoctets, vous devez:

une machine 64 bits
un 64 bits xfs _ réparation / xfs _ contrôle binaire
~ 2 Go de RAM par téraoctet de système de fichiers
100 à 200 Mo de RAM par million d'inodes dans le système de fichiers.

xfs_repair utilisera généralement moins de mémoire que cela, mais ces chiffres vous donnent une idée approximative de ce qu'un gros système de fichiers> 80% plein peut nécessiter pour réparer.

FWIW, la dernière fois que cela s'est produit en interne, le système de fichiers de 29 To en question a pris environ 75 Go de RAM + swap pour réparer. "

— James
source

Question intéressante, mais la formulation du devis peut-elle être améliorée?

— Coops

Si oui, je ne sais pas comment?

— James

Essayez de l'entourer de `

— Brad Gilbert

Ceci est un test intéressant. Je prévois de publier les résultats n'importe où?

— 3dinfluence

Eh bien, je posterai probablement sur la liste de diffusion xfs et je pourrais toujours modifier cette question avec les résultats.

— James

12

xfs_db a une option blocktrash qui

Mettez les blocs de métadonnées du système de fichiers sélectionnés au hasard. La corbeille se produit pour les bits sélectionnés au hasard dans les blocs choisis. Cette commande n'est disponible que dans les versions de débogage de xfs_db. Il est utile pour tester xfs_repair(8)et xfs_check(8).

Par exemple

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

— James
source

2

dd se bloque sur le périphérique où réside le système de fichiers. Vous pouvez l'écrire afin qu'il soit reproductible. Juste quelques blocs aléatoires à des emplacements aléatoires, puis continuez.

— Posipiet
source

Dans un système de fichiers de 50 To qui est pour la plupart vide, vous devriez sûrement avoir la chance de corrompre le système?

— James

Eh bien, il vous suffit d'utiliser suffisamment de blocs aléatoires :-). Quoi qu'il en soit, une "collision" est probablement plus probable que vous ne le pensez, en raison du Birthday Paradox: en.wikipedia.org/wiki/Birthday_Paradox .

— sleske

0

Vous pouvez essayer d'écraser les 512 premiers octets (MBR et table de partition) du périphérique de bloc.

Sauvegardez-le d'abord:

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

Et zéro plus tard:

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

Votre machine ne devrait pas démarrer après cela, vous pouvez tester la réparation XFS en utilisant un CD live.

— Karolis T.
source

Je veux avoir une corruption relativement petite car le temps d'exécution et l'utilisation de la mémoire dépendent du nombre de fichiers et de la taille du système de fichiers

— James

Ce n'est que 512 octets de corruption. Cela vérifie simplement si le système de fichiers est capable de récupérer sans aucune information sur la façon dont le système de fichiers devrait ressembler - si xfs n'a pas rangé des superblocs de rechange quelque part.

— au