Slashdot Mirror
How Does Flash Media Fail?
bhodge writes "Aside from the obvious 'it stops working' answer, how does flash media — such as USB, SD, and CF — fail? Unlike with traditional hard drive, where anyone who's worked with computers for a while knows what a drive failure looks like, I don't know anyone who has experienced such a failure with flash. I've haven't been able to find more than scant evidence of what such failures look like at the OS level. The one account I have found detailed using a small USB drive for /var/log storage; it failed very quickly, and then utterly (0 byte unformatted device), after five years of service in the role. This runs contrary to other anecdotal claims that you should still be able to read the media after you can no longer write to it. So my question is: what have you seen of the nature of flash media failure, if anything?"
It usually "fails" because it went through the washing machine in my pants too many times.
The next Cmdr Taco duplicate will be ready soon, but subscribers can beat the rush and see it early!
Comment removed based on user account deletion
I have several boxes booting from flash. None failed yet (all less than 3 years).
I usually mount /var in the HDD array, if that's possible...
very carefully.
Don't make your problems my problems!
He'd taken it out of his camera, tried to put it back in, and nothin'. Slapped it into my Linux box. It "saw" that there was a device there, but wasn't real happy about it:
[ 5555.618324] sd 4:0:0:0: [sdb] Add. Sense: No additional sense information
[ 5558.777567] sd 4:0:0:0: [sdb] Sense Key : No Sense [current]
"It's dead, Jim."
I'm tempted to try the old hard-drive swaparoo: get the exact same SD card, unsolder the flash chips, and put the bad one's flash on the new one's circuitry. See if it's the circuitry that's bad, or the flash, itself. If anyone has any bright ideas on how to determine definitively which it is without me going through that exercise, I'm all ears.
From what I gather, the most common cause of failure is the flash getting fried. Dodgy card readers, pulling the card out when a voltage is running through it, the chips are very sensative to spikes in current or voltage and burn out because of it.
If a cell fails, you can't read or write that cell.
If a gate fails in a page, you lose access to the page.
If a gate fails in the overall control logic, you lose access to the whole device.
Is there something I'm missing? Did you think there were oil changes or brake shoes? It's one silicon chip with metal on it.
Intron: the portion of DNA which expresses nothing useful.
Had two finally wear out. Both started giving "could not write to device" sort of errors. The system (Windows 2K or XP) would still recognize the drive, would show the files, etc. Indeed, I could still access (read) the files, so the data was there and copyable. But I'd get a file write error every time I read anything, because Windows was trying to update the flash drive's file directory with "last accessed" or some such, and that write would fail.
No biggie; copied the data to a replacement, threw the old ones away, after hitting them several times with a hammer to "clear" the memory :-)
Flash media fails when you write the data. In theory this means that you can always recover data as you can never write data to bad sectors. In practice the entire media device (CF, SD, etc.) fails at once.
><));>
I gave up on my first flash drive after it took about 20 minutes to copy a mere 10Mb worth of data onto it. It's still readable, I just don't want to wait for it to find good sectors to write to.
Maybe I am totally on the wrong track here but don't the fact that they can't use Lead in some of the alloys contribute to the lifespan of some computer parts?
As I understand it aluminium alloys created without lead and then used in computers degenerate several magnitudes quicker than alloys with lead. The process is apparently that the aluminium start sprouting tiny tiny "hairs" and when one of these connects to another one of these coming from somewhere else in the machine then it's thank you and good night for that part.
Anyway the reason I mentioned this is because apparently with intensive use 5-7 years is how long parts in your computer takes to make a connection and after that it is LED OFF (see what I did there?) Of course unless you have a computer constructed before the mid nineties (I think that was the point); since they use lead in their alloys this isn't something that will affect them (though a range of other issues will).
The Long Now Foundation
Without knowing more about this specific situation, I'd say this failure sounds like it pre-dates wear leveling. Prior to wear leveling, the most used sectors were likely to fail the fastest. And what sector gets written to more than the file allocation table?
If the file allocation table was lost, that would explain why the device became completely inaccessible. The card might not be a total loss if the card contains firmware or circuitry to remove bad blocks from usage. In that case it might be possible to reformat it. (Of course, if it lacks wear leveling I wouldn't count on it.)
Wear leveling neatly solves this issue by shifting writes to different free blocks with every write. This assures that the maximum use of the card is obtained prior to failure. Should any given block fail the card will detect the checksum error, mark the block as bad, then attempt to rewrite to a different block. This is communicated back to the reader in a transparent way. As far as the reader knows, nothing happened.
As you can imagine, wear leveling makes it incredibly rare to see Flash failures these days. It can still happen, but the results are likely to be unpredictable. The card will need to chew through all free blocks before it starts returning errors. In that case you may be able to continue reading the media. Or it may fail like the USB drive you mentioned. It all depends on the importance of the block on which the erasure was attempted. Since you only know about a failure *after* the block erasure, you're at the mercy of the quality of the card's electronics and algorithms to protect against a dangerous erasure.
Javascript + Nintendo DSi = DSiCade
I've been booting linux servers off of flash for a few years. For some of them, the whole OS, even /var/log, is on the flash drive.
I've had one drive fail, and it basically got hot and stopped being recognized as being connected by the computer. It was older generation technology, though. Newer flash technology designed for computers doesn't fail, as far as I have experienced. I'm talking about the flash SATA drives from name-brand manufactures.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
I had a 4GB FAT32 flash drive that I used as storage for a mail server attached to an OpenWRT router. It required renaming and deleting files all the time (every time it got an e-mail)--so I think it wore down pretty quickly.
One day, the storage for the flash drive stopped working (from one hour to the next, without being touched, the computer acted like I had just yanked the drive out)--it would be recognized but report a "no media in drive" error when you tried to access it, like an empty CD drive. In fact I think Windows would say "Insert CD" or "No disc in drive F"
Is it possible the first part the OS looks at, with the index of everything on the drive has failed and shows nothing when in fact the data is there. Not unlike a dual booting Windows overwriting a previous Linux MBR and "forgetting" to add the already installed Linux to the list of boot options. Linux is still there although there is nothing in the first part pointing to it. I dunno how flash works at this level so it may be bullshit, but I thought I'd throw it out there; you never know.
A few weeks ago /. linked to a really wonderfully written article by Anand Lal Shimpi about SSD drives. In the article he includes some simple and clear explanations of how flash memory works, its lifespan, and how it handles writes and deletes to maximize the life of every block of storage.
http://www.anandtech.com/printarticle.aspx?i=3531
The only think missing from the article is a description of the behaviour of a failing drive.
If the flash drive fails, yes you can continue to read from it, but you also have to consider what is meant by reading.
You can always read the raw data from the device, that will never change. There is nothing that prevents the electrical signals from forming a proper read transaction on the IO pins of the flash IC chip.
However, when you consider the software that is on top of the raw data (a file system for example), this is where you will have the trouble.
With older CF cards, the concept of wear leveling was not implemented, I don't know about newer ones. This being the case, the directory structure for a file would more than likely reside in the same physical location on the flash. Opening, writing, closing a file with the same name would no doubt wear that space out as the directory entry gets hammered. Once that has "worn out", data is lost because the file system can no longer track it (even though the actual data may be viable).
Also consider the device that does support wear leveling. At some point it will run out of places to wear. Some large files will remain static and won't move (they are only read), some files will be moved all over the device by the device's ASIC as the data in the file is updated or changed. At some point, the flash will run out of cells. This could happen as some critical directory entry is being updated, and the whole file system could be corrupted because there are no more viable flash cells to use.
Your data might still be there is all its binary glory, but w/o a viable file system data structure to access it, well, you're toast. Unlike a harddrive that burped and lost a few bytes, a worn out flash drive has no recordable medium available to do any file system data structure repairs.
Kevin
I had flash failing on my 'gracefully'. The amount of available storage just becomes fewer and fewer after usage. It seems like the cells(if one can call it that) just dies after repetitive usage. Formatting does not help either.
The urban legend about being able to still read flash after it fails is just that, an urban legend.
I've had 3 flash devices fail: two USBs and one SD. None were readable after their failures. On one I could see the directory structure but none of the contents.
The first sector is the most important sector of a flash card as it has the filesystem and other information for the rest of the card. In other words this is where the addressing for the rest of the card is stored, where you write to to format it, etc. It also contains bad sector information about bad sectors in the rest of the card.
When this first sector fails, the card is useless.
When cards are guaranteed to be "written to 10000 times", it means that the first sector has that guarantee. Cards usually ship with some bad sectors, with the card formatted and the first sector having the details of the bad sectors.
I was under the impression that unless something disastrous happened to the media, such as enough physical force to break it or spikes in voltage (or flawed materials/workmanship) they were pretty much reliable indefinitely. I have a Simple CF card that's over 10 years old in regular use with no problems, and have read about a photographer who dropped his camera in deep water and a diver recovered it a year laterâ"the camera of course was useless but all the photos on the card were recovered and the card was still useable. I would imagine that the technology used for larger drives now would be able to withstand similar abuses.
Some years ago i used a 64Mb CF to install a minimal Debian on a IBM PC110 with 8Mb of ram. As the install process wanted more memory i created a 12Mb swap partition.
Big mistake.
The install took a whole day. I happily ran some programs the next day and crash - kernel screams of i/o errors in the swap partition.
Formated the card MS-DOS - it found a few bad sectors. Then i ran Norton Disk Doctor and at every run it was founding more and more bad sectors. But each time i was re-formating the card using a camera, the bad sectors were shifting around. Unusable.
FYI: IBM PC110 is a 486 Palmtop with a CF slot to be used as hard-drive. The CF interface is IDE.
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
The wear-leveling concept would certainly work to favor a long, normal operational lifetime punctuated by an epic fail.
I would expect corruption of blocks - some take the new values, others don't. There is also the concept of t he bad-block list which might work well enough to begin shrinking the available blocks, possibly to zero, as the one failure you mentioned described.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
I had one fail a couple months ago. It was pretty old (a few years at least, 256MB). I used it as an encrypted store for ssh keys and other things. I think the encryption is what wore it out so quickly (and maybe that it was older technology). It just started losing the partition table randomly. It still works for about 5 minutes at a time, though.
I'm Anonymous
I'm the real Anonymous
All you other Anonymous'
Are just Pseudonymous
Your flash memory is fine, the controller is hosed.
This kind of (essentially unrecoverable) failure will continue to be an issue wherever the logic is integrated with the storage.
If it's any consolation, except for those who are always forgetting to "eject" or turn off their device before removing the media this kind of failure should be quite rare*.
Enjoy.
*Mfr's producing shoddy products not withstanding.
Platform advocacy is like choosing a favorite severely developmentally disabled child.
On a modern filesystem, your writes should essentially be atomic and in theory it shouldn't be possible to leave the drive in an inconsistent state when the write fails.
Of course most camera memory cards end up being formatted with fat32 which can be a little less forgiving.
I found an old 10MB CF card tidying some boxes the other day. Plugged it in and it said device (or disk) not formatted.
As to how old it was, it came bundled with the Kodak DC120 I bought on promo when that model was superceded.
I wonder what was on it - at 10MB, probably not much!
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
So far I've only encountered sudden failures, where the whole medium becomes inaccessible at once, probably due to some mechanical failure, e.g. miniature cracks in traces or bad soldering points. SD cards are particularly flimsy devices which should not be subjected to bending stresses at all. Take a broken one apart if you don't believe me.
About 5-6 years ago, I decided that it would be a good idea to build a small application on a flash drive, that is, code and compile it directly to the drive. :)
After what must have been hitting compile a few hundred to a thousand times, the 128MB thumb drive starting giving me drive write errors and then stopped responding altogether within about a minute after errors starting appearing.
I think the moral of this story is backup your data, even when it's on a flash based drive, and don't code directly on a cheap thumb drive
I have a cheap 4GB SDHC card. I've used it only a few times to take photos. Sometimes if it's in my camera, the camera gives an error that there's no card in it. After removing it and putting it back, it works again. And if I put it in the card reader in my PC, same thing: Sometimes mounting it in Linux works, sometimes it doesn't and it's as if nothing is in it. Removing it from the reader and inserting it back may make it work again. Could this be due to bad copper contacts on the SD card?
I was given a 4GB SDHC card by a friend, frantic that all her photos had disappeared. She did not do anything do physically damage the card, it was sitting in her camera and just suddenly started showing 0 photos one day when she turned it on.
I popped it into my linux machine and started to dd all the data I could get off of it. The first 512MB were fine. The next 512MB were completely unreadable. The last 3GB were fine.
Not sure exactly what could cause this type of partial failure, but it certainly seems like SHDC cards are actually multiple devices internally connected together, and it's possible to have just one fail at a time. Alternate explanations are welcome.
(VirtualBox + XP + Kernel FAT NTFS did the trick by the way, was able to save 80% of the photos).
DJ kRYPT's Free MP3s!
...and quality and longevity take a back seat. So companies stopped offering SLC Flash RAM (+100.000 writes) and only offer MLC (5000 writes), and are now pushing even eight-level MLC, which will be even less reliable than standard 4-level MLC Flash RAM. But who cares, the consumer will be slightly fucked after a while, but that will be much later, after they enjoyed the happiness of getting slightly more GB for their buck.
The only manufacturer that I know of, that is an exception, if Kingston, which still offers SLC Flash products - namely their elite pro line of SD and CF cards, and the Data traveler USB drives. But that's it, everyone else has not completely transitioned to MLC.
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
I have never had a flash drive long enough to wear out the flash cells, and I can't say I have seen them fail electrically.
I have however gone through at least 5 usb keys over the last few years, all due to physical abuse:
-Laundry (went through at least twice without failing, 3rd time's the charm)
-Loose/worn USB contacts: at least two different drives, after that I stopped buying the cheapest ones available
-Soup: Spilled in my bike bag, and caused the usb key to corrode internally, and probably caused a short because I didn't notice the soup had leaked into the casing until after I plugged it in
-Clumsiness: I dropped one on a hard wood floor, and then rolled over it with my desk chair. Another one broke the USB contacts off when I tripped and banged it with my leg. At least that one left a nice bruise in self defense.
I would love to see a completely sealed usb key that uses something like the Apple laptop power cable connections (mag safe, I think it is called) for the connection. Perhaps if it had a titanium case and complete water-proof seal, it might survive my abuse for more than 3 months!
More Caffeine. NOW
ive been able to roll over a flashdrive with my car, wash, and bake a flashdrive in the process of doing laundry, and its never failed...however ive had one on my desk for a month that failed like a whale for no good (read:user abusing it as normal) reason. blaming gremlins, jeebus, and FSM until a solution abounds.
Good people go to bed earlier.
I've never had an old one fail yet (usually they are replaced with larger/faster drive before it fails) but I did have one defective drive. It had a problem with random data corruptions similar to what you see when a drive has bad sectors.
I have managed to wash and dry my flash drive numerous times and it still works. I make sure I have a backup of any important data on there of course, but I have been pretty impressed with how durable these flash drives have gotten.
For ~3 years now ive been using a swapfile on a 2GB Kingston micro-mmc card with my nokia tablet (only 64meg ram)
after running an 8Meg file as swap i got a scare maybe 6mo back when i was unable to write a new file to the card - I thought, I'd finally done it: id burned through my writability -
after some close inspection though, i'd just hit the FAT file-per-directory limit. oh -ho :P
Recently ive actually increased the file to 64Meg to swap out more stuff for gaming with large Roms.
Honestly Im amazed the card has lasted as long as it has - considering i thrash the system near-constantly - with my new usage patterns, i'd still estimate the card has another 2 healthy years of service.
When I was in the digital imaging kiosk business, we had to repair about three flash drives a week. A customer would put it in one of our systems and pull it out while it was being read, or it was a cheap drive or whatever. Either way, the customer would blame our systems for killing their drives (rightly or wrongly). Of course, it would contain pictures of their dead grandfather or ex-girlfriend naked or whatever was completely priceless and irreplaceable.
The vast majority of the time, we would be able to run an application that would be able to recover whatever was on the drive. While I'm not certain of the original problem, the system acted as if the drive had no FAT (File Allocation Table... do I really need to say it?) on it or the FAT had become corrupted. This particular application would be able to go in and recover whatever was on the drive and most of the time repair the drive to its previous working state.
I say it ACTED like the FAT was corrupt, but I don't know or care if a flash drive has a FAT on it. Could have been a hardware thingie in there that hiccuped. The repair utility acted much like a scan-disk that would repair an MBR or FAT and/or act like an undelete utility would, restoring the files on the drive.
There is no "I disagree" mod for a reason. Flamebait, Troll, and Overrated are not substitutes.
Because it's proprietary and sucks ass technically too.
In my linux product which runs off compaq flash I can tell you that:
You often see lots of garbage and complaining in dmesg.
The flash chip fails to overwrite files properly. So that when I overwrite the file and try and read it back I get garbage.
Often the flash chip seems to have successfully overwritten the files and you don't realize anything is wrong until you reboot.
And... They don't last anything like the number of writes they pretend to. If you put even a light write load on a flash chip for any extended duration (Few days, few weeks) it will blow up.
David
Most removable 'flash' media probably dies from ESD and wear of the connectors. I've never knowingly lost one, but from the destroyed ones brought to me, it looks like static or possibly 'hot insertion'. 'Flash' is ideal for static file systems like /usr or /, etc. I use an image of the memory on hd and simply do something like dd if=/dev/image of=/dev/flash bs=16k. Systems that use inodes (just about all) are best and MS file-systems that use FATs are the worst. Even if you must use FAT file-systems, copying a formatted image to hd with dd and using it (the hd) to manipulate data and then putting the _whole_ image back with dd will never wear out. (over 1.000.000 cycles possible)
So to make it simple: Read from the flash and write to it sequentially before power is removed. This is the Unix solution. I'm not that sure if Windows can do it. Also write times will be up to 100x faster, often greatly exceeding the rated speed which is based on the FAT that it comes pre-formatted with.
BillSF
For a prior employer, I had set up a process to qualify flash media for use in embedded products. There's a couple of different failure modes you are likely to see.
:-)
First off, when the actual flash media itself wears out, it takes longer and longer to erase individual sectors.
A flash device such as a USB stick or a CF card is slight more complicated because it has something known as an FTL (Flash Translation Layer). The FTL has the job of implementing the virtual media to flash sector translations, implementing wear leveling, and handling the awkward page erases. (Multiple sectors in a page, but you can only erase full pages.)
The FTL obviously must store some mapping information in the media in addition to your data.
If you start writing flash media, and time those writes, you see an initial rapid growth in the write timing that evetually levels off as the FTL tables swell to their constant operational size.
The over all flash write speed will level off to some average value that follows slow growth over a very very long tail as the media wears.
Early flash chips supported about 10,000 erases per page, and modern chips shipped by Samsung and others support a couple million erases per page. When you consider this is spread over say 4GB of media, you can understand that tail is very very long and flash media are probably comperable to hard drives in their MTBF these days.
Secondly, when flash actually does begin to fail, the media itself tends to exhibit a small number of different symptoms.
The flash may stat to show occasional data corruption when read. You might also have instances where data persists in the media only so long as power is applied. And then of course you have the fact that erases take longer and longer to achieve. Eventually erases or programming start timing out occasionaly.
With the FTL between you and the flash, you don't directly observe these effects. Presumably the FTL is smart enough to try and re-map your data elsewhere. In most cases there's ECC to attempt correction of moderately corrupted data. The real killers are when the data fails to persist after power cycling, when ECC fails to recover critical FTL data tables, or when there are no more spare sectors to re-map data too.
Those first two critical errors are likely to produce the lightbulb effect where your flash card or USB stick one day simply fails to come up when probed after device insertion. In more rare cases, the lack of spares may show up as some sort of reported write failure in your kernel logs assuming the flash device reports proper IDE/ATAPI/??? error data.
One final note -- please don't leave your USB stick inserted in the PC as you power it off! USB ports supply power and use a FET device to control that power. When you turn off the PC, the gates float and significant leakage current goes to the USB device. Some of the cheaper USB drives lack a key resistor that bleads this current away and protects the flash memory chips. This leads to data corruption. I have seen the FTL break in such sticks simply by doing POR on the PC.
Oh...almost forgot. When you put you flash stick through the washer and dryer, always use fabric softner or Bounce strips to reduce the static.
I have had 2 fail on me within the last year. The first was a Corsair Survivor http://www.corsair.com/products/survivor/default.aspx Was a pretty rough and tumble device but I guess it couldn't stand pottery dust. Within 4-5 months Windows nor Mac would recognize the drive. I kept a backup of it and called Corsair. They were very cool about it and asked that I return it. I sent it back and received a replacement for the drive within a few business days of them receiving it. I want to say that it was sent back to me via UPS Second Day. The drive itself wasn't handled to roughly so I have my doubts that it wasn't just a hardware problem from the start. Second one that is on its' way to failing is an Imation Clip Drive http://www.imation.com/en/Imation-Products/USB-Flash-Drives--Accessories/Clip-Flash-Drive/. It is intermitantly failing to transfer files. I ran a version of Portable Apps http://portableapps.com/ and am also starting to see the Imation have a few problems. I'll probably not get the clip flash again because dust and dirt gets into the rubber boot and falls into the USB sheeth.
I work in an environment that can get pretty dirty, http://www.hlchina.com/ But what should I expect from a pottery. On the positive side, i've had about 3-4 SD cards that I transfered over from my Palm Zire that are now being used in the wife's camera and they refuse to die.
It's too big to fail.
After only a year i had a 1g miniSD in my vx8100 slowly start having read/write failures. It acted just like it was having bad sectors that were expanding just like on a disc drive
In my business I handle a lot of SD, SDHC, and CF cards every week. First failure is very common, maybe universal, in SD cards: as it comes from the factory, the card works fine in digital cameras and readers attached to computers, but in a Windows Mobile PDA (all five different Dell and HP models I've tried), a small number of files in folders copied from Windows XP or Mac don't show up--the folder's there, but the file inside isn't. When I look at it on a reader on the original Windows XP or Mac OS X, the file is there and I can copy, open, etc. It's perfect. But no WM device can see that file. The problem seems to get worse the more the card is used. After formatting the SD card in the Windows Mobile PDA itself using a formatting utility, it works perfectly on all devices. Folks on forums have said that formatting it in a digital camera also prevents/fixes the problem. Reformatting it on Win XP or Mac doesn't help--same problem as when factory fresh. I don't know if other formats suffer from this--I now format every card in a PDA as soon as I get it to head off problems. Problem 2 comes up when someone yanks a card out of a card reader without following the computer's proper procedure for doing so. Some files can't be accessed, and sometimes the file and folder names are converted to gibberish. It's luck of the draw: 9 times out 10, there's no voltage flowing when you yank the card and you'll get away with it so maybe you'll think it's safe, but keep doing it and eventually you'll toast a card. To do it right on a Mac, drag the card to the trash, or select the card and enter command e, or Control Click on the card and choose "eject" or "safely remove" (I forget which). In Win, right click on the card and choose Eject. In Windows, if you've named the card, then when after choosing Eject the name of the drive changes from the correct name to "Removable Drive," it's safe to remove the card from the reader.
This is how it looks in linux: http://paste.ubuntu.com/127979/
IIRC that was the secondary SSD in an eeepc 900. Not sure what the windows variant of this would be.. BSOD?
We had a flash drive where I used to work a few years ago that for whatever reason(don't remember why any more), the plastic housing had broken off. We were able to use the unprotected chip as a working drive for at least another 3-4 months before it eventually decided it couldn't take any more abuse.
N/T.
But if you want a more detailed description, I'll acquiesce.
I've had 3 flash drives fail.
One failed because of cheap manufacture. The repeated use finally caused the solder to crack where the USB plug was mounted on the PCB. I was able to resurrect it with some careful soldering, but it eventually happened again, and I eventually wasn't able to get it working again. AFAIK, the actual device was fine, other than the loose plug. The body was made of cheap plastic, though, so it wasn't really a huge surprise.
The 2nd and 3rd flash drives that failed were a bit more of a disappointment. Apparently they had some sort of on-board firmware that got corrupted, because somehow they were totally bricked. The computer wouldn't even recognise that a device was plugged in. The blue LED would very briefly flicker when they were inserted, then nothing. I got the first one replaced under warranty, and when the same thing happened to the second one within a month, I basically said fuck this. I blame it on loose USB connectors in the lab computers I was using, but still - a loose connection shouldn't brick the device. Data corruption would be understandable, but the entire device dead? Not so much.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
most of them come formatted with patent encumbered FAT16/32 file system. Most users would never bother formatting to something else, and expect any device or computer in which they plug it to be able to use this filesystem. Want to change the file system and reformat? Ok, you may pick NTFS, which is probably worse of a patent risk and will also fasten the death of your flash drive... You may also choose exFat, but besides of being another patent risk, it will only work in two MS OS - the latest ones -
Not all is lost, you can go FLOSS and pick a file system from outside MS, of course, those will not work anywhere else outside of a FLOSS OS/Device.
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
I invested money in a cheap USB flash drive which, after I put data on it and plugged it into another computer, simply stopped working.
No machine could identify it anymore, formatting was impossible.
At least when I sent it to the shop where I bought it, they gave me a new one.
Surprisingly, the new device was manufactured by a well-known memory chip company and hasn't stopped working yet.
I use SD cards for distributing software to PDA's. I've gone through several hundred. In my experience they either become read only or unreadable. So far I haven't had any noticeable file corruption. We do wipe the cards before updating them with new data so it's possible there are dead areas on the card that the SD controller is finding and avoiding for us.
We use them more like rewritable CD's rather than hard drives though so ymmv.
I have a Philips DVD drive with a usb port, and was using a 1GB flash drive to play back video files copied from my PC. The drive failed relatively quickly - I'd had it for about a year, but hadn't used it all that often. I started to notice the video files were corrupt on playback, but initially suspected the file itself, or possibly a problem with the DVD player's decoder. I diagnosed the problem by copying a file onto the drive, then repeatedly checksumming it. The first couple of times, the checksum value would be often be correct, then on subsequent checks it would change on me. I'd end up seeing several different checksum values, never seeing it return to a previous value. Whether this was due to a problem in the interface harware when reading, or memory cells failing to retain their state, I don't know.
Even though it was a year old and I had no receipt, the manufacturer (Kingmax, I think?) was happy to send a free replacement. The new drive has seen much more use, but is still working fine.
I have a flash drive that started as 8 Gb and is now reduced to 4. The file system answers as 8, you can write as if it was 8, but all that goes after the 4Gb mark is later read as "noise" (yes, it was all audio files :o), instead of what you put in.
I'm still using it, up to 4Gb.
Rome taught me patience and assiduous application to detail. Virtues which temper the boldness of great, general views.
I too had a flash drive fail, but in the "worst" way... quietly.
Fortunately, the drive was mostly used for "sneaker net" use, and did not contain any irreplaceable data. This use exposed the issue quickly too (had it been a backup device, the backup would have been useless and I wouldn't know until I needed it.)
A typical failure was to zip up a software installation on a dev machine, then take it to a clean target machine, where the zip would fail to unpack, or the installer exe, once unpacked, would fail to run with various errors.
I finally got to the point where I simply copied several megabytes of plain text data to the memory key, then copied it back and diffed the files to see the corruption (large areas of nulls, as I recall.)
Never heard a peep from the OS.
It was a 1 1/2 year old Patriot XT 2GB, and, after a couple of emails and a PDF of my NewEgg receipt, a new drive showed up in the mail under the lifetime warranty.
I also had an expensive Lexar CF card for a digital SLR that failed. In that case pictures that I know I took simply weren't on the card... but could be "recovered" with the Lexar utility (along with EVERYTHING else on the card, so it was a PITA.) Since that was nearly $200 when it was new, I figured getting my lifetime warranty honored would be easy, since the cards were down to about $20. No dice. Just got the run-around and finally gave up. Lexar lost a customer.
This issue is a bit more complicated than you think.
Seriously. How do you 'test' for bad sectors? If you do a surface scan, it will read/write certain sectors. So you find sector 12345 is bad. You mark that sector as bad in the bad sector table and life goes on, right? Not necessarily. What if sector 12345 is now remapped to sector 23456 the next time you use it because of the hardware sector reallocation.
I hear everyone talk about how there's extra 'spare' memory pages for replacing the worn out ones. Let's say I have 5% extra blocks. How do you deal with these extra blocks? I see 2 ways...
1. All of the primary sectors are mapped physically and logically the same. As the physical pages wear out, the 'extra' pages are logically mapped in place of the physically bad ones.
2. The wear leveling mechanism remaps the physical and logical sectors through the useful life of the device. As various sectors reach their end of life, they are then remapped to the 'extra' sectors.
If #2 is the way it works, then performing any kind of 'surface' test is completely pointless. The device could remap the memory cells over and over. Through a series of surface scans you could theoretically mark every sector as bad because it's remapped every time you perform a read/write operation.
If #1 is the case, it would be very helpful if the device would tell you how many free pages you had left before writes are disabled. This would be analogous to the SMART feature of platter based media. Then we will be able to tell 'my drive has approximately 20 years left' or 'my drive has 20 minutes left! Yikes!'.
I am very interested to know which one manufacturers use, and i'm sure they all aren't the same.
We need tools to tell us what is really going in inside the SSD drives. We need software programs that find a bad sector to tell the hardware that the page of memory is actually bad and to remap accordingly. This would also signify the end of the 'bad sector table' for file systems as the issue is dealt with solely on the hardware level.
I've been using a cheapo SD card for a linux rootfs (embedded system) After some moderately heavy use blocks just got "stuck" so essentially after zerofilling the card, it still contained bits and pieces of the original data in random locations. No idea if it was wear or some kind of failure though.
I left one in my car on a hot sunny day without thinking about the consequences. When I went out and saw the device sitting on the front seat I was concerned. I took it in to my office and tested it. Windows didn't know what to do...
Linux said it was there, but could only read half of the files.
It will depend on a lot of different variables:
- disk manufacturer
- what O/S
- what application is accessing the disk
- what interface connects the disk
- how is the disk physically connected (what controller is the disk behind)
If you're using a SCSI/SAS device you might see any of these errors. The O/S might see an "adapter failure" or a "time out failure". In turn, the O/S would probably just tell your application that a read/write failed and hopefully log the failure somewhere.
Not with a bang, but with a whimper...
I've been running my home desktop/server (Linux 2.6) on a Sandisk Cruzer 8GB usb stick (root, swap, tmp, everything except large media files) for a year and four months without any glitches. I've napkin-calculated that at current usage and wear levelling, I should be able to use it for over 50 years without a failure. Funnily enough, the portable USB drive that I use to back it up failed last December. I keep multiple backups, I didn't flinch.
Then again some flash devices fail miserably and silently. I've had a few 64MB and 128MB stick batches with stuck bits, and those were practically new. The operating systems they were used on didn't detect the errors, I did, by trying to open garbled files.
My wish list: A SATA gizmo that has 4-5 USB connectors with each their own bus that presents itself to the SATA bus as a single drive, and does RAID-5 automatically. That'd be sweet.
on IRON file systems shows that you should definitely
be at least as worried about how the file system
handles (or doesn't handle) device failure.
http://www.cs.wisc.edu/wind/Publications/iron-sosp05.pdf
is packaging. There is stuff in the potting epoxy that holds enough electric charge to make the FET's gate start to conduct a little, playing havoc with everything. We've been having to redo parts with an extra layer of metal over the top of the IC to protect it from an intermittent contamination in our packaging material.
I believe I remember reading that Intel had problems with their water being mildly radioactive downstream of an old uranium mine, and running into the same problems (only much worse, since they're doing much finer geometry.)
So this is a case where the FET hasn't failed, precisely: it's just getting messed up by external interference.
Nostalgia's not what it used to be.
my experience has been that flash media often fails when vlad and/or reza and/or marticock farts near it
I recently had a couple MTRON Pro Flash SSD devices die on me. A power surge damaged two mirrored units, taking out a whole volume (a neighboring box on the same UPS circuit blew a Power Supply, the resulting power surge made quite a lot of damage).
The real problem was that both units appeared to be fine to the operating system, they would just stop responding if you tried to read data beyond a certain point. They would actually pass an fsck and mount properly as well, and you could list the files on the devices.
The only way to reliably trigger the error was to run surface analysis, which would read and write across the whole disk. One unit would stop responding after ten minutes, the other after an hour and a half.
This was on Solaris 10, with UFS file system.
Not with a bang, but with a whimper.
My first thumb drive just died. Plugged it into the computer and it was detected as a removable storage device with 0 bytes available. No idea what happened to it, and no warning ahead of time.
In it's defense, it went through the washer/dryer twice. Sigh. But it lasted a few months after the last washing.
The replacement I got for it was DOA, returned to Fry's. It's replacement was stolen. It's replacement is in my pocket now, got it last October.
So I've had 4 thumb drives. 1 died. 1 DOA. 1 stolen. 1 still working.
Commercially available memory media is NAND flash which is similar to NOR flash but has roughly a 2 to 1 size advantage. The basic issue with these types of non-volatile memories is that they have a limited number of writes that can take place to any given cell before they become erratic or non-functional. There are two types of NAND flash. SLC memories are good for ~100K cycles, while MLC memories are good for ~10K writes. MLC is what is typically used in commercial products, BTW. To minimize this particular problem, an integrated management controller is used with the physical memory for reasons that I'll explain a little later. This management controller does several very important tasks whenever the memory is accessed. First it performs error checking and control. If the controller detects an error in the data written, it flags the block of memory (in reserved space) so it will not be used in the future and rewrites the data to another block. This rerouting of the data is a second important function and is referred to as bad block management. Finally, the controller also performs a function known as read/write leveling. As you can imagine, if you continually write to the first block of available memory, it would quickly wear out, while the rest of the memory would be in tack. The read/write wear leveling "spreads the love" by writing data to various parts of the physical memory to ensure uniform wear. All this being said, the device, as it ages, would begin to exhibit a decrease in total capacity as the blocks were flagged as bad without a catastrophic failure to the entire device. Several other components may be the culprit for a total failure. If it's a jump drive, there is the USB driver chip and oscillator that could have failed. Jump drives, can even be washed as there is no voltage applied to the individual memory cells to maintain them (hence non-volatile) that would be damaged by short circuiting the PCB from the water. Just make sure that thing is completely dry before plugging it in!
How Does Flash Media Fail?
Catastrophically.
At least with hard drives you can often get the drive up and running long enough to pull the data off if you put it in the freezer overnight, or encase it in dry ice. Or, if it's a board problem, if you have another drive with the same firmware rev, swap the controller. Very worst case, you can send the drive to a recovery lab and get your data back.
Not so with flash. When it fails, the data is GONE.
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
So, I will pass on what I have discussed with my brother-in-law who is an Electrical Engineer that writes software to test flash memory:
1. Flash memory is built with additional fail over storage (so a 1GB SD card actually has a certain % more memory than 1GB).
When a section of memory fails it is marked bad by the flash controller and some of the fail over memory comes into service (marked bad much like failures on standard hard drives... although I get the impression the flash controller may be the thing remembering it's bad... wasn't clear on this now I have something else to ask him)
2. Flash memory will fail... it can only be written to so many times before it will no longer be able to be written to... and the number of times is definitely not as high as a standard hard drive
So it's likely that you can extend the life of a flash device by writing to it less often.
And, not from my brother-in-law discussions, I personally had a flash drive fail (I was using it as the master copy of documents as I moved data between my work machine and home machine while working toward an online degree). When it failed there was no warning previously. It simply stopped working... wouldn't be read and wouldn't write. I suspect my batch file that performed the backups to it must have written to it too many times (it was a smaller 128MB drive so, considering the above discussion about fail-over memory a smaller drive SHOULD fail faster...)
Hope that helps
Brilliantly!
I have an old flash device which becomes smaller every time I plug it in. It's old, I mean REALLY old. One of the first generation of flash devices, so the write times are awful, and the life expectancy isn't very good, but I still check it every once in a while.
It was originally 512 MB, but now it's dwindling somewhere around ~200 MB. Any write you make isn't particularly likely to fail, but some files might disappear as you put something new on it. Deleting files often delete whole folders, etc.
Hope that gives you an idea.
Hello, I think i have seen enought flash failure to tell you what happens, i've created a system using linux for embedded systems with a total of 12000 units, for 5 years, in this time we have changed about 20% of theses flashes. What happens is not a single event, here it goes. - The flash just stop working, you can't read, you can't write, you can't do anything - Some sectors of the flash stop working, it gets corrupted somehow - The read of some sectors start to show errors like normal hard disks - When the sectors start to reach 100.000 write cycles, it gets slow to read, and the entire flash starts getting slower and slower My Solution until now: Make a big partition for the writable data, and turn it into reiserfs, it naturaly cycles the writes on each sector and you will be able to recover some of the data when it crashes And dont forget to make the software unlink the node before writing to it, then it will be a brand new file each time.
...it seems to fail catastrophically.
The company I work for makes systems which use CF as a boot device.
I've yet to see a "partial" failure. It's usually all or nothing...During system upgrades we write new a boot kernel to the CF card and usually, I have found when that fails, the system will not boot either.
Goofy, Geeky Gifts and More!
I have a Kingston 2GB stick in a long-term overwrite test. The stick is first fully written with a random 1MB data block (repeated until full). Then the data is read and compared.
The first 2069 Cycles went without error. Then I had some bit-errors in one cycle. Then anothe 746 perfect cycles. But since then it takes between 5 and 50 cycles for more errors. The really bad thing is, however, that unlike a HDD, the flash seems to have no error-detection at all, it just delivers bad data on read. The Flash controller chip is ECC capable, but does not seem to use it (you cannot have single-bit errors with ECC -- either you get no errors or a lot more).
For me, this means that at least this stick is basically unusable for anything important. If I have to do a manual verify on each write, the usability is far too low. Also, the design is the stupidest possible. Error-detection id non-optional in data storage. I also find 2000 cycles (ot 2800) to frequent errors quite disappointing. I would at least have expected the advertised 10'000 cycles before data corruption starts.
There is a residual possibility, that something else is responsible, but the progression is indicative of Flash degradation and I have observerd no other errors on this system, which is a 24/7 fileserver.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
well, the physical reason why most flash drives fail is because of some sort of strong voltage spike, maybe a result of touching the electrodes w/o grounding yourself.
but most modern flash drives work by using quantum tunneling, which allows electrons to pass the junction as a wave. of course, some electrons get through by hot electron injection. after years of this wear, certain bits become damaged, and simply become closed circuits.
also, if there is a voltage spike, way too many of the electrons go through by hot electron and again, same thing.
I wonder how well that hammer thing worked.
It's beautifully effective for drives because they are high speed high precision mechanical devices, but even if you broke up the circuit board the chips were soldered to a guy with a soldering iron and some know how might still be able to get it back together again. Looking at that cell to gate progression posted earlier it sounds like unless you are able to actually destroy a given gate you don't destroy access to a give chip. If you were able to access the internals of the chip that might not be a barrier.
Too many electrons are easy to find though. Maybe get some rubber gloves, one of those hand held stun guns and zap the board parts a few times after (or before) you're finished hammering. It could be fun and sparkley. This also provides opportunity for some memorable conversations with management. " ...It's these SSDs boss. They're just really hard to erase when they fail. I'm afraid the department is going to need it's own Vandegraff generator..."
The blue smoke wants to be free.
Everyone knows that the mainstream flash media is so left wing that's going to fail.
I can't believe it. This is the first technically interesting Ask Slashdot I've seen in a very, very long time. It may be the first one I've ever seen that makes me wonder why they didn't just Ask Google or ask RTFM.
What if to construct a raid-flash-drive. Combining 2 flash-drives into one? If one drive is gone, blinking orange lamp goes on, instead of green? Data is written always on 2, like with a raid array.
I got a 16 GB Transcend SD memory card as expansion storage for my Aspire One netbook. I reformatted it for ext4 and put about 4 GB worth of music onto it. It worked fine for a couple of months, then just recently, especially today, I've been getting read errors and it's hiccuping on songs that used to play just fine. The weirdest one is that one track will actually jump to a completely different song from a different artist about a minute in. I'm playing stuff in mplayer which is extremely forgiving of read errors, but I shouldn't expect any errors.
Aside from reformatting to ext4, this card has had very little rewriting. I haven't filled it yet, and very little has ever been erased or rewritten. I don't know whether the weirdness should be attributed to the the cutting-edge ext4 file system or to the cheapo Transcend SD card. I'm leaning toward the latter, but I'm curious if anyone else has experienced this sort of thing.
KTHXBYE
My lab had a 256MB flash drive that got used intensively, passed from student to student for a few years... eventually it could no longer be written to, but we were able to read nearly everything on it.
Otoh, I have a 4GB drive, and it suffered data corruption recently, though I'm unsure if it was due to an OS error, the drive itself, or an improper disconnect.
There again; am I the only one who thought at first glance that Flash media fail because they are disabled by NoScript?
At some time I noticed that a small USB flash reported 8GB instead of 1GB. I only looked at the problem because of some corrupted files (files written into an inexistent adress space). Probably cause: a bad motherboard that died a week later.
I've had many flash drives over the years. currently I have a 1GB Kingston, 2GB Memorex and a 4GB Kingston. The 1 and 2 GB sticks seem a bit more stable, but the 4GB just drops off the volumes list quite frequently. More so when copying large files. I suspect it might be a power issue. But i havent looked into it too much :P
nigelt.wordpress.com
In their product web page they have an interesting section titled "Don't think you need FAT32?". In that paragraph they say that FAT32 is less susceptible to a single point of failure than FAT16 due to the use of a backup copy of critical data structures in the boot record. See their MMC/SD Memory Card FAT16/FAT32 Driver page.
I presume this is referring to the second copy of the FAT table. Do all OS's back up with a second FAT copy (or other data) to make the media more reliable.
Are there other steps an embedded application can take to make SD cards more reliable? e.g. read back after write, use checksums or CRCs in data files, use FEC (forward error correction), write two copies of files ...???
Is it better to use a non-FAT file system for reliability if PC compatibility isn't essential.
is decapitation. they might work one last time while you hold it to the port, but that's usually it.
0- Eamonman Proud member of DNRC
I had a 2GB SD card from my camera show up as empty when I put it into my card reader a few months back. I used the (free) utility that I found on Lifehacker to recover the 4-5 months worth of family pictures off the card. It worked great. The pics all had strange filenames and I had to sort based on the pictures metadata rather than the file creation date, but that's to be expected.
http://lifehacker.com/software/file-recovery/recover-a-borked-flash-drive-with-photo-rec-314963.php
To my dismay, this article had nothing to do with Adobe Flash technology. I had a written thesis waiting for such an event. You win this time Adobe, but I'll be back with in due time my friend, in due time.
I recently had a fibre channel router whose flash had gone bad. This is an embedded Linux system on PPC (Brocade 7500). Basically, the flash was showing a zero size device:
Booting "Fabric Operating System" image.
Blk map has an invalid version 0
Blk map has an invalid version 0
ThisOSLoader has an invalid magic number (0x00000000)
ThisOSLoader has an invalid magic number (0x00000000)
ATA()0x48047's entry point is too small (0x00000000 0x00100000)
OSLoader contains no bootable devices.
When I tried to reflash it after booting off the network, there wasn't any /dev/hda device there to format. Replacing the flash card solved the problem.
Unfortunately, the dead flash took with it any prior logs of errors it might have given before it failed, but it certainly wasn't readable after the fact.
- Necron69
Well is difficult to explain what a flash memory is (but there is a detailed explanation on wikipedia http://en.wikipedia.org/wiki/Flash_memory). To make a long thing short (and very approximative), a flash memory is a sort of "unconnected capacitor" (floating gate) the charge is changed using a quantum physics effects (not only), and is read due to the "interference" of the charge of this "capacitor" with a "nearby" transistor gate.
So the first thing you have to know is that the data on a new flash memory stays for a long time (10 years at least), but not forever, cause the capacitor discharge due to natural loss of carge.
Due to disk writing (changing the value of a cell) the charge is loss faster and faster so there will be a day that the charge of a cell will be completely loss after just a few hours or less.
The effect you may see depend mostly on the cell type (SLC or MLC) and cell allocation algorithm, but the first thing you'll see is random data corruption of recently updated datas; but, due to the cell allocation algorithms, faulty cells will be eventually assigned to updated fat data and the damage will propagate fast.
My sugestion is: replace a flash memory at the first signs of data corruption.
Cya
Unluckily Murphy was right.
And, basically, it was unspectacular. It simply became suddenly inert -- as if it had been unplugged. Except, after that you couldn't plug it into anything and have it work. I'm guessing that the memory on the device was probably just fine but the little IO PIC in the thing probably blew (it probably was marginal when I bought it, it just took a while to die).
There was no static/humidity/chemical issues, and I'm assuming that it wasn't a voltage spike since it was plugged into a hub attached to a UPS with AVR and nothing else was affected.
http://www.usenix.org/events/sec01/full_papers/gutmann/gutmann.pdf
The lack of privacy around flash is the main failure.
The lack of universal device support is the second failure.
Two cheap flash drive that failed on me seemed to be related to too many writes related the the directory / FAT table. I was doing a lot of saves and automatic document updates. After about two years it would have problems being recognized in any computer but the one I used it in and I just barely got it online long enough to get the data off. I tried formatting it but after writing one file to it the drive was no longer readable at all.
My assumption, without any tools to look at the bits on the silicon, is that one or more cells failed right when writing out the changes to the FAT tables. At that point, since cheap ones don't have any wear-leveling algorithms, it was toast. I even played with using some net coding examples that were supposed to go over the USB bus, under Linux, to try to use it as a raw device to find the dead cells. It did not work but I think that is my skill level at understanding the code examples, not that it would not work. The premise was that the code would allow it to be mapped out and then "reprogrammed" to drop out all the bad cells. Sounds good but if it worked reliably it would have been being sold, not on a badly coded web page.
The one time recently I've had Flash memory fail (an SD card in this case, FAT formatted) due to natural causes, i.e. other than ESD or hardware-development abuse, it grew a at least one defect which acted just as a HDD 'bad sector' would - with a catch: The communication between an SD card and the PC is essentially SCSI, and the card may (and should!) return an error flag in the SCSI packet if a read/write failed. My PC's Flash reader interprets such an error as a sign that it should crash outright. Maybe it is trying to re-read the sector infinitely many times until success, or maybe just throws in the towel altogether, but the upshot is that the card/reader goes catatonic on the first read error and must be recovered by plugcycling it. So 'chkdsk' or other tools which would mark off bad sectors at the filesystem level will not recover it as they perform a read-read or read-write-compare test and inadvertently crash the reader just before they could have fixed it.
Flash can handle a large, but limited number of erases, so bulk Flash media (SD, CF, etc.) use a wear-leveling system to ensure some physical sectors don't get written to much more frequently than others. A table of the logical sector numbers (as the OS sees them) points each number to a "randomly"-selected physical address, which is re-selected to another free sector on every write.
There are many other ways Flash can fail (e.g. page/column driver failures taking out large swaths, possibly GBytes of media at a time), but for single-sector failures, if you are able to write to the bad sector (without reading first, if your reader hangs up on reading one), the fault will appear to 'go away' since a fresh new physical sector was selected. But beware, the bad sector is still in the pool, so it WILL come back to bite you sometime in the future. If the bad sector can be marked off at the filesystem level, in theory nobody will ever attempt to write to it (thus changing the wear-leveled physical sector the logical 'disk' sector number points to), and it will remain safely excluded.
Some types of Flash media will attempt to mark sectors 'bad' at the device level and exclude them from the physical sector pool, but I would not rely on this.
Caveat Emptor is not a business model.
I did something similar for a senior project at the University of Utah that was sponsored by Micron. Our goal was to build a testing platform for NAND Flash memory, which would allow vendors to test the memory and analyse the failure characteristics. We never fully finished, but we did get a spot presenting at the 2008 FLASH Memory Summit.
Have had several SD cards fail in a custom board & 1 fail in a commercial product. In all cases, they got into some safe mode where they wouldn't accept write commands but would accept read commands. The problem may be static electricity, too many invalid write commands, or just flaky manufacturing.
Unfortunately, for whatever reason, it's really hard to find failures of SD cards on Google, or failures of any commercial product for that matter.
I work as an Electrical Engineer and I have a buddy who is a Technician. He has been in the business for 30 years. He told me that he used to work part time for a company that would recover data from dead flash drives. What they would do is take the broken flash drive, buy and identical model flash drive, (here is where my Tech buddy comes in) they would then take the actual flash memory from the faulty device and solder into place on the brand new flash drive. He said that this would allow the data to be recovered 9 out of 10 times. This means, of course, that when your flash drive fails, 9 out of 10 times (anecdotally) it is because the I/O portion of the drive or the connector has broken, not the actual flash memory. Basically, your data is still there, you just can't read it.
Anonymous Coward
I have seen a mis-wired front panel USB connection fry the controller chip on a USB stick. One of the sticks that I had seen damaged was a Micro SD flash reader. I pulled the Micro SD chip and plugged it into a new reader and was able to use it normally. When we took a closer look at the computer that was frying our sticks, we found that the connector from the front panel USB was reversed (+ to - and D-in to D-out) -k
mine, is weird, it started brining back the wrong parts of files, so you copy a file there, when you try to read it all you get is part of the file and part of another file on the drive. its been formated a couple of times now, and still does it.
I have a USB flash stick that has some strange sectors. They do NOT cause any I/O errors. However, different data results from reading those sectors. Even more strange is that I get different data based on what block size used to do the reading. For block sizes 512, 1024, 2048, 4096, and 8192, I get a certain data value on these sectors. If I use a block size of 16384 I get different data. And for all larger powers of 2 (I tried up to 1048576) there is another value. So I can get 3 possible data values from these sectors depending on what block size is used. As long as I use the same block size (one of 512/1024/2048/4096/8192 vs. 16384 vs. one of 32768/65536/131072/262144/524288/1048576) I get the same data. That is just so strange.
I'm guessing that internally, the flash is failing to read some sector, but goes ahead and transfers to the USB bus whatever data was left in the buffer. What was in the buffer depends on the size of the request.
What's annoying is that there is NO indication of an error. I discovered this only because 2 different programs that happen to do read() requests in different sizes got different data. These programs were bzip2 and gzip. So then I ran tests to see why.
I bought a brand new 8GB flash key last night. It did exactly the same thing. I then write over it and now it does not do this anymore. I am guessing that there is some kind of rotation of blocks (of some size maybe around 16384 bytes) that are the unit of erasure, as part of the wear leveling, that has left the bad sector currently in the unused pool. I hope it has been detected as bad and flagged unusable. I worry that it may come back sometime as more data is written in the future. Now I need to do read-back verification of any critical data I write.
This has happened with 2 different 8GB sticks and 1 16GB stick from SanDisk. I did not get to test this with smaller ones I previously had, and have given them away so I no longer have them. I'm not going to buy more smaller ones just to carry out these tests. I also use SDHC memory cards, but have not tested those, yet. I plan to get a 16GB SDHC card soon, and I will run these tests on the factory data recorded on them at that time and see if SD cards have the same issue.
I'm hoping it's just some glitch in the way the factory initializes the flash. Maybe they initialize it while its still a chip and not using the USB interface, and don't actually run the wear leveling logic during that initialization (which may even be loading the wear leveling firmware at the same time, so in that case it can't use that logic, yet). As soon as I can get hold of someone at SanDisk that is technical enough, maybe I can find out what the issue is.
So in summary, maybe this is a bad flash, and maybe not. But something is not giving an I/O error when I think it should. So there may be a risk that flash devices could fail without proper error indications.
now we need to go OSS in diesel cars
My drive started not showing any partitions in Linux and /dev/sdb gave errors. In Windows the driver said 'insert media'. I presume the USB controller lost its connection to the flash chip or something, weirdness
Had a 64 mb flash ur-disk flash drive fail about 4 years ago. Totally unreadable, no trips thru the washer. Was used for daily file backups for a couple years. Save your data in many places you must.
I work at a computer retail store and I asked one of our Techs this question. He did not know so he called a SSD manufacturer and their answer was this. If you are using the computer and the drive fails the screen will just go black, and all will be lost.
When my 1yr2 old 4GB 266x CF (not cheap when I bought it) died I figured I was SOL. But, with one request for service they sent me an RMA # and I had a new one within a few weeks. I will definitely not feel the need to purchase SanDisk or Kingston for trustworthiness anymore.
Even though Lexar seems like a big name, they always felt a little sketchy to me. Maybe I associate them with Lexmark or Lex Luthor.
The only stable state is the one in which all men are equal before the
In my case, a MicroSD 2GB flash media file, that had been in my phone and worked for a while, just stopped working period, to the point where the phone reported that it simply didn't exist. I though the phone was broken.
Nope. Popped into a known good MicroSD adapter and that into a known good multiformat flash reader, it's as if the thing simply does not exist whatsoever. An identical MicroSD card bought at the same time and installed in my Garmin GPS works fine, in the GPS, in the adapter and via the reader. I put it in my phone, and the phone saw it, although because it's full of GPS data and maps, I made no attempt to actually use it with the phone.
Died, plain and simple. Not even heavy enough to be used as a boat anchor so it's a truly useless thing.
Linux, otoh, doesn't need eject. Just umount the thing, and sync if you're paranoid.
Actually, eject is still useful in GNU/Linux.
Eject USB devices in GNU/Linux with the same old /usr/bin/eject command used for CD-ROM drives (internally, the ioctl is still named CDROMEJECT) (GUI users will probably have an 'eject' entry in a right-click menu somewhere).
A friend of mine had a 8Gb memory stick that went bad when we tried copying several hundred photos on it. With the first batch, it seemed to have multiple files with the exact same name in the same directory, which I believe shouldn't be possible. Each one had the same thumbnail too, and I'm pretty sure each could be opened normally. On the other hand, some of the photos we tried copying on it just weren't there. For some reason, we still tried with the second batch of photos. This time as well, many photos simply didn't show up on the stick after being copied. There were also some very, well, odd files present: too small to be photos and with file names consisting only of a few letters (with no extensions).
I just had this happen to me!
I didn't know what was going on, but I typically keep a lot of small text files open in JEdit. Fortunately JEdit checks the status of files when it gets focus again - and this started when a couple dozen files "changed on disk" though I hadn't done anything. I didn't investigate at the time, but then it happened again early next week: a couple files I hadn't touches were reported "changed on disk". I looked and the directory was now empty! I still don't know what if anything else was affected the same way.
Further investigation showed that a couple directories reported 4-10GB of space used. While trying to copy over files to another drive another 4 directories failed such that the total reported file size on the 16GB flash drive was WAY over 20GB. I have screen shots if that helps any. Looking at those directories in Total Commander (Windows XP) shows dozens to hundreds of files with gibberish names and file sizes.
I tried using Nero 9's recovery tool, but it seems to only be made for people trying to recover a single file - I can't see how any programmer would consent to release such a shitty UI. I still haven't done a compare to see if Nero was able to recover anything more than a simple copy did. (besides hundreds of zero-size files)
AND I'm possibly out dozens of files I may never know about. Of course if I wasn't using JEdit I don't know how I'd be able to identify the problem at all. I don't feel like I can trust SDs anymore with critical data.
This was after trying to use the SD as my personal data drive in a laptop since last July. I wouldn't even call it heavy use - fortunately I kept my repositories on an HD instead of the SD card. But everything is backed up again...
8-PP
Had a SanDisk 8GB microSD in my N810 - used it as root/swap. After about 3 month it the root file system was corrupted: First fsck would find and correct errors, second fsck would say everything ok, reboot would show exact same errors in the exact same locations again.
It basically looked like a read-only device that would accept writes without complaining, but would loose that information on the next power-cycle.
Lost some (unimportant) data because I couldn't believe that the drive had gone bad so quickly. Send it in for warranty and got it replaced free of charge.
Also Linux/UNIX (OS X)/BSD gives (raises) "EIO" flag if filesystem senses an inconsistency.
I am giving an example from Windows since chkdsk is questionably best thing for their own format, just to give the idea of old fashion.
Every month, on Flash drives carrying meaningful, non reproducable data (e.g. personal data, not downloads), I suggest running chkdsk /f /r (drive letter). It is very fast and cheap way of learning issues before they happen. As it is not magnetic data/moving parts, I wouldn't keep using it if there is 1 byte of "bad block". As OS X user, I don't have stock command to bad sector check foreign filesystems (in fact, even its own) so I don't know the Linux commands.
We have to get old fashion on USB/Firewire drives too as we (and the OS we run) can't pull the SMART data from them.
The warning about not powering your PC off with a USB stick inside might well be true but I've not heard anything concrete about it elsewhere.
A few days ago I did this - powered down a desktop PC with a uSB stick attached (I was too lazy to safely remove the stick first). A day later I put the USB stick in another machine and it was completely empty - zeros as far as the hexdump could see (including the partition table)...
Now it could be unhappy coincidence but it seem awfully fishy that these two events would happen so close to each other so if I guess anecdotally I will start advising people to pull USB sticks before powering off PCs wherever possible.
I miswired the usb ports on my motherboard to my case and fried a few flash drives. Anybody else brave enough to admit that on Slashdot?
The filesystem relies on the device sector writes to be atomic, which generally is not the case for flash media. Therefore consistency cannot be guaranteed for ANY filesystem.
I bought a 512 meg Verbatim flash drive. After a lot of use copying data back and forth to work each day, it failed on me. It would get write errors copying data to it. Since I needed it to copy data back and forth, no write = no use. I'm unsure if I could have read the data off it as I deleted the data and copied new stuff to it. I didn't lose data because of it. That's the only failure I've had out of 20 flash drives. Most age out due to size long before they wear out. A 128 meg drive is useless now, even if it works.
I had a Sandisk Cruzer mini USB stick fail on me without warning. I recall working in one environment where static discharge was an issue. While I grounded myself before inserting drives, this may have contributed to the drives failure.
When the device failed, Windows would not recognize the file system on it but it still recognized the drive. Windows Explorer would just hang when accessing the drive. Windows drive manager would claim that the drive was unformated.
I ran a few file recovery apps (GetbackFAT, Encase) and one of them could read the files, but I never registered and recovered the data. I tried the drive on Linux and OS X; those operating systems also had trouble reading the FAT32 file system, but they did see the hardware (without hanging the operating system). I believe it was probably a corrupt file allocation table in the end that caused the failure of the drive. Also note that Spinrite was unable to recover the files.
I ended up reformating the drive and thus far the USB stick is working again. I try not to leave anything important on it in case the hardware failes again.
You've never seen a problematic flash drive? Try cheap chinese made models.
If you try reading message boards from poor countries where cheapo flash drives are really common, you'll find a lot of complaints.
From their FAQ:
Sorry, I had to laugh a bit there. That's VERY naive. In anonymizing networks, HTTPS is the only thing that protects you from possibly corrupt exit nodes by encrypting the traffic between your browser and the destination webserver. To claim I2P doesn't need HTTPS support is misleading or at least ill-phrased.