Flash drive life-span and test script

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

while true
do
if [ `cat /dev/urandom | tee $DEVICE | md5sum` = `cat $DEVICE | md5sum` ]
then
counter=`expr $counter + 1`
echo $counter successful iterations
fi
done

I did not really want to continue with this topic but post my "results" as well as the test script I used.

You can bet that there are at least two a dozens of variants in order to execute such a "stress test".

No matter what testing approach you choose, the weak point is still how to match the data gathered with real live. My stick (1GB) got written with a data volume of around 1.7TB. I can not really estimate what lifetime I could expect from a media which achieves at least lets say 2TB data being written to the stick. My 16GB san disk I use with Trisquel 5.5 is still happy. So is my 4GB CF card from my Debian box.

Thanks for making your own thoughts and posting your script. I choose to make writes to a file system rather than the block device because I wanted to make my test as close to the daily use as possible.

I will end my experiments now. If Chris wants to step in with further evaluation on compact SD cards I would be interested by the results. For now I will simply trust on my USB stick as I would any HDD.