Testing the robustness of a flash drive: dd'ing the drive till it fails?

Question

Hi,

I've been given a cheap, brandless 2GB flash drive. As I have a bigger flash drive, I have decided to use it for testing flash technology robustness.

I plan to write 1's all over the drive, check for correctness, write 0's, check and so on. I'll log the results, and seek for failures later.

I am looking for the most resource-saving technique for doing that. My current strategy includes using linux dd command for writing and reading, and comparing the result to a file of ones and zeros. Another approach would be writing ones and zeros to the drive, and calculating the md5 of its contents. This is a simple trade-off between extensive IO reads and high CPU usage; I guess I'll simply measure the running time of each method and decide.

Are there any better, more elegant ways of doing this?

Answer 1

Pick a random 32 bit number. Write that in every block. Read that from every block. New 32 bit number. Run the drive again. Hash algorithms like MD5 are CPU intensive. Since you know exactly the pattern and are just testing that the drive doesn't screw up the bits, simple direct comparison is the best approach. Don't use DD... write direct from a language like C or Perl (if there were ever apples standing next to oranges...)

No need to have a comparison file either... the pattern fits in memory. In fact, the whole test probably fits in the CPU cache if done neatly, but the flash drive will obviously be a bottleneck anyway. Find a number that isn't right, you know you've got your bad block.

Answer 2

You could also use the linux 'badblocks' command to do the tests for you. When used with the -w option it will do a write-mode test for you using various patterns, writing a block and reading it back to check it succeeded.

You can run it directly on the device without having it mounted too, to test every block of the physical device.

   -w     Use  write-mode  test. With this option, badblocks scans for bad
          blocks by writing some patterns  (0xaa,  0x55,  0xff,  0x00)  on
          every block of the device, reading every block and comparing the
          contents.  This option may not be combined with the  -n  option,
          as they are mutually exclusive.