Hacker News Reader

Comment by ericpauley | Hacker News Reader

The obvious question is what are the failures? While it may not matter to BB in this case, a drive going read-only is far less of an issue than losing data.

View on HN

For what it's worth the only SSD I've had that failed into a readonly state was (IIRC) an Intel one. Had others fail in worse ways (and some Pacer drives that just silently corrupted your data - proved this out with a test program I wrote that filled the disk with pseudorandom bits and read them back).

I always do this with new USB sticks. Write one random file, fill the drive with copies and then test for the checksum, for example for a 16 gig thumbdrive:

    $ cd /path/to/thumbdrive
    $ dd if=/dev/urandom of=test.bin bs=1000000 count=100
    $ for i in $(seq 1 160); do echo "Writing file $i"; cp test.bin test$i.bin; done
    $ md5 test.bin
    MD5 (test.bin) = 0d3c4fe338109b09b61fcea3e11b0e4b 
    $ ls *.bin | xargs md5 | grep -v 0d3c4fe338109b09b61fcea3e11b0e4b

I'd be happy to hear if there's a oneliner for this, though.

I've been using F3 to test new SD cards: https://github.com/AltraMayor/f3

I think it does practically the same thing as your method.

flash uses over-provisioning, I'm not sure this script would have the desired effect.

Related: proving that your fake $50 16TB USB drive really is fake. Really clever malicious firmware would notice your script is writing the same 100MB over and over (or the same 25K block checksums over and over), and would successfully trick your script.

Different threat model, though.

Reply on news.ycombinator.com