Як перевірити фізичне здоров'я USB-накопичувача в Linux?

Як перевірити стан здоров'я USB-накопичувача?

Як дізнатись, що USB не працює після ремонту або підлягає ремонту?

Немає можливості запитувати USB-накопичувач на SMART-параметри; Мені невідомі будь-які картки пам’яті, які підтримують це, навіть через загальнодоступне власницьке програмне забезпечення. Найкраще, що ви можете зробити, це перевірити, чи можна успішно читати + записувати на весь пристрій за допомогою badblocks.

https://en.wikipedia.org/wiki/Badblocks

Ви хочете вказати один із тестів на запис, який буде стерти всі дані на палиці; спочатку зробіть резервну копію.

Знайдіть пристрій, подивившись dmesgпісля підключення USB-накопичувача; ви побачите назву пристрою (швидше за все, sd_, тобто sdc, sdd тощо) та інформацію про виробника. Переконайтеся, що ви використовуєте належний пристрій!

Якщо палиця відформатована з дійсною файловою системою, можливо, вам доведеться спочатку unmountїї.

Приклад синтаксису для USB-накопичувача, перерахованого як / dev / sdz, виводить інформацію про хід, із тестом для руйнування даних та журналом помилок, записаним у usbstick.log:

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

Вам потрібно буде переділити і переформатувати палицю згодом, припускаючи, що вона пройде; цей тест витирає все на паличці. Будь-які збої вказують на збій контролера пам’яті пристрою, або у нього не вистачає запасних блоків для перевпорядкування несправних блоків. У цьому випадку жодній області пристрою не можна довіряти.

Через помилку [ubuntu] Перевірте USB-накопичувач , я врешті-решт виявив це, що може бути корисним:

• http://oss.digirati.com.br/f3/ "F3 - альтернатива h2testw"

Я приїхав до блогів Fight Flash Fraud та SOSFakeFlash, які рекомендують програмне забезпечення H2testw (див. Тут чи тут) для тестування флеш-пам'яті. Я завантажив H2testw і виявив дві проблеми з ним: (1) це лише для Windows, і (2) не є відкритим кодом. Однак його автор був досить люб'язним, щоб включити текстовий файл, який пояснює, що він робить; на цій сторінці йдеться про мою реалізацію цього алгоритму GPLv3.
Моя реалізація проста і надійна, і я не знаю точно, як F3 порівнюється з H2testw, оскільки я ніколи не запускав H2testw. Я називаю свою реалізацію F3, що коротко для Fight Flash Fraud або Fight Fake Flash.

Додаток від @pbhj: F3 знаходиться в репозиторії Ubuntu. Він має дві частини, f3write записує на пристрій файли 1 ГБ і f3 читає спроби їх прочитати після цього. Таким чином перевіряється ємність та здатність записувати та ефективно читати дані.

Це залежить від режиму відмови, я думаю. Вони дешеві з причини.

Як USB-пристрій, перегляд шини через диспетчер пристроїв в Windows або вихід dmesg в Linux скаже вам, чи пристрій навіть визнано підключеним. Якщо його немає, то або контролер на борту, або фізичні з'єднання ламаються.

Якщо пристрій визнано підключеним, але він не ідентифікується як дисковий контролер (і я не знаю, як це могло статися, але ...), тоді контролер знімається.

Якщо він визнаний дисковим накопичувачем, але ви не можете його встановити, можливо, ви зможете його відремонтувати за допомогою fdisk та переписати таблицю розділів, а потім зробити іншу файлову систему.

Якщо ви шукаєте еквівалент SMART , то його не знайдете. Контролери Thumbdrive дешеві. Вони є товарним сховищем, і не призначені для нормальних відмов та інтелекту, якими володіють сучасні диски.

По ходу до сьогодні ця тема викликала деякі питання.

- Скільки часу це займе (мається на увазі під час обговорення того, як дозволити йому працювати протягом ночі).

В даний час я тестую USB 3.0 128G Sandisk за допомогою sudo badblocks -w -s -o, він підключений до моєї USB 3 / USBC PCIe карти в старій версії Athlon 64x2. Отже, USB3 в USB3 на PCIe повинен бути досить швидким.

Ось мій командний рядок консолі із завершенням 33%:

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)

Цей процес повторюється з oxaa, потім 0x55, 0xff і, нарешті, 0x00.

ArchLinux дав некваліфіковану заяву:

For some devices this will take a couple of days to complete.

NB: Тестування було розпочато близько 20:30, тестування було завершено до 8:45 ранку наступного дня, і закінчилося приблизно за 12 годин для моєї ситуації .

- Деструктивне тестування - не єдиний можливий метод.

Вікіпедія запропонувала цю заяву:

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.

Моя поточна сторінка дистрибутива підтверджує, що -n не руйнує.

-n Use non-destructive read-write mode. By default only a non- destructive read-only test is done.

І нарешті, що цього не варто. заява.

Узагальнююче твердження, засноване на ситуації мільярдів сайтів пам’яті у флеш-чіпі, збій - це осередок, який уже був записаний та стертий десятки тисяч разів, і зараз виходить з ладу. І коли один тест показує, що комірка не вдалася, пам’ятайте, що кожен доданий та стираний файл виконує ці цикли.

Ідея тут полягає в тому, що коли 1 клітина виходить з ладу, багато інших клітин також досягають тієї ж точки відмови. Сьогодні одна клітина вийшла з ладу, але ви її нормально використовуєте деякий час довше, потім більше 3 комірок виходить з ладу, потім ще 24 виходять з ладу, потім 183, і перш ніж ви це знаєте, масив пам'яті пронизаний поганими місцями. Є лише стільки клітин, які можуть загинути до того, як ваша придатна ємність почне падати, врешті швидко падаючи. Як ви дізнаєтесь, що більше клітин виходить з ладу? Отже, публікації тут охороняють ваші дані, кажучи, що після того, як у вас погана комірка, ви дуже багато зробили щодо надійного зберігання. Можливо, ваше використання може отримати кілька місяців.

Це ваші дані.

HTH

Багато збоїв є або повними, або дозволяють одній локації підтримувати кілька локацій. Я написав невелику програму зчитування випадкових записів, яка використовує просте число для генератора псевдовипадкових чисел, як для шаблонів, так і для адрес. Читання розміщено за записом на достатній кількості сторінок, щоб переконатися, що я не тестую кеш-пам'ять в системі. Це ще не параметризовано, просто встановіть для моєї системи 64G пристрій з 8G таран. Сміливо критикуйте, параметризуйте, зробіть його розумнішим.

Це потужна перевірка і швидше, ніж робити кожен байт знизу вгору, але також є чудовим генератором підкачок (викочує майже все інше). Я помістив свопінг на 1 тимчасово, і він став повільніше, але більш терпимим для інших додатків. Будуть також вдячні будь-які поради щодо налаштування проти заміни:

$ 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 ;
        }
}

USB-накопичувачі досить рудиментарні, не так вже й багато що може піти на них! Як правило, якщо він відображається як диск, і ви можете відформатувати його, він працює. Ви можете спробувати ознайомитись з портативною версією CrystalDiskInfo, як це швидкий легкий інструмент для аналізу. Дуже небагато USB-накопичувачів повідомляють про SMART інформацію тощо.