Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am going to be testing 'xfs_repair' on some large file systems ( around 50 TB ) as in the past the memory usage is high. While I could test the program only on file systems which were correct it would be good to test them on a corrupt system.

So what would be the best way to corrupt a file system. Extra credit if the method repeatedly gives the same corruption every time....

To give people an idea of what I mean in 2006 ish

"To successfully check or run repair on a multi-terabyte filesystem, you need:

  • a 64bit machine
  • a 64bit xfs _ repair/xfs _ check binary
  • ~2GB RAM per terabyte of filesystem
  • 100-200MB of RAM per million inodes in the filesystem.

xfs_repair will usually use less memory than this, but these numbers give you a ballpark figure for what a large filesystem that is > 80% full can require to repair.

FWIW, last time this came up internally, the 29TB filesystem in question took ~75GB of RAM+swap to repair."

share|improve this question
    
Interesting question, but can the formating of the quote be improved? –  Coops Jul 14 '09 at 15:29
    
If so I don't know how to ? –  James Jul 14 '09 at 16:20
    
Try surrounding it with ` –  Brad Gilbert Jul 14 '09 at 19:19
    
This is an interesting test. I are you planning on posting the results anywhere? –  3dinfluence Jul 14 '09 at 23:48
    
Well I will probably post to the xfs mailing list and I could always edit this question with the results. –  James Jul 15 '09 at 5:49
add comment

3 Answers

up vote 10 down vote accepted

xfs_db has an option blocktrash which

Trash randomly selected filesystem metadata blocks. Trashing occurs to randomly selected bits in the chosen blocks. This command is available only in debugging versions of xfs_db. It is useful for testing xfs_repair(8) and xfs_check(8).

For example

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

share|improve this answer
add comment

dd blocks to the device where the filesystem resides. You can script this so it is repeatable. Just a few random blocks at random locations, then move on.

share|improve this answer
    
In a 50TB file system which is mostly empty surely you would have to be quiet lucky to corrupt the system ? –  James Jul 14 '09 at 7:48
    
Well, you just have to use enough random blocks :-). Either way, a "collision" is probably more likely than you think, due to the Birthday Paradox : en.wikipedia.org/wiki/Birthday_Paradox . –  sleske Jul 14 '09 at 8:51
add comment

You could try overwriting first 512 bytes (MBR and partition table) of the block device.

Back it up first:

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

And zero it later:

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

Your machine should not boot after that, you can test XFS repair using live CD.

share|improve this answer
    
I want to have a relatively small corruption as run time and memory usage are dependent on the number of files and the size of the filesystem –  James Jul 14 '09 at 7:57
    
This is just 512 bytes of corruption. This just checks whether the filesystem is able to recover without any information on how the filesystem should look like - if xfs hasn't stowed away some spare superblocks somewhere. –  towo Jul 14 '09 at 11:41
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.