Verifique o tamanho real do pen drive USB

Question

Eu recentemente li muito sobre pen drives USB que afirmam ter muito espaço (mesmo se você perguntar ao seu computador), enquanto fisicamente oferece menos. Eu comprei recentemente uma unidade USB SanDisk (128 GB reivindicada) e quero testar seu tamanho. Não é comprado via ebay ou algo assim, mas eu realmente quero testar o tamanho real antes de usá-lo de forma produtiva.

Eu poderia simplesmente copiar as coisas nele, copiá-lo de volta e ver se os arquivos estão bem. Eu também poderia automatizá-lo com hashes e outras coisas. Mas eu esperava que houvesse uma solução mais precisa. Eu li que para o Windows, H2testw faz o truque. Existe uma maneira fácil de testar isso no Ubuntu / Linux? Uma ferramenta especializada e bem trabalhada, talvez?

Atualização: só para ficar claro, a idéia é verificar se o tamanho do sistema Linux informado pelo controlador está correto (, então nenhum dado será perdido ). Não é como se eu quisesse ver se recebo 128 GB em vez de 127,3 GB. Quero testar se todos os dados que escrevo poderão ser lidos novamente. Infelizmente, só consigo encontrar algumas informações sobre isso em sites de tecnologia em inglês. Existem boas fontes alemãs, no entanto. Eu estou realmente procurando por um aplicativo como esses, mas para o Ubuntu / Linux:

Update2: Eu tentei reunir algumas fontes em inglês. Eu não li todos eles em detalhes, devido a falta de tempo.

• link
• link
• link
• link

Update3: explicações

Devido aos estranhos críticos abaixo, algumas explicações.

Qual é o problema e por que o dd sozinho não resolve?

Esta é uma reação a

  

"Descubra claramente qual é o problema que você está tentando resolver e qual é a definição de" disco falso "."

Parece que algumas pessoas não entendem o problema. Então eu tento explicar o mais breve possível, mas acho que isso é muito mais do que a minha pergunta.

A capacidade dos dispositivos USB que o seu sistema operacional ou ferramentas Unix oferecem pode estar errada. Isso é fatal, já que seu sistema operacional regula a quantidade de dados para os quais você pode enviá-lo. Envie mais dados do que realmente aguenta, você receberá uma perda de dados. Isto é um problema. Então, por que isso pode acontecer?

Você não precisa conhecer bem o protocolo USB para entender o problema. Interfaces Seriais possuem a propriedade comum, que o dispositivo cliente (a unidade usb) precisará informar sua própria capacidade através desta interface serial. Isso significa que o dispositivo cliente precisa de seu próprio controlador com algum conhecimento sobre a finalidade dos dispositivos e, nesse caso, sua capacidade. Ele também decide o que é feito, quando recebe o comando para armazenar algo. Se o controlador for programado dessa maneira, ele pode simplesmente ignorar o comando ou sobrescrever algo com os dados.

O que isso significa? Quaisquer que sejam as ferramentas do seu Unix, fale sobre a capacidade da unidade: é o que as ferramentas pediram à unidade, nada mais. É para isso que o h2testw foi inventado: testa o tamanho real com um método explicado mais adiante e compara-o ao que a unidade diz. Se isso não é o mesmo, você pode ter uma perda de dados, porque todas as suas operações comuns para armazenar dados, contam com as informações do seu sistema operacional, que apenas pede ao controlador. Por que apenas perguntar? O teste precisa de tempo e sobrescreve todos os dados na unidade. Portanto, é natural que um sistema operacional precise contar com essas informações.

Para verificar a capacidade real como h2testw, você pode usar dd para gravar dados na unidade, ler novamente e ver se é o mesmo que você escreveu. Totalmente legítimo A natureza do hardware e da unidade tornam isso mais complicado. Considere write-caches por exemplo. Você precisa garantir que você não leia do cache. Este é apenas um exemplo de por que não é tão fácil quanto parece. Pense também que apenas escrever zeros significa uma baixa entropia de informação, que pode ser reconstruída durante a leitura. Não é tão fácil em detalhes. Você ainda pode fazer isso manualmente, é claro.

Mas por que, quando você pode automatizar as coisas? Por que o trabalho? f3 como proposto na minha resposta abaixo, implementa toneladas de pensamentos de muitos contribuidores (considere que o tipo de h2testw estendido) e também implementa vários métodos com diferentes compensações. O desenvolvedor descobriu os truques de diferentes unidades falsas (também conhecidas como unidades falsificadas) que tinham em mãos .Então, enquanto eu entendo a teoria e o problema (aparentemente porque os problemas são bem explicados na mídia tecnológica alemã, mas não na mídia em inglês), eu não pretendo entender tudo, e é por isso que eu mencionei acima. É apenas a teoria que eu entendo, e eu sou mais um cara de software. Mas como estudante de informática eu entendo bem o suficiente para ver o problema.

  

"Tente entender os utilitários básicos do Unix"

Na verdade, eu já respondi a essa pergunta, mas para deixar claro: as ferramentas Unix usam apenas o protocolo USB (apenas para dispositivos USB, é claro) para coletar informações. Não faz sentido fazer mais do que isso.

Ajuda apenas a comprar de fornecedores confiáveis?

tl; dr: Não.

  

"Quando se trata de comprar bens, assim como se trata de qualquer forma de segurança, considere encontrar um vendedor de confiança e comprar discos apenas deles."

Segurança (e segurança) NÃO é sobre confiança! É sobre verificação e validação! Desculpe, mas isso é tão errado de muitas maneiras.

Suponha que você compre por meio de um vendedor confiável. Algumas perguntas:

1. O fornecedor testou o hardware para garantir que não haja perda de dados? Reconhece quando ele compra discos falsos e vende-os? Não necessariamente.

2. É possível que ele compre coisas que ele não sabe que são falsas? Totalmente, veja as recentes falsificações: link , link

3. Se eu perder minha apresentação na unidade e estragar a apresentação, meu fornecedor confiável voltará a tempo e me resgatará? Provavelmente substituirá a unidade, desde que o último DeLorean que viaja no tempo foi destruído em 1885.

Outras coisas

  

"Esta pergunta realmente parece mais como" promo "para o que o OP gosta, e parece que o OP está muito menos interessado em testar os drives."

Isso é ridículo. Eu estava procurando especificamente por uma ferramenta semelhante ao h2testw que também roda no linux. E sim, é disso que eu "gostaria", resposta útil, sinto muito. Eu não tinha ideia de que a imprensa que fala inglês não está ciente de tais problemas e teve sorte de encontrar algo assim mais tarde. Isso não é uma promoção, mas na verdade parece que você poderia usar uma.

    

Answer 1

Existe apenas uma alternativa que encontrei, mas acho que esta é ainda melhor do que a ferramenta original h2testw para o MS Windows. Felizmente, é realmente fácil de usar, mesmo a partir da linha de comando. Existem GUIs disponíveis, no entanto. Há também muitas informações sobre a implementação e o problema com unidades falsas no site de ferramentas.

F3 - "Lutar com Fraude Flash" ou "Lutar contra Flash Falso"

Fonte: link
QT GUI: link
GUI do OSX: link

O método h2testw

O F3 é uma coleção de ferramentas que lida com flash drives falsos. Dois deles juntos implementam o h2testw -Method:

f3write [--start-at=NUM] [--end-at=NUM] <PATH>
f3read  [--start-at=NUM] [--end-at=NUM] <PATH>

f3write solicitará o tamanho dos dispositivos reivindicados e os preencherá com arquivos gerados com um tamanho de 1gb cada. f3read lerá todos esses arquivos e verá se eles estão completos e não quebrados. Como exemplo, os comandos que usei para testar o meu pen drive de ~ 128GB:

~> f3write /media/username/1EB8021AB801F0D7/
Free space: 117.94 GB
Creating file 1.h2w ... OK!                           
...
Creating file 118.h2w ... OK!                         
Free space: 0.00 Byte
Average writing speed: 11.67 MB/s

Agora, para testar se os arquivos estão armazenados corretamente:

~> f3read /media/username/1EB8021AB801F0D7/
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
...
Validating file 118.h2w ... 1979488/        0/      0/      0

  Data OK: 117.94 GB (247346272 sectors)
Data LOST: 0.00 Byte (0 sectors)
           Corrupted: 0.00 Byte (0 sectors)
    Slightly changed: 0.00 Byte (0 sectors)
         Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 32.38 MB/s

O teste para uma unidade deste tamanho demorou cerca de três horas com este método e, por vezes, causou uma carga de disco pesada no meu computador, mas é-me dito o mais preciso.

O método f3probe

f3probe é outra maneira de testar as unidades, não tão preciso, mas mais rápido, pois não grava na unidade inteira. Você pode ler mais sobre isso no site de ferramentas. Se você quer ter 100% de certeza, é melhor usar o método h2testw. Como o desenvolvedor descreve no site:

  

f3probe é a maneira mais rápida de identificar unidades falsas e seus tamanhos reais.

e

  

Finalmente, graças ao f3probe ser software livre, e uma vez f3probe é   batalha comprovada, f3probe poderia ser incorporado em smartphones, câmeras, MP3   jogadores, e outros dispositivos para parar de uma vez por todas a proliferação   de flash falso.

Há também um exemplo de uso no site:

$ sudo ./f3probe --destructive --time-ops /dev/sdb
[sudo] password for michel: 
F3 probe 6.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing may **demolish data,** so it is more suitable for flash drives out of the box, without files being stored yet. The process normally takes from a few seconds to 15 minutes, but
         it can take longer. Please be patient. 

Bad news: The device '/dev/sdb' is a counterfeit of type limbo

You can "fix" this device using the following command:
f3fix --last-sec=16477878 /dev/sdb

Device geometry:
             *Usable* size: 7.86 GB (16477879 blocks)
            Announced size: 15.33 GB (32155648 blocks)
                    Module: 16.00 GB (2^34 Bytes)
    Approximate cache size: 0.00 Byte (0 blocks), need-reset=yes
       Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 1'13"
 Operation: total time / count = avg time
      Read: 472.1ms / 4198 = 112us
     Write: 55.48s / 2158 = 25.7ms
     Reset: 17.88s / 14 = 1.27s

Observe que ele também retorna um comando que permite usar a unidade com seu tamanho real, usando f3fix .

A ferramenta f3fix

  

O f3fix permite que os usuários usem a capacidade real de drives falsos sem perder dados.

Instalar no Ubuntu

As ferramentas descritas fazem parte do pacote f3 , que está pelo menos disponível no Ubuntu 15.10. Segundo o site, existem mais algumas ferramentas disponíveis. Para obtê-los, dê uma olhada no site. Para instalar o pacote, basta digitar em um terminal:

sudo apt-get install f3

O pacote vem com páginas de manual curtas, mas úteis, embora eu ache que elas não tenham informações do site sobre a diferença de f3read / write e f3probe por exemplo, e é por isso que essa resposta ficou um pouco mais longa.

    

Answer 2

Eu escrevi uma ferramenta simples para isso, é chamada de CapacityTester (screenshot) e tem uma GUI, bem como um CLI.

Há um binário precompilado para o Debian 7 disponível para download , que é muito provável que funcione fora da caixa em um arquivo sistema Ubuntu moderno.

Eu escrevi para meu uso pessoal, porque não consegui encontrar uma ferramenta gráfica para essa finalidade. Você só precisa montar sua unidade flash USB vazia primeiro, selecioná-la e iniciar o teste. É uma ferramenta muito burra porque tudo o que faz é preencher a unidade com arquivos e, em seguida, verificar se os dados na unidade estão corretos. Irá abortar o teste no primeiro erro (escrita ou leitura / verificação). Ele relatará o deslocamento do fragmento que não pôde ser gravado ou verificado com êxito, mas esse é um deslocamento lógico, portanto, essas informações podem ser inúteis porque dependem do sistema de arquivos em que os arquivos estão localizados na unidade. No entanto, quando a unidade tiver sido preenchida com dados e tudo puder ser lido e verificado, deve ser seguro assumir que a capacidade relatada da unidade está correta. Como nota lateral, os arquivos de teste são excluídos automaticamente (isso pode não funcionar se a unidade estiver com problemas).

Novamente, é muito simples, pois funciona apenas com arquivos sobre um sistema de arquivos existente. Portanto, há alguns KB (buffer de + 1M) que não podem ser testados. E é muito lento porque realmente preenche todo o sistema de arquivos. O F3 é certamente muito mais sofisticado e também mais rápido, mas não possui interface gráfica. A única razão pela qual o CapacityTester existe é porque ele tem uma GUI para que possa ser usado por usuários que não estão familiarizados com a linha de comando ou que simplesmente preferem uma GUI.

O feedback é apreciado.

    

Answer 3

Enfrentando o comportamento do OP e a "unidade falsa"

Estou editando a resposta para abordar adequadamente alguns pontos, já que OP tem sido muito veemente (e, na minha opinião, opondo-se à maioria dos comentários e respostas, exceto os deles, que acho suspeitos). Particularmente, há muita afirmação de que existe "drive falso", mas não há uma definição clara sobre o que realmente significa na Terra. OP declarou:

  

Eu poderia simplesmente copiar as coisas nele, copiá-lo de volta e ver se os arquivos estão bem. Eu também poderia automatizá-lo com hashes e outras coisas. Mas eu esperava que houvesse uma solução mais precisa.

O próprio OP admitiu que "poderia simplesmente copiar coisas", e verificou a integridade dos dados, mas foram muito contra todos os outros comentários e respostas que propuseram qualquer outra coisa e OP apenas continuou pressionando F3 como o "acordo real". A questão em si começou no início sobre o tamanho da unidade, mas depois OP por qualquer motivo mencionado hashes para "olhar se os arquivos estão ok", como se houvesse unidades misteriosas que reivindicam um tamanho e permitem que você escreva esse tamanho, mas então os dados estão corrompidos. Portanto, acho altamente suspeito e consideraria OP promover F3 como pergunta e resposta de spam.

Quando uma unidade é realmente uma unidade falsa

Na pergunta, a aparente definição do OP é

  

".. drives que afirmam ter muito espaço (muitas vezes carregado muito longe, como 128 GB), enquanto fisicamente oferecendo apenas 0,5 a 4 GB."

Em outras palavras, de acordo com OP, o controlador reivindica X quantidade de dados, mas o USB só pode conter algo como 80-90% menos do que é reivindicado.

O usuário sudodus proposto no comentários (grifo nosso):" Descobri que vários pendrives USB são um pouco menores que o tamanho nominal. chamá-los de subdimensionados . Acho que os drives falsos são 'substancialmente subdimensionados' (geralmente metade do tamanho nominal ou menos ) ". Esta definição é ótima, no entanto, se tomarmos isso, a unidade falsa é definida em 50%. Uma unidade que reivindica 64 GB, mas que pode conter apenas 32 GB, perde tecnicamente metade do seu valor para o proprietário, e o proprietário só pode colocar metade do que pretendia na unidade.

Proponho uma definição mais simples: o dispositivo de armazenamento falsificado é aquele que afirma ter Claimed Size , mas está abaixo de 15% de tolerância (e a tolerância é Claimed Size ± 15 % ).

O ± 15 % é muito razoável. Considere também que os usuários geralmente são confundidos entre organizações Unix, IEEE e IEC usando prefixo binário em vez de 10 prefixo para o tamanho do armazenamento de dados. A diferença chega a 20% no nível do prefixo yotta, mas os drives USB ainda não estão lá, então, talvez nos próximos 20 anos, 15% seja razoável. (Veja askubuntu pergunta "Significado de 'i' em 'MiB'" e Prefixo binário )

Testando a unidade

Efetivamente, o usuário não precisa de nenhuma ferramenta especial, além do que já vem com o Ubuntu e a maioria dos sistemas Unix compatíveis com POSIX. Vamos enfatizar e reformular novamente a definição:

  

Se não for possível gravar a quantidade de dados para a unidade e o que escrevemos está dentro da tolerância de 15%, a unidade está OK

A maneira mais simples de fazer isso é com dd , apenas sobrescreva o dispositivo com zeros (e, claro, lembre-se de salvar seus arquivos antes de fazer isso).

sudo dd if=/dev/zero of=/dev/sdb1 iflag=nocache oflag=direct bs=1                        

Observe o bs=1 para o tamanho do bloco de 1 byte. O comando dd geralmente fornece um relatório sobre quanto está escrito.

$ dd if=/dev/zero of=/dev/null bs=1 count=1024
1024+0 records in
1024+0 records out
1024 bytes (1.0 kB, 1.0 KiB) copied, 0.00261981 s, 391 kB/s

Pedimos que escrevesse 1024 bytes, ele escreveu 1024 bytes.

Uma lista mais precisa das etapas que seguem a definição seria:

• Descubra quantos dados a unidade reivindica (supondo que você suspeite que df esteja "equivocado"). Neste exemplo, suponhamos que /dev/sdb1 seja o arquivo do meu dispositivo para a unidade USB:

  $ df -P /dev/sdb1 | awk 'NR==2{print }'
  115247656
  

  Observe que -P flag é para portabilidade POSIX, o que significa que o tamanho de bloco dos dados será de 1024 bytes e isso significa que há 115247656 * 1024 bytes nessa unidade.

• Descobrir o que é tolerância de 15% abaixo das reivindicações de unidade (115247656), talvez use um utilitário que suporte o cálculo de ponto flutuante, como awk :

   $ awk 'BEGIN{printf "%d\n",115247656*(1-0.15)}'
   97960507
  

• Crie dados aleatórios no disco rígido do mesmo tamanho da unidade na etapa anterior para usar como referência: dd if=/dev/urandom of=./mytestfile.random bs=1024 count=97960507

• Agora escreva os dados dd if=./mytestfile.random of=/dev/sda1 . Se a unidade puder aguentar isso, é "real". Você também pode usar md5sum ou sha1sum do ./mytestfile.random e comparar com /dev/sda1 agora.Melhor ainda seria escrever o mytestfile.random para o ponto de montagem do arquivo, mantendo assim o sistema de arquivos na unidade e inalterando o particionamento da unidade, em outras palavras

  dd if=./mytestfile.random of=/mountpoint/for/usb/drive/testfile.random
  

• Para integridade, você pode fazer qualquer verificação de hash, como md5sum , sha1sum , sha256sum ou outros. Por exemplo

  md5sum ./mytestfile.random  /mountpoint/for/usb/drive/testfile.random
  

  O ponto chave aqui é que, se a quantidade de dados gravados estiver dentro da tolerância e produzir uma soma de verificação correta antes e depois da gravação - a unidade provavelmente está OK.

Tudo isso pode ser colocado em um bom roteiro por conveniência, se assim o desejar.

Conclusão

Esta questão parece ser mais como "promo" para o que o OP gosta, e parece que o OP está muito menos interessado em testar os drives. Além disso, o problema em si é mais humano do que o problema da "unidade". Nos comentários, o próprio OP afirmou que não entende o comportamento do USB, mas é veemente culpado pelo "controlador". Vou deixar essa questão com 3 pontos:

• Descubra claramente qual é o problema que você está tentando resolver e qual é a definição de "unidade falsa".
• Tente entender os utilitários básicos do Unix
• Quando se trata de comprar mercadorias, da mesma forma que se trata de qualquer forma de segurança, considere encontrar um vendedor de confiança e comprar apenas discos deles.