Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

How to check the health status of a USB stick? How do I know that a USB is broken beyand repair, or repairable?

share|improve this question

migrated from Jan 9 '12 at 4:16

This question came from our site for system and network administrators.

Throw it away. Your invested time is more expensive than buying a new one. – mailq Jan 8 '12 at 23:29
I have to agree with @mailq. You can buy a decent 4 GB thumb drive for $2.00 these days. – iglvzx Jan 9 '12 at 6:24
@iglvzx Well the question does not tell, if it is a cheap one, or some +32Gb encrypting fast one... – varesa Jul 26 '12 at 15:34

There is no way to query a USB memory stick for SMART-like parameters; I'm not aware of any memory sticks which support doing so even via publicly-available proprietary software. The best you can do is to check that you can successfully read+write to the entire device using badblocks.

You want to specify one of the write tests, which will wipe all data on the stick; make a backup first.

Find the device by looking at dmesg after plugging in the USB stick; you'll see a device name (most likely sd_, ie sdc, sdd, etc.) and manufacturer information. Make sure you're using the proper device!

If the stick is formatted with a valid filesystem, you may have to unmount it first.

Example syntax, for a USB stick enumerated as /dev/sdz, outputting progress information, with a data-destructive write test and error log written to usbstick.log:

sudo badblocks -w -s -o usbstick.log /dev/sdz

You'll need to repartition and reformat the stick afterwards, assuming it passes; this test will wipe everything on the stick. Any failures indicate a failure of the device's memory controller, or it has run out of spare blocks to remap failed blocks. In that case, no area of the device can be trusted.

share|improve this answer
badblocks is probably the best option. the comments that say "not worth it" completely miss several cases when this can be very needed (for example, a company might have purchased merchandise flashdrives, and would like to see how badly they got scammed...) – Richlv Jul 25 '12 at 17:18
as pointed out in the wikipedia article linked, there's also e2fsck -c that uses badblocks and effectively hides those badblocks from the filesystem, thus avoiding corrupted writes. It should be noted however that, if the disk got new badblocks it's probably getting damaged and new ones may arrise later, meaning its life is shortening and you should consider replacing it. – igorsantos07 Aug 13 '14 at 4:19
I suggest adding the -v flag as well do see the error in the terminal windows. (if you let it run over night for example. The logfile is not that helpful for a quick view how bad it is. – Tilo Dec 17 '14 at 15:49
@BeeDee, should we use whole device or just some partition or it does not matter? I mean /dev/sdz or /dev/sdz1? – Pisek Feb 13 '15 at 8:45
@Pisek you ought to use whole device, because it is the device failing, not just a partition. – Hi-Angel Apr 5 '15 at 22:03

It depends on the failure mode, I suppose. They're cheap for a reason.

As a USB device, watching the bus via device manager in Windows or the output of dmesg in Linux will tell you if the device is even recognized as being plugged in. If it isn't, then either the controller on board or the physical connections are broken.

If the device is recognized as being plugged in, but doesn't get identified as a disk controller (and I don't know how that could happen, but...) then the controller is shot.

If it's recognized as a disk drive, but you can't mount it, you might be able to repair it via fdisk and rewrite the partition table, then make another filesystem.

If you're looking for the equivalent of S.M.A.R.T., then you won't find it. Thumbdrive controllers are cheap. They're commodity storage, and not meant to have the normal failsafes and intelligence that modern drives have.

share|improve this answer

Via [ubuntu] Error Check USB Flash Drive, I eventually found this, which could be helpful:

I arrived at the blogs Fight Flash Fraud and SOSFakeFlash, which recomend the software H2testw (see here or here) to test flash memories. I downloaded H2testw and found two issues with it: (1) it is for Windows only, and (2) it is not open source. However, its author was kind enough to include a text file that explains what it does; this page is about my GPLv3 implementation of that algorithm.
My implementation is simple and reliable, and I don't know exactly how F3 compares to H2testw since I've never run H2testw. I call my implementation F3, what is short for Fight Flash Fraud, or Fight Fake Flash.

Addendum by @pbhj: F3 is in the Ubuntu repos. It has two part, f3write writes 1GB files to the device and f3read attempts to read them afterwards. This way capacity and ability to write and effectively read data are tested.

share|improve this answer
Is there any advantage to F3 over badblocks? – Zaz Jul 15 '14 at 13:41
@Zaz As best as I understand it, badblocks isn't designed for detecting fake flash drives and may not report any errors for them. – bmaupin Aug 28 '15 at 19:50

USB drives are pretty rudimentary, there's not a lot that can go wrong on them! Generally, if it shows up as a drive and you can format it then it works. You could try having a look at the Portable version of CrystalDiskInfo as that's a quick lightweight analysing tool. Very few USB sticks report back S.M.A.R.T. info and the like though.

share|improve this answer
For reference, here's the Crystal Disk Info manual in English: – Matt Simmons Jan 8 '12 at 23:34

Many failures are either complete or allow one location to support multiple locations. I wrote a little random write read program that uses a prime number for a pseudo-random number generator, for both patterns and addresses. The reads are staggered behind the writes by enough pages to ensure I am not testing ram cache on the system. It is not yet parameterized, just set up for a 64G device on my system with 8G ram. Feel free to criticize, parameterize, make it smarter.

This is a powerful check and faster than doing every byte bottom to top, but is also a great swap generator (rolls almost everything else out). I put swapiness at 1 temporarily and it became slower but more tolerable to other apps. Any tips on how to tune against swapout would also be appreciated:

$ sudo ksh -c 'echo 1 > /proc/sys/vm/swappiness'

$ cat mysrc/test64g.c

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>

int main( int argc, char **argv ){

        long long int mask = 0xFFFFFFFF8L ;    // 64Gb word
        long long int stag = 8413257 ;  // 8G / 1021
        long long int inc = 1021L ;     // prime < 1024

        long long int w_addr = 0L ;
        long long int r_addr = 0L ;
        long long int w_ct = 0L ;
        long long int r_ct = 0L ;
        long long int w_patt = 0xFEDCBA9876543210L ;
        long long int r_patt = 0xFEDCBA9876543210L ;
        long long int r_buf ;
        int fd, ret ;

        if ( argc < 2
          || argv[1] == NULL
          || 0 > ( fd = open( argv[1], O_RDWR ))){
                printf( "Fatal: Cannot open file $1 for RW.\n" );
                exit( 1 );

        while ( 1 ){
                if ( (off_t)-1 == lseek( fd, w_addr & mask, SEEK_SET )){
                        printf( "Seek to %llX\n", w_addr & mask );
                        perror( "Fatal: Seek failed" );
                        exit( 2 );

                if ( 8 != ( ret = write( fd, (void*)&w_patt, 8 ))){
                        printf( "Seek to %llX\n", w_addr & mask );
                        perror( "Fatal: Write failed" );
                        exit( 3 );

                w_ct++ ;
                w_addr += inc ;
                w_patt += inc ;

                if ( ( w_ct - r_ct ) < stag ){
                        continue ;

                if ( (off_t)-1 == lseek( fd, r_addr & mask, SEEK_SET )){
                        printf( "Seek to %llX\n", r_addr & mask );
                        perror( "Fatal: Seek failed" );
                        exit( 4 );

                if ( 8 != ( ret = read( fd, (void*)&r_buf, 8 ))){
                        printf( "Seek to %llX\n", w_addr & mask );
                        perror( "Fatal: Read failed" );
                        exit( 5 );

                if ( ( ++r_ct & 0XFFFFF ) == 0 ){
                        printf( "Completed %lld writes, %lld reads.\n", w_ct, r_ct );

                if ( r_buf != r_patt ){
                        printf( "Data miscompare on read # %lld at address %llX:\nWas: %llX\nS/B: %llX\n\n", r_ct, r_addr & mask, r_buf, r_patt );

                r_addr += inc ;
                r_patt += inc ;
share|improve this answer
Using a inc of a power of 2 like 1024 would allow better checking or dead high address bits, although only checking 8 bytes per hop. – David Pickett Aug 14 '15 at 20:02
yeah, this will miss the case of dead high bits. also doing reads and writes in the same pass can miss that, – user313114 Nov 25 '15 at 20:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .