Install on microSD

How you use it make a huge difference. Don't use it for databases is all I can say. Using it for routers and similar types of devices where nothing gets written to the flash should be fine.

On 06/07/2012 02:45 AM, name at domain 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.

Maybe I should have rephrased it. The problems I see may not be the result of write access to the card. It could have other explanations.

I have done a lot of testing though with solid setups (ext2 rather than ext3/ext4, read-only setups with AUFS and ram, etc). The updating part in my experience kills it. However it could be that taking it in and out frequently (daily) for months causes the problem. It could also be that maybe data isn't being properly flushed to the disk on shut down or something similar.

However that said I can think of other scenarios where lots of data does appear to have killed the USB flash sticks. I'll give you examples. I used the Trisquel flash drive to write bootable ISO images to it. I got maybe 5-10 images written to it before I started seeing disk errors. In that situation I didn't take the drive in and out though more than maybe a dozen times. Now these are cheap flash drives and not using SLC or anything like that. And it is pretty well known that the cheap stuff doesn't last.

However I have seen similar results with highly rated "never fails" MLC Micro SD cards that run significantly higher. I was testing with 16GB cards.

I've also seen problems with 32GB SDHC cards with SLC.

For those who don't know SLC is a higher quality flash which allows more writes to it before failing.

Some of the setups I've had included real world testing with things like raid: software raid'd that is between two 32GB SLC SDHC cards that used USB card readers. Ultimately the one drive failed in a rather short time. And yes- this was with a properly setup card. It was used in a read-only setup (and verified) except during the update process. The only other time it got written to were when files were saved to a second partition although this 2nd partition was not for swap. It was for data and did not hold a home directory and didn't get mounted until I manually mounted it. No data would have been written to it without having manually mounted it and then going to save a file.

And the reason for the raid'ing of SDHC cards and using SLC had to do with the fact flash is terribly unreliable in the real world.

Now- I'm not trying to dispute your results. There could be an explanation for this that has nothing to do with the read/write or the connection. I haven't figured it out and am doubtful though given all the evidence I've seen.

I think when SD/Micro SDHDC/etc cards are used to store files infrequently or used in cameras/phones/etc they tend to last. That has been my experience and what I've seen from reading well reviewed cards with hundreds of people reviewing the same product.

More data would be useful. My data comes from years and years and years of testing. I'm actually working on testing a type of Mini non-removable SSD card that fits into the Mini PCIe card slot (If I recall correctly, this has been a project that has spanned 10+ years which I infrequently gets to work on, these slots though have to support a USB function to work with the Mini PCIe SSD cards).

I've tried compact flash using adapters to IDE adapters in the past. I always seemed to run into problems with the adapters though. You can get an OS loaded on them, it boots, and shortly thereafter fails. I haven't done that though in 10+ years probably though. I last tested that with a 200Mgz Pentium system.

You are not always writing the same random file, do you? If you do, I believe the result does not tell much since the new write confirms what was on the drive ('rm' does *not* remove the data, just the inode).