How Long Does a Flash Drive Last?

Prepping the Media
I had to write a utility that could do file reading and writing using the O_DIRECT flag. That means that the filesystem access directly interacts with the file. This is needed since the filesystem likes to cache file data in
RAM. This is ideal under most circumstances, but for my testing, we don't want this. In order to use O_DIRECT, I'm going to have to reformat the drives to use the ext3 filesystem. The drives came with vfat filesystems, which doesn't appear to support O_DIRECT properly.

Here is how I created the filesystems:

mkfs.ext3 -m 0 -b 1024 /dev/sdb1

Yes it has a journal, but that's how I would use it, so that's acceptable.

The Test
Fill up the disk, leaving one free block. Write to that block over and over with random data each write, until device failure.

Create test file:

dd if=/dev/urandom of=test-file bs=1024 count=1

sync that file once, then fill up the disk using this command

dd if=/dev/urandom of=big-file

We then start running the application which will overwrite test-file until the drive fails.

This test isn't really possible, as a one block file, really needs more than one block. This is of course due to filesystem magic I don't completely understand, but that's OK. Presuming all needed blocks are written to, this should be OK. It seems the drive had to have 3 free blocks for this test to work.

I'm going to guess that this means I should get somewhere around 30K writes before the device dies. The numbers I keep reading are that a USB flash drive can see a about 10K write per block before it dies.

The Results
It turns out that the wear leveling seems to work better than I expected. It took 90593104 writes for the drive to die. That's 90.5 million, well beyond my expected 30K. From looking at my data, it appears that the flash drive will move used blocks as part of the wear leveling. As I had no idea how the wear levelling would work, this was a pleasant surprise. The below graph shows the number of microseconds needed for each write. As I have too much data for gnuplot to easily handle, I'm only graphing every 1000 points. There appears to be three distinct lines, the top two I presume are when the wear levelling is moving around blocks, while the bottom solid line shows that the vast majority of writes took about 1500 microseconds.


The long write times don't seem to follow any sort of real pattern. I graphed how many writes occurred between each "long" write (a write which was > 10000 microseconds) and the graph is even more puzzling.

It would seem the drive was well aware of its impending death and stopped wear leveling quite as often.

The reads were a bit more constant. Even as the drive was dying, the time it took to read data never really changed.


The Death
The application I was using to read and write the data wasn't what caught the death of the drive, it ended up being ext3 itself. While the application quit working, it failed during the write, not during the readback verification. This was the console message I saw

Message from syslogd@link at May 15 07:44:03 ...
kernel: journal commit I/O error

I can still mount and read from the drive, but I can no longer write to it. It's nice to know that when a drive dies, it's more likely you just won't be able to write new data to it, rather than complete data loss.

I'm happy to say that I have far more confidence in these little drives than I thought I would be. While it obviously can't stand up to the sort of abuse you could give a hard drive, it's easily good enough for my emergency needs.