On 06/07/2012 02:45 AM, holger.be...@gmail.com wrote:
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
FYI:
I have been using USB sticks and SDXC cards (in a Lexar USB adapter)
to test Installs of Fedora 17 from the USB/SDXC. I have never had a
failure. All tests required a f17 disk-utility re-format to GPT and fat
/dev/sdb1. I was able to create persistent USB's of the live.iso's;
Build USB's that install DVD contents to HD; and do dd writes and
liveusb-creator (with persistence) with no failures. I recommend using a
custom format of /Bios Boot +/ ext4 and no swap. when formatting. I
have not tried LVM on a USB
I have seen NO failures in the 2-3 years that I have been writing to
these USB's _Including some $4.95 EMtec 4 GB usb's.- (I normally use
HP125, Toshiba 8 and 16GB; Lexar Firefly 2GB and 4 GB.) Newly arrived:
SanDisk ULTRA SDXC 30x 64GB Cards
Tom Gilliard
satellit_
I also use Ubuntu/Trisquel USB Startup Disk Creator successfully
(usb-creator-gtk) with these sticks.
