Como verificar a integridade física de um pendrive no Linux?

70

Como verificar o status de integridade de um pendrive?

Como eu sei que um USB está quebrado além do reparo ou reparável?

    
por valpa 09.01.2012 / 00:26

6 respostas

62

Não há como consultar um cartão de memória USB para parâmetros do tipo SMART; Não tenho conhecimento de nenhum cartão de memória que suporte isso mesmo através de software proprietário publicamente disponível. O melhor que você pode fazer é verificar se consegue ler + gravar com êxito em todo o dispositivo usando badblocks .

link

Você deseja especificar um dos testes de gravação, que limpará todos os dados no bastão; faça um backup primeiro.

Encontre o dispositivo olhando dmesg depois de conectar o pen drive USB; você verá um nome de dispositivo (provavelmente sd_, ou seja, sdc, sdd etc.) e informações do fabricante. Verifique se você está usando o dispositivo adequado!

Se o bastão for formatado com um sistema de arquivos válido, você poderá ter unmount primeiro.

Exemplo de sintaxe, para um dispositivo USB enumerado como / dev / sdz, que gera informações de progresso, com um teste de gravação destrutivo de dados e um registro de erros gravado em usbstick.log:

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

Você precisará reparticionar e reformatar o bastão depois, presumindo que ele passe; este teste vai limpar tudo no palito. Qualquer falha indica uma falha no controlador de memória do dispositivo ou esgotou os blocos sobressalentes para remapear blocos com falha. Nesse caso, nenhuma área do dispositivo pode ser confiável.

    
por 09.01.2012 / 04:58
18

Via [ubuntu] Erro na verificação da unidade flash USB , acabei encontrando isso, o que pode ser útil:

  • link "F3 - uma alternativa ao h2testw"

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.

Adendo por @pbhj: F3 está nos repositórios do Ubuntu. Ele tem duas partes, f3write grava arquivos de 1GB no dispositivo e f3read tenta lê-los depois. Dessa forma, a capacidade e a capacidade de escrever e ler dados com eficiência são testadas.

    
por 29.04.2013 / 08:20
14

Depende do modo de falha, suponho. Eles são baratos por um motivo.

Como um dispositivo USB, assistir ao barramento através do gerenciador de dispositivos no Windows ou a saída do dmesg no Linux lhe dirá se o dispositivo é reconhecido como estando conectado. Se não estiver, então o controlador a bordo ou as conexões físicas estão quebradas.

Se o dispositivo for reconhecido como conectado, mas não for identificado como um controlador de disco (e não sei como isso pode acontecer, mas ...), o controlador é disparado.

Se for reconhecido como uma unidade de disco, mas você não puder montá-lo, você poderá consertá-lo via fdisk e reescrever a tabela de partições, depois criar outro sistema de arquivos.

Se você está procurando o equivalente de S.M.A.R.T. , você não o encontrará. Controladores Thumbdrive são baratos. Eles são armazenamento de commodities, e não significam ter as falhas e inteligência normais que as unidades modernas têm.

    
por 09.01.2012 / 00:33
1

Muitas falhas são completas ou permitem que um local ofereça suporte a vários locais. Eu escrevi um pequeno programa de leitura de escrita aleatória que usa um número primo para um gerador de números pseudo-aleatórios, para padrões e endereços. As leituras são escalonadas atrás das gravações por páginas suficientes para garantir que eu não esteja testando o cache de memória RAM no sistema. Ainda não está parametrizado, basta configurar para um dispositivo 64G no meu sistema com 8G ram. Sinta-se à vontade para criticar, parametrizar, torná-lo mais inteligente.

Esta é uma verificação poderosa e mais rápida do que fazer cada byte de baixo para cima, mas também é um ótimo gerador de troca (rola quase todo o resto). Eu coloquei swapiness em 1 temporariamente e tornou-se mais lento, mas mais tolerável a outros aplicativos. Todas as dicas sobre como ajustar o swapout também serão apreciadas:

$ 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 ;
        }
}
    
por 14.08.2015 / 21:56
0

As unidades USB são bastante rudimentares, não há muita coisa que possa dar errado nelas! Geralmente, se aparecer como uma unidade e você puder formatá-la, ela funcionará. Você pode tentar dar uma olhada na versão portátil do CrystalDiskInfo , que é uma ferramenta de análise rápida e leve. Muito poucas varas USB reportam de volta S.M.A.R.T. informações e afins embora.

    
por 09.01.2012 / 00:30
0

No caminho até hoje, este tópico levantou algumas questões.

- Quanto tempo isso vai demorar (implícito na discussão de deixá-lo rodar durante a noite).

No momento, estou testando um Sandisk USB 3.0 128G usando sudo badblocks -w -s -o , ele está conectado à minha placa USB 3 / USBC PCIe em um Athlon 64x2 mais antigo. Então, USB3 em USB3 no PCIe deve ser bem rápido.

Aqui está minha linha de comando do console com 33% de conclusão:

Testing with pattern 0xaa: 33.35% done, 49:47 elapsed. (0/0/0 errors)

e novamente mais tarde:

Testing with pattern 0xaa: 54.10% done, 1:17:04 elapsed. (0/0/0 errors)

Em seguida, veio este segmento:

Reading and comparing: 43.42% done, 2:23:44 elapsed. (0/0/0 errors)

Este processo é repetido com oxaa, 0x55, 0xff e finalmente 0x00.

ArchLinux fez uma declaração não qualificada:

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

N.B .: O teste foi iniciado por volta das 20h30, os testes foram concluídos antes das 8h45 do dia seguinte, completando em cerca de <12 horas para minha situação .

- Testes destrutivos não são o único método possível.

A Wikipedia ofereceu esta declaração:

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.

Minha página de distribuição atual confirma que o -n é não-destrutivo.

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

E finalmente isso não vale a pena. declaração.

Uma declaração resumida, baseada na situação de bilhões de sites de memória em um chip flash, uma falha é uma célula que já foi escrita e apagada dezenas de milhares de vezes, e agora está falhando. E quando um teste mostra que uma célula falhou, lembre-se de que cada arquivo adicionado e apagado está executando esses ciclos.

A idéia aqui é que, quando 1 célula falha, muitas outras células também estão atingindo o mesmo ponto de falha. Uma célula falhou hoje, mas você a usa normalmente por mais algum tempo, então mais 3 células falham, 24 falham, 183 e, antes que você perceba, a matriz de memória está repleta de pontos ruins. Existem apenas tantas células que podem morrer antes de sua capacidade útil começar a cair, eventualmente caindo rapidamente. Como você saberá que mais células estão falhando? Portanto, as postagens aqui estão protegendo seus dados dizendo que, depois de ter uma célula ruim, você está praticamente pronto em relação ao armazenamento confiável. Seu uso ainda pode lhe dar alguns meses.

São seus dados.

HTH

    
por 07.06.2018 / 03:01