3 ms·
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.
by ericpauley 4y ago
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.
- rkagerer 4y agoFor 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).
- bartvk 4y agoI 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.
- zapu 4y agoI've been using F3 to test new SD cards: https://github.com/AltraMayor/f3 https://github.com/AltraMayor/f3 I think it does practically the same thing as your method.
- 4gotunameagain 4y agoflash uses over-provisioning, I'm not sure this script would have the desired effect.
- sowbug 4y agoRelated: 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.