Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Media Data Storage

Low-Level Format For a USB Flash Drive? 252

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?
This discussion has been archived. No new comments can be posted.

Low-Level Format For a USB Flash Drive?

Comments Filter:
  • by RhapsodyGuru ( 1250396 ) on Friday May 28, 2010 @09:01PM (#32385072)

    DBAN still does the trick. I use it on all my hard disks, thumb drives and memory cards.

  • GNU Shred? (Score:4, Interesting)

    by Jim Hall ( 2985 ) on Friday May 28, 2010 @09:12PM (#32385150) Homepage

    "... 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 [gnu.org] 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.

  • The real answer (Score:5, Interesting)

    by Burz ( 138833 ) on Friday May 28, 2010 @10:06PM (#32385534) Homepage Journal

    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.

  • by Anonymous Coward on Friday May 28, 2010 @10:21PM (#32385628)

    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.

  • by ChipMonk ( 711367 ) on Friday May 28, 2010 @10:21PM (#32385642) Journal
    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:

    #badblocks -w -s device-path

    Use the entire device, e.g. /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.

    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.
  • by Anonymous Coward on Friday May 28, 2010 @11:12PM (#32385954)

    add &threshold=-1 to any thread in url bar

  • Re:Ridiculous (Score:3, Interesting)

    by Cylix ( 55374 ) on Friday May 28, 2010 @11:53PM (#32386224) Homepage Journal

    On a positive note they try tremendously hard to save their awful reputation. At least, they troll newegg a lot and try to encourage customers to contact support.

    It always seemed like a red flag to me.

    Just think... one horribly cheap SD card has forced thousands of individuals to waste some previous bits of their time. The total combined value of those wasted hours would have bought hundreds of SD drives.

  • Re:Low-Level Format (Score:5, Interesting)

    by romiz ( 757548 ) on Saturday May 29, 2010 @01:28AM (#32386670)
    You're wrong.

    There is definitely a special 'erase' command for SD-cards. See page 33 for the simplified specification [sdcard.org]. 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.

  • Re:dd of course (Score:3, Interesting)

    by Piranhaa ( 672441 ) on Saturday May 29, 2010 @11:40PM (#32394324)

    Yes, but you really need to understand how NAND flash works, because filling your drive up with zeros in dd is very bad for performance. If you write 'zeros' to the entire drive, you're going to get terrible performance afterwards when writing ANTYHING to the drive. It's the same thing that plagues SSDs after using them for a short while. Read up on why we need TRIM.

    This is because flash memory's default state is a one. To change a single cell to a 'one', an entire block of cells need to be changed to a 'one' first (which takes a long time in the eyes of flash memory speeds) and explains why an SSD's performance suffers greatly after a long period of use. A single cell can be changed to a zero without this long wait, that clearly shows it's better to write 'ones' from the beginning. This is a currently limitation of MLC memories.

    This is just a very, very simple explanation of how it works. I suggest reading one of the in depth articles off anandtech or xbitlabs (I can't remember which one had it).

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Working...