| Date: | December 15, 2005 / year-entry #386 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20051215-11/?p=32963 |
| Comments: | 42 |
| Summary: | You probably wouldn't want to run Windows or applications directly off your USB memory drive, even if you could. The reason is that the solid-state memory used by these drives support only a limited number of write cycles per block. (Originally measured in the thousands, though I'm led to believe that it's gone up since... |
You probably wouldn't want to run Windows or applications directly off your USB memory drive, even if you could. The reason is that the solid-state memory used by these drives support only a limited number of write cycles per block. (Originally measured in the thousands, though I'm led to believe that it's gone up since then.) Most software assume that a disk's lifetime is essentially infinite and have no qualms about writing to a file multiple times. For example, your program might decide to group its data in chunks. To modify a byte of the file, you would load a chunk, modify the byte, then write the chunk out. You've "spent" a write cycle for an entire chunk of data even though you really might have been able to get away with updating a single sector. What's more, if that one byte gets modified three times in a row, you just paid for three writes when you could have gotten away with just one if you had just done a little more caching. Operating systems often update a file's metadata with high frequency. The last-modified time on a directory entry gets rewritten each time the file is updated. The free block bitmap is updated each time disk space is allocated or released. The page file gets updated constantly. A database application will update its database index very frequently. Even a simple application will probably update its history and settings files often. These "hot spots" are most likely to wear out first on a drive. Unfortunately, these hot spots also tend to coincide with nonrelocatable critical file system metadata; as a result, once the sector responsible for, say, the free cluster table goes bad, the drive is useless (in the absence of hardware sector remapping). I know some people who wrote a so-called "Flash File System" specifically designed for this class of devices. It spread the writes out across the disk so that it wore uniformly, avoiding the "hot spot" problem. The file system came out in the early 1990's and promptly died because the hardware hadn't yet caught up to the software. It was a solution ahead of its time. Note that my information about the number of write cycles of flash memory is pretty old. Can modern USB drives handle millions of writes before wearing out? |
Comments (42)
Comments are closed. |
At least a few manufacturers offer what is usually marketed as "industrial" grade flash products (I’ve seen these in CF, but suspect USB is available). These usually claim 2 million write/erase cycles versus 1 million for the consumer products (although, getting the detailed product information for the consumer products is sometimes hard). Even with that many write operations, operating system tuning (e.g. disabling last modified time and background defragmentation) and other protections like XPe’s enhanced write filter are critical if you don’t enjoy mysterious disk errors.
I think it depends on the type of flash but it’s in the region of about 1,000,000 writes for some of the best chips.
I run apps from flash to clean up systems that are infected with spyware and viruses. Firefox can run from a flash drive, and most antispyware apps do as well. I’ve had six of these USB flash keys, mostly the cheap $20 models, and never had one fail because the flash went bad. I’ve had two physically break though, so maybe the electronics aren’t the weak spot.
Here’s another endorsement of flash durability. The Vista guys are doing a lot of work to improve power management, and part of that is reducing disk drive power consumption. At the last WinHEC they showed a Samsung hybrid drive that had a large front-end flash buffer. That way the drive wouldn’t need to spin up in many cases. Of course Vista has a bunch of changes to make that work nicely, and I suspect they avoid excessive writes to flash.
BTW, I think this is the paper you mentioned:
http://citeseer.ist.psu.edu/kawaguchi95flashmemory.html
This was one of the issues faced when we made Pocket Access and ADOCE back in 97/98, and a million writes was the ballpark limit. You’ll really don’t want to be writing back to the file on a per-record basis when you have a large database. It’s better to have software that can handle large R/O databases like product catalogs.
I believe Linux has some options (in patches, not included in the standard kernel) for flash FSes, though it’s possible that that’s old information too.
Since writes to flash media involves erase, consecutive writes to a (logical) sector do not write to the same (physical) sector. This is how it works with most modern day removable flash media (not sure how the firmware for the USB Thumbdrives are written). So, as long the disk space is not near full capacity, the writes are okay. Only once in N writes to the same logical sector will the same physical sector be re-written. Where the N is the number of free physical sectors (this is usually more than the number of free logical sectors).
Logical sectors are sectors as seen by the OS. Physical sectors are the sectors as seen by the media. Flash media like memory stick, xD picture card, SmartMedia, have this memory mapping known to their readers. Media like MemoryStick Pro, MMC, SD,.. are slightly more intelligent in that they abstract this functioning from the host (reader).
Running the OS directly from flash memory is certainly doable (the proof is in my keychain) and it can be very practical for troubleshooting machines with problems. For avoiding excessive writing it is a good idea to use a version that is designed to run from CD (like Windows XP Preinstallation Environment or the equivalent non-Windows choices) and remembering to reserve some space in the memory so that it is possible to save data manually if it is necessary.
How about "Super-Fetch" (from Jim Allchin’s keynote) in Windows Vista? Isn’t that suppose to leverage a USB drive to extend VM?
Schweitzer Engineering sells industrial PCs which have compact flash hard drives.
http://www.selinc.com/computers.htm
The 3301 unit comes with XP Embedded and the Enhanced Write Filter to protect the CF card. They have had so many problems with the Write Filter (customers not realizing that File->Save doesn’t actually save a file until it is explicitly committed to flash) that they gave up on it for the 3351 unit.
I believe Intel’s Strataflash has wear leveling, either built-in or optional. I’m not sure if it’s done at the hardware or software level though.
hardware: http://www.intel.com/design/flcomp/prodbref/306782.htm
software: http://www.intel.com/design/flcomp/toolbrfs/298073.htm
My USB stick has a write protection switch. I think this is the best policy against wearing out the stick because of excessive writes.
Aren’t they just EEPROMs?
And how does that memory mapping work? It seems to me that no matter what kind of creative memory mapping you come up with, you have to have a FAT-equivalent at the beginning of the flash drive. I would expect that to fail long before any of the other segments of the memory.
Michael: The memory mapping makes it so that the FAT-equivalent that’s at the "beginning" of the drive isn’t actually at the physical beginning of the drive. The sectors that the OS sees are different than the sectors on the flash chips.
It’s like virtual memory: process memory can be moved around in physical RAM at will by the OS, as long as it keeps the page tables for that process updated. The page tables are a layer of indirection between the virtual addresses used by the process’s code and the physical addresses sent out the memory bus.
Likewise, there’s probably a virtual-sector to physical-sector mapping table somewhere in the flash drive’s firmware, that the firmware keeps up to date.
About flash drives being just EEPROMs: I don’t believe so, but I don’t know for sure. I think the number of write-erase cycles that a typical EEPROM can do is smaller than the number of write-erase cycles that a typical Flash chip can do; but again, that’s possibly-out-of-date information. I don’t know for sure.
Umm.. shouldn’t the OS’s disk cache help majorly with this issue?
Or does MS mount flash-disks synchronously?
Oh, wait, I see what you’re saying: No matter how you do it in the FS code, you still have at least one portion that changes fairly frequently.
Maybe the FS code moves the FAT structure around?
I’m not entirely sure on that one though, either.
The rewrite problem is why I don’t use flash based memory. Nope, I’m building thumb drives using hand wound ferrous core. My first 16K unit is about the size of a large dictionary so I can’t plug it directly into the usb port. Instead I use a usb extension cable.
Compact Flash devices have wear-leveling built in. On top of emulating an ATA drive, they also shuffle blocks around to try to keep the wear level across the memory device. They will relocate blocks that become dead. So, even if you continuously write one byte in the same location, on the actual physical flash, that block might move all over the device.
I was stunned to see the myriad differences between similarly labeled CF devices. I’m told they use second-rate FLASH chips and just use the wear-leveling and defect tracking systems to work around it. So, even if your have 512MB of space on the card, only a fraction of that could be available.
Of course, nobody documents their wear-leveling schemes, so I couldn’t tell you which one was better or worse. When I was doing embedded linux work, our solution was to limit writes to the disk as much as possible — no swap space, for one.
The other trick is to mount filesystems with ‘noatime’ — which turns off some of the filesystem metadata updating — specifically, it no longer updates the ‘last accessed’ time. This setting is useful in non-flash environments because it makes read-only operations faster. Web servers, for instance, should probably serve content from filesystems mounted noatime.
"Umm.. shouldn’t the OS’s disk cache help majorly with this issue? "
Nope. Flash drives are removable media, and by default Windows assumes you will be capricious and yank them out without using the "Safely Remove Device" feature. So, it uses a write-through policy rather than buffering writes and doing them in batches. That way the data is always consistent unless you yank it while an app is in the midst of a write.
If you like to live dangerously, you can go into Device Manager and change the policy for the flash drive to "Optimize for performance". After that you’d better always use the Safely Remove Device feature or be prepared to kiss your data goodbye.
USB flash drives will actually do wear levelling which does greatly mitigate against the wear and tear – you won’t constantly be doing erase cycles on the same flash block.
Linux has JFFS2 in the standard kernel and YAFFS too (can’t remember if that is merged or not) both of which are flash-specific. However, you still need to pay attention to what you’re doing in your application – it’s only possible to mitigate against wear problems, not eliminate them.
At about £30 for a half gig pen drive, I’m not going to lose too much sleep over this.
I dunno, I end up losing all my USB drives before they could possibly die….
(Maybe that’s why I’ve stopped buying them.)
As alluded to by numerous people, "flash" is a wide ranging term. Flash is a specific type of memory, different than EEPROM, but with similar characteristics.
At the lowest level, you have flash memory chips. Flash chips will wear out if you write to the same sector.
So people do "something" to wear-level.
In the case of removable flash media, there’s a controller of some sort that provides some sort of abstract access to the flash disks themselves. CompactFlash has 3 distinct access modes, with the low level being simple "read/write this memory address", and the high level being "I’m an IDE hard drive!"
In the case of embedded devices running off of flash that’s soldered on board (cellphones are the prime example), the wear leveling is usually handled in software. Flash filesystems are available for most all Real Time Operating Systems, and I imagine they’re also available seperately. When you configure these flash filesystems, you tell it the memory address of the flash, type of flash, etc etc.
Linux has the "jffs2" filesystem — a journaling flash filesystem, included in the kernel now.
Now, if you’re running normal operating systems off of CompactFlash (or similar media), you’re in danger mode. Non-embedded Windows is really dangerous. Linux and Embedded Windows variants will let you turn off all swap files and control the processes running on the flash, but you’ve still got to make sure that there’s nothing on the disk that can wear out the flash in the operational time that you’ve got planned for the device.
The first thing I thought when I saw the Super-Fetch(tm) demo was "won’t that wear out the USB drive more quickly?"
If you can get past the idiots then this thread over at ars is related. http://episteme.arstechnica.com/groupee/forums/a/tpc/f/99609816/m/521006306731/r/620006706731#620006706731
You have to remember there’s two types of flash, NAND and NOR. StrataFlash is a NOR memory type, which looks more like RAM. It has usually 10k-100k erase cycles, is highly reliable, has fast read times, and erase times in the seconds. You rarely see people using NAND in anything over 1Gbit/chip. NOR is used for firmware and booting, say Pocket PC.
Flash drives use NAND, because it’s cheap and high-density. Those have 100k-1M erase cycles, fast read and write, except they’re sequential read, usually comes with bad blocks, and tends to flip bits by itself (bit error rates at more than 1%). Anything that uses NAND uses a controller and a bad-block reallocation algorithm. While you’re doing that, you might as well do wear leveling. NAND is used in CF, SD and all those bulk storage methods.
So USB drives basically always have wear leveling. If you assume, maybe a 5 MByte/sec transfer rate, you can easily show that it will take more than a year of waiting to wear out a USB memory drive.
Usually CompactFlash and similar media use simple file systems like FAT or FAT32. If you run a program which does not create any files in the current directory/drive then there is no danger.
These file systems have no notion of ‘last accessed’ or similar frequently modified fields, so the OS will not update the card if not really necessary…
Have you guys checked out http://www.u3.com/? Go figure :-)
PE-built OS running (read-only) on the first USB memory drive
+ a second USB memory drive for storing your data
= the answer
I just avoid all this and use a 12GB 2.5" HDD in a USB 2.0 enclosure. Total cost, about £25 from ebay (~$60). Faster transfer rates, loads more space, much less of a wearing out problem.
Also, XP will autorun a USB HDD, but not a USB removable drive, which is great because I set mine up to autorun a nice little menu program for running my USB apps.
And while we’re on the subject of flash wearing out, I once attempted to use an old compactflash card to transfer data from an old Windows 95 laptop to a modern XP machine.
The card worked fine in 95, it also worked fine in XP, but if XP formatted it, 95 could not see XP files, but could create it’s own, which would corrupt the entire drive as seen by XP. If 95 formatted it, it was seen as corrupt by XP. After a bit of investigating I found that 95 would report a bad media descriptor every time scandisk was run, even if it had just "fixed" it.
I then bought a new CF card which worked flawlessly…
People can, because more and more programmers are getting their act together and writing software which doesn’t write to "my documents" or spam the registry, and some people have started to compile it: http://portablefreeware.com/
I think it depends a lot on the type of program. I’ve found that USB sticks are very useful for storing service packs etc., and I will normally run those programs off the stick (rather than copying them to the hard drive first) since they use the hard drive to create any temp files. On the other hand, I wouldn’t want to run Word off one, mainly due to the speed.
While this is interesting to know, it doesn’t matter. Flash drives are cheap! If you get a year’s use out of your $25 flash stick, it was probably worth it.
Some USB memory drives can handle only 5-10 write cycles: http://www.mways.co.uk/rom_use_only_usb_key.html
Is there a noatime equivalent for windows?
My last flash drive gave up the Ghost after only two wash cycles in my shirt pocket.
Does Raymond know if the MBF increases if I change the setting to use cold water only?
Even with wear leveling, isn’t the map that implements the logical-to-physical mapping stored in the flash drive? And wouldn’t that need to be rewritten often? As often as anything else on the drive?
That’s sort of what BryanK is saying with "you still have at least one portion that changes fairly frequently. Maybe the FS code moves the FAT structure around?" Moving the FAT structure around still needs to write the FAT structure to the disk, in case the user yanked it out.
It *seems* that there will have to be one portion that changes very frequently.
I happened to be debugging some problems for a friend lately, and I happened to have Windows 2000 SP4, which he hadn’t installed yet, on my 512M keychain drive. (I also have WinXP SP2 on the same drive.)
Does that make me a geek?
adf: "Is there a noatime equivalent for windows?"
Yes. At a command prompt type:
fsutil behaviour set disablelastaccess 1
or modify
HKLMSYSTEMCurrentControlSetControlFileSystemNtfsDisableLastAccessUpdate
and voila, no "last accessed time" tomfoolery. (It’s not very flexible — either it’s on for all NTFS drives, or it’s off for all of them — but it’s better than nothing.)
Hmm, fsutil command eh, let’s see what it can do…
fsutil /?
It did give me some help (thanks), after first blaming me because it wasn’t aware of Microsoft’s conventions on asking for help.
I see some references to the flash file system in the MS-DOS 6.22 documentation.