How to check the physical health of a USB stick in Linux?
How to check the health status of a USB stick? How do I know that a USB is broken beyond repair, or repairable?
7 Answers 7
There is no way to query a USB memory stick for SMART-like parameters; I’m not aware of any memory sticks that 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 , e.g., 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 (with the umount command).
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.
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. )
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.
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.
I suggest adding time in front of the command to see how long it takes in order to calibrate one’s self to how long this takes. Ex: time sudo badblocks -w -s -o usbstick.log /dev/sdz . Note: for me on a 16 GiB USB 3.0 flash drive it took a couple hrs I think (I forgot to use time :(, so I’m guessing here).
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.
I see some advantages for a typical user: (1) it detects (quickly) a fake flash, which as @bmaupin mentioned badblocks can’t do reliably (nor quickly), and is able to «fix» a fake flash, (2) to check full drive health, it is comparable to badblocks, but it doesn’t require root privileges and it gives a slightly more nuanced output, (3) if you don’t need to check all sectors, you don’t have to completely erase and reformat the drive.
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.
Along the way to today, this thread raised some questions.
—How long will this take (implied by discussion of letting it run overnight).
I’m currently testing a USB 3.0 128G Sandisk using sudo badblocks -w -s -o , it is connected to my USB 3/USBC PCIe card in an older Athlon 64×2. So, USB3 into USB3 on PCIe should be quite fast.
Here is my console command line at 33% completion:
Testing with pattern 0xaa: 33.35% done, 49:47 elapsed. (0/0/0 errors)
Testing with pattern 0xaa: 54.10% done, 1:17:04 elapsed. (0/0/0 errors)
Reading and comparing: 43.42% done, 2:23:44 elapsed. (0/0/0 errors)
This process repeats with oxaa, then 0x55, 0xff, and finally 0x00.
ArchLinux gave an unqualified statement:
For some devices this will take a couple of days to complete.
N.B.: The testing was started about 8:30 p.m., testing had completed before 8:45 a.m. the next day, completing in about 12 hours for my situation.
—Destructive testing isn’t the only method possible.
Wikipedia offered this statement:
badblocks -nvs /dev/sdb This would check the drive «sdb» in non-destructive read-write mode and display progress by writing out the block numbers as they are checked.
My current distro man page confirms the -n is nondestructive.
-n Use non-destructive read-write mode. By default only a non- destructive read-only test is done.
And finally that it isn’t worth it. statement.
A summarizing statement, based on the situation of billions of memory sites in a flash chip, a failure is a cell that has already been written and erased tens of thousands of times, and is now failing. And when one test shows a cell has failed, remember that each file you added and erased is running up those cycles.
The idea here is that when 1 cell fails, many more cells are also reaching the same failure point. One cell failed today, but you use it normally for a while longer, then 3 more cells fail, then 24 more fail, then 183, and before you know it, the memory array is riddled with bad spots. There are only so many cells that can die before your usable capacity begins to fall, eventually falling rapidly. How will you know more cells are failing? So, posts here are guarding your data by saying once you have a bad cell, you are pretty much done in regards trustworthy storage. Your usage might still give you a few months.
Introduction
Anytime you store data on hard drives, CDs, or usb drives there is a possibility that something could happen to that device causing you to lose data. Two problems that may occur : your files may become lost — a corrupt index meaning that all the pieces of the files are so muddled up they no longer make any sense — or the storage media may develop defects — bad blocks on hard disks or scratched CDs. Tools exist to detect and repair errors. We will present these tools to you now.
Checking Filesystems
Errors may occur in the data stored on a disk. This may be due for example to power failures, system crashes or impetuous removal of media. When this happens, files may become lost or corrupt — you will need to check your data for validity.
The tools used to check your data depend on your filesystem, please refer to the appropriate section.
Finding out what filesystem is on the drive
Gparted is an easy way of finding out the file system on the drive. If you would like to use the command line type:
Where /dev/sda1 is the partition you are looking to test/fix and then at the prompt type
That should tell you the filesystem. To quit type
ext3 and ext4
Hard Drive
To run a filesystem integrity check on an ext2 or ext3 partition the drive must be unmounted (Running fsck on a mounted drive is a very bad idea.). In the case of your hard drive you will need to force a fsck on next boot up. To do this you create a file called forcefsk in the root directory.
Removable Media
For removable media, like usb drive, first unmount the drive. To unmount just right-click the icon on your desktop and select ‘Unmount’ or ‘Eject’. From terminal, use ‘sudo umount /dev/yourdevice’. To get the right device use the ‘mount’ command to list all mounted devices. Then in a Terminal run:
FAT32 and FAT16
To check and repair MS-DOS type filesystem, we will use the dosfsck tool. Please note that because FAT is owned and made by Microsoft, this tool is naturally not as good as Microsoft’s own tools (chkdsk on DOS, Windows NT, 2000, XP, Vista and 7, the scandisk on Windows 95/98/ME). Therefore, if you have a computer running Windows, it is recommended that you use this to check the filesystem.
If you don’t, you should proceed to try dosfsck. It won’t harm the filesystem, but it might not pick up certain errors that chkdsk/scandisk does.
In a terminal, type the following to know the name of the partition you want to check :
No we will run the check with the following command (assuming your partition is /dev/hda1) :
- The a option is use to automatically repair the file system.
- The v option is use to get some more information about the check.
to get some information about the others options available.
NTFS
Their is no equivalent yet to chkdsk/scandisk for NTFS in linux.
The linux-ntfs team project aims to make one.
In the meanwhile, you’ll have to use windows to check your NTFS partition.
Checking for Physical defects
to consult the documentation related to testing disks.
Recovering Data
See the DataRecovery page for details on how to recover lost files.
Further Reading
TestingStorageMedia (последним исправлял пользователь ckimes 2017-09-04 22:45:10)
The material on this wiki is available under a free license, see Copyright / License for details
You can contribute to this wiki, see Wiki Guide for details