
Death and Resurrection of an SSD - basil
http://rentzsch.tumblr.com/post/12955002148/death-and-resurrection-of-an-ssd
======
daxelrod
Ugh. Rentzsch is a braver person than I.

I wonder how many days of backups he keeps. If his drive were to start
silently corrupting data again, how long would it take him to figure it out?
Even if he did have an extensive archive, hunting through it to find good
versions of all of his files would be a royal pain.

I'm also curious how stressdrive handles the various levels of caching between
it and the disk. I guess the expectation is that the cache is not nearly as
large as the entire drive?

------
__david__
Btw, a quick way to write random data to your disk is with "dd":

    
    
        dd if=/dev/random of=/dev/your_disk_dev bs=1m
    

Use "bs=1M" on linux. It read back the data like his stresstest program does,
but it's really about as "close to the kernel" as you can get without writing
your own C code (and you probably aren't going to do anything faster or better
than dd already does).

~~~
daxelrod
EDIT: I see now that you say "It read back the data like his stresstest
program does" and probably mean "It _won't_ read back data..."

While your command is a good way to quickly write random data to a drive, note
that it doesn't match the functionality of his stressdrive program, which
keeps a checksum of the random data it wrote, and then reads back the data
from the drive to verify the checksum.

Not that that would be hard to do with a few pipes. Note that the docs for
stressdrive[1] mention this:

    
    
        "Pshaw! I could do this with dd, /dev/random & shasum!"
         Indeed you could. I prefer a minimal focused tool whose
         operation is fixed, its source simple+readable and
         offers good built-in progress reporting.
    

[1]: <https://github.com/rentzsch/stressdrive>

~~~
JoeAltmaier
How is this different from writing each block's own address to it, and reading
them back? That's the test I use to detect errors in block addressing.

