You seem to know much more than me about how flash drives break... but since
you continue with this topic I feel like arguing more (even though I am
probably wrong):
Why writing on a file system (and not directly on /dev/sdb or whatever the
last letter) when you want to test the hardware? The file system may always
write at the same place or, in the contrary, prefer to write on blocks that
have been less used in the past (for instance, I believe btrfs does that to
lengthen SSD's lives). Here are consequences for these two extremal writing
strategies:
If the file system maximizes the number of written blocks, more iterations
will pass if the drive is larger. To avoid that, the whole drive should be
filled.
If the file always write in the same blocks, it may be that some of these
blocks have longer lives than others (I really doubt it is the case with
Flash drives but it must be so with hard disk where writing at the beginning
or the end of the disk means spinning more or less).
If the file system always write in the same blocks and the problem is a
difficulty to change the polarization of a bit, then the drive will never
fail because a new write will confirm what was previously on the drive. Using
/dev/zero between the writes is good... for the bits at 1 only.
All in all, the following (simpler) script seems to avoid these pitfalls. It
must be ru with administrator's privileges. It makes far less iterations
since the whole drive is used every time. I have not tested it since I do not
have any drive to destroy!
#!/bin/sh
DEVICE=/dev/sdaX
while true
do
if [ `cat /dev/urandom | tee $DEVICE | md5sum` = `cat $DEVICE | md5sum` ]
then
counter=`expr $counter + 1`
echo $counter successful iterations
fi
done
