Chris,
it seems logical to me that someone would not use any Flash-based storage for
heavy random write-access.
I do not think that the interface (USB vs. SATA vs. IDE) plays a big part
here. A CF card inside a USB card reader will have a different lifespan
compared to the CF card in a Flash2IDE adapter.
The german part of the C't article I posted says this:
Their script was writing more or less random data to a 2GB usb stick (full
data write). Every 50 writes the script checked if the data at the stick was
written correctly by MD5 checksum. After a month they were doing more than 16
milions (!) write access which translates to a volume of 23.5 TB data written
to the USB stick.
To quote one of the archlinux wiki entries I mentioned:
Note: A 32GB SSD with a mediocre 10x write amplification factor, a standard
10000 write/erase cycle, and 10GB of data written per day, would get an 8
years life expectancy. It gets better with bigger SSDs and modern controllers
with less write amplificati
OK, even with a standard 10k write/erase cycles for flash cells and 10GB data
volume written to a SSD (which of course might have techically different
layout, different write algorithms) they expect a life expectancy of 8 years.
Unfortunately I do not have the DVD from C't magazine
(http://www.heise.de/ct/) from 2006, so I can not find out which script they
used but this is no problem.
I will do the following (may be this weekend):
Write a script which fills up a USB device with random data and compares the
written file with the source file via MD5 checksum. Once the file written to
the USB device is different from the source file I will stop the test. Then I
will publish the results here. I have both an old 1GB USB stick and several
smaller CF cards lying here around which I do not mind trashing.
A rough outline of the test scenario is this:
1) Create a RAM disk on my Linux box holding the source file (to minimize
read access to my HDD) via tempfs
2) Create a file inside the RAM disk with roughly the size from the target
device via dd from /dev/random
3) Generate the MD5 checksum from the source file in the RAM disk
4) Wipe the target device via rm -rf *
5) Copy the source file to the target device
6) Generate MD5 checksum of the target device file
7) Write loop count and MD5 checksum to a log file
8) If source and target files differ stop the loop
Unfortunately I neither have enough RAM in my system to set up a 16 GB RAM
disk), nor am I willing to shell 10€ for a 16GB USB stick simply to trash
it. This is up to someone else with bigger wallet and a more beefy system.
I will both publish the bash script and interim results to the mailing list
as I guess this is interesting for everyone running Trisquel from Flash. By
posting the script everyone can try himself how flash stands up the intense
use. We will see. Being an engineer myself I rather trust those things I can
see / try out myself than relying on ańything that someone else posted.
Oh yes, and my Debian system on the 4GB CF received the usual apt-get update
/ apt-get upgrade as soon as I was aware of any security fixes. This means
at least once a week. And as for the lower write speed of the USB Flash
devices compared to SSD or even a normal HDD you will most likely only notice
it during installation, updates and of course if saving bigger files. A
normal use (writing mails, surfing the web, watching video, listening to
podcasts, etc.) means usually much lower write access.
HTH,
Holger