Проверка флешки в линукс

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.

Источник

unixforum.org

Какие есть в Linux средства проверки и восстановления USB флешек?

Какие есть в Linux средства проверки и восстановления USB флешек?

Сообщение MiK13 » 17.11.2017 00:47

Когда-то купил USB флешку на 64 ГБ (была необходимость переноса большого объёма информации).
Пользовался ей довольно мало (в основном другими). Недавно понадобилось перенести ряд файлов. Достал из кармана эту. Вставил, но система её не подключила. Воспользовался другой.
Сейчас дома решил ещё раз её проверить. Вставил.Индикатор на ней загорелся. Но не подключилась.
В списке lsusb появиласт строка

Bus 001 Device 008: ID 13fe:5500 Kingston Technology Company Inc.

# ls -l /dev/sdd* brw-rw---- 1 root disk 8, 48 ноя 17 00:14 /dev/sdd

root@MK_ASUS:~# fdisk /dev/sdd Welcome to fdisk (util-linux 2.29.2). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. fdisk: cannot open /dev/sdd: Носитель не найден root@MK_ASUS:~# dd if=/dev/sdd dd: не удалось открыть '/dev/sdd': Носитель не найден

ieleja Сообщения: 307 ОС: Debian 9, macOS, Windows Контактная информация:

Re: Какие есть в Linux средства проверки и восстановления USB флешек?

Сообщение ieleja » 17.11.2017 01:06

alv Бывший модератор Сообщения: 7268 Статус: Пенсионер в законе ОС: Cintu Контактная информация:

Re: Какие есть в Linux средства проверки и восстановления USB флешек?

Сообщение alv » 17.11.2017 01:44

Флешки 64 ГБ вроде бы фабрично форматировались в ExFAT, а с её поддержкой в Linux’е, ввиду закрытости, были какие-то проблемы. Возможно, и остались.

Re: Какие есть в Linux средства проверки и восстановления USB флешек?

Сообщение MiK13 » 17.11.2017 01:51

Показывает информацию только о том, что подключено. А кроме встроенного (sda) были подключены ещё внешний (sdb) и флешка (sdc). Поэтому у неработающей было имя sdd.
Когда всё отключил, а потом опять вставил «неработающую», в dmesg появились строки

[ 5954.650892] usb 2-1: new SuperSpeed USB device number 4 using xhci_hcd [ 5954.674055] usb 2-1: New USB device found, idVendor=13fe, idProduct=5500 [ 5954.674072] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 5954.674082] usb 2-1: Product: 2307 Boot ROM [ 5954.674091] usb 2-1: Manufacturer: Phison [ 5954.679681] usb-storage 2-1:1.0: USB Mass Storage device detected [ 5954.684208] scsi host2: usb-storage 2-1:1.0 [ 5955.708522] scsi 2:0:0:0: Direct-Access 2307 PRAM 1.00 PQ: 0 ANSI: 0 CCS [ 5955.710555] sd 2:0:0:0: Attached scsi generic sg1 type 0 [ 5955.716143] sd 2:0:0:0: [sdb] Attached SCSI removable disk

Re: Какие есть в Linux средства проверки и восстановления USB флешек?

Сообщение MiK13 » 17.11.2017 02:06

Флешки 64 ГБ вроде бы фабрично форматировались в ExFAT, а с её поддержкой в Linux’е, ввиду закрытости, были какие-то проблемы. Возможно, и остались.

У меня стоит пакет exfat-fuse. Кроме того, я одно время пользовался этой флешкой без проблем. Да и fdisk должен был показать структуру. А dd вообще работает прямо с устройством.

P.S. Сообщение напоминает другое. В разрабатываемом АРМе надо принимать данные от GPS приёмника. Реализовали работу на Qt.Я параллельно написал программу, которая читала данные с /dev/ttyUSB1 и «разбирала» их. Самостоятельно работала. Но как только запускаи АРМ, работать переставала В каталоге /dev/serial пропадали ссылки на /dev/ttyUSB*, а dd при попытке прочитать /dev/ttyUSB1 говорил про отсутстие устройства. АРМ с этого устройства данные читал.

Источник