Slashdot Mirror
Low-Level Format For a USB Flash Drive?
Luyseyal writes "I unwittingly bought one of these terrible flash cards at Fry's and have managed to nuke two of them, successively. I have a USB flash card reader that will read/write the current one at USB 1.0 speed, but it locks up every Ubuntu and XP machine I've come across in high-speed access mode. I have read that if I low-level format it that it could be fixed, though my current one doesn't support it. My Google-fu must be weak because I cannot seem to find a USB flash reader that specifies that it will do low-level formatting." Can anyone offer advice for resurrecting such drives?
"... but it locks up every Ubuntu and XP machine I've come across in high-speed access mode. I have read that if I low-level format it that it could be fixed, though my current one doesn't support it. My Google-fu must be weak because I cannot seem to find a USB flash reader that specifies that it will do low-level formatting."
I wonder if GNU Shred would be something to try, at the device level? Let's say your flash drive shows up as /dev/sdc, then you'd do this:
shred -v -n 1 /dev/sdc
(You might even try -n 3.) I think this would work, but I don't know what wear leveling would do when shredding a USB flash drive.
Once you run shred, you'll have wiped the entire flash drive. That means you'll need to repartition the device and lay down a new filesystem.
Might work.
If speed is a factor, then none of the answers I read above apply to your issue.
Your el cheapo flash card has a temperature-sensitive hardware defect which probably turned into an inability to read at hi-speed when the unit heated up to a certain temp and caused some poorly-made part of the chips to act flakey or broken. At USB 1.x speeds, the flash unit remains cool so access to it remains OK. Consider returning that flash card.
Of course, there is another possible explanation: Your particular flash reader device has an incompatibility with your flash cards (possible but not likely). You could try different readers if you haven't already.
I used to do on site computer repair for a few big companies (Dell, IBM being the biggest two, plus others) and we replaced hard drives frequently. Every brand. I think hard drives brands are computer geeks full moons. Ask an ER doc or cop if things get crazy on a full moon and the answer is often "Yes", even though objective research shows there's no such correlation. Sure, some brands are a bit worse than others, but for the most part that only rally matters if you're dealing with a huge number of them. Some home users will see failures regardless of brand, and others will not, again, regardless of brand. It's just a crap shoot when you're dealing with just a few drives at a time.
And I do mean one time, but three years later I'm still using the thumb drive. The following assumes a Linux environment. First, pull off any data you can (and want to), then unmount it and type:
/dev/sdg, not /dev/sdg1. This guarantees that all the Flash blocks on the chip are reset. The patterns 0xAA, 0x55, 0xFF, and 0x00 are written, then checked; "shred" does no checking, and doesn't report errors. The "-s" is to show continuous progress.
#badblocks -w -s device-path
Use the entire device, e.g.
If you get any errors (and you probably will, if the device is as weak as you say), simply re-run the "badblocks" command, and note if the error count goes down. The one time I did this, I got a few errors (less than 10) the first time, but zero the second time. Whatever badblocks caused on the low level of the device, it was just what the doctor ordered. I hope it can help you, too.
There is definitely a special 'erase' command for SD-cards. See page 33 for the simplified specification. The problem is that unless you have direct access to the SD controller - perhaps on a mobile phone like the N900, the USB mass storage abstraction hides completely this feature. Formatting using this command is usually very fast compared to writing to all existing blocks.
The reason for that is that the card uses a translation layer to mask the physical deficiencies of the flash memory. Bad blocks in NAND flash are even a bigger problem than on a magnetic disk, but using an error-correction mechanism implemented with a Hamming code and 'spare bits' for each block, the translation layer hides all of this to the user, presenting a 'perfect' storage area. If you send an erase command, the translation layer only needs to take care of bad blocks and clear all others, instead of trying to write 'formatting' data it does not recognize.
In a way, this command is equivalent to the TRIM command for SSD drives: it is useful in the long term and improves performance, but not obviously missing in day-to-day use. But when SSD users pay a premium to use them in a very efficient way, the absence of consideration for performance of SD-Memory cards users led to the current situation, where the command exists but cannot be accessed easily.