Mídia de armazenamento USB - problemas de integridade de dados no linux

Question

Eu sempre fui um pouco paranóico em verificar dados com backup em mídia removível, então depois de copiar coisas para uma unidade flash USB ou HDD portátil, eu invariavelmente desmonto a unidade, remodelo e difito -q os arquivos armazenados com os originais .

Anos atrás eu descobri que (pelo menos com o equipamento que eu tenho), eu estava vendo erros de bit em algo na ordem de 1bit / GByte. De alguma forma (eu esqueço os detalhes) eu descobri que a cura é, antes de escrever qualquer dado, fazer

echo 64 > /sys/block/sda/device/max_sectors

(assumindo que a mídia aparece como sda, é claro). Desde que me lembro de fazer isso, nunca tive problemas. (Acredito que o valor padrão max_sectors é 128).

Minhas perguntas são:

• É só eu? Eu vi o problema com uma variedade de drives flash, HDDs portáteis, placas-mãe e laptops (mas nunca fiz um teste exaustivo de todas as combinações para ver se eu tenho algum que são realmente confiáveis). A mídia que foi usada com o windows, e as máquinas que usam dual-boot windows, parecem não ter nenhum problema similar lá, então parece ser específico do Linux.

• O que realmente causa o problema? Mídia, chipsets, cabos não compatíveis com os padrões?

• Existe alguma coisa que eu possa configurar em meus sistemas (Debian Lenny) que irá definir automaticamente o max_sectors ? (Algum script HAL ou sysctl tweak? Um parâmetro mais global / sys?). Presumivelmente, o padrão 128 está no kernel em algum lugar, mas um kernel personalizado parece um pouco drástico.

Obrigado por qualquer conselho

    

Answer 1

Primeiro de tudo, quando você adquire um novo dispositivo, posso recomendar a gravação de dados nele e verificar os dados posteriormente usando o md5sum / sha1sum / ... Dispositivos USB especialmente baratos tendem a ser quebrados. :( Não é tão incomum que as canetas USB funcionem bem nos primeiros (cem) MBs, mas tendem a diminuir os dados nos últimos MBs. Infelizmente muitos usuários não estão cientes disso e percebem os problemas tarde demais: quando a caneta USB está ficando cheia .

O problema de que você está falando geralmente está localizado no chipset USB (embora, às vezes, seja visível apenas ao usar combinações especiais de hardware). Se ele funciona com o Windows, mas falha com o Linux usando o mesmo hardware, parece que há uma solução alternativa no driver do Windows que não existe no kernel do Linux (ainda). E enquanto o Linux usa max_sectors = 240 por padrão (sendo 120kB) parece ser 64kB transferências (max_sectors = 128) para o Windows, de acordo com link (onde alguns problemas com os adaptadores feitos pela Genesys Logic são mencionados também).

Para definir automaticamente os max_sectors: use o udev para esta tarefa. Ele permite que você configure max_sectors apenas para os dispositivos para os quais deseja ajustá-lo.

Você pode recuperar as informações necessárias sobre o dispositivo USB em execução:

# udevadm info -a -p /sys/class/block/sda/

ou para versões mais antigas do udev:

# udevinfo -a -p /sys/class/block/sda/

Em seguida, pegue os atributos que deseja usar para suas regras e crie um novo arquivo como 42-fix-max_sectors.rules e coloque-o em /lib/udev/rules.d (ao usar versões recentes do udev) ou / etc / udev / rules.d (para versões mais antigas do udev). Para ter uma ideia de como esse arquivo de configuração poderia ser:

SUBSYSTEM=="block", ATTRS{model}=="Voyager Mini    ", RUN+="/bin/sh -c '/bin/echo 64 > /sys/block/%k/device/max_sectors'"

Certifique-se de recarregar o udev depois de escrever seu arquivo de regras (através da execução do /etc/init.d/udev reload). Para testar seu arquivo de configuração, posso recomendar o uso de:

# udevadm test /sys/class/block/sda/

PS: Eu prefiro substituir o hardware se eu notar qualquer problemas porque geralmente não vale a pena o esforço para trabalhar em qualquer solução alternativa (e tenho certeza que você está ciente do Murphy que vai te pegar de qualquer maneira assim que você achar que está funcionando;)).

    

Answer 2

Dependendo do número de arquivos ou do tamanho dos arquivos, vi coisas semelhantes no passado.

Durante um backup / cópia de mais de 4 milhões de arquivos .PDF, descobrimos que os hashes MD5 em alguns arquivos não eram iguais!

O que funcionou para nós foi o rsync.

Uma coisa que eu sugiro que você tente é rsync os arquivos e veja se você ainda experimenta a perda de dados.

Espero que isso ajude.

    

Answer 3

No meu sistema Ubuntu 9.04, tanto /etc/udev/rules.d como /lib/udev/rules.d são usados. O README recomenda usar /etc/udev/rules.d para regras locais ou para substituir regras fornecidas pelo pacote que estão contidas em /lib/udev/rules.d . Além disso, diz:

The udev daemon watches this directory with inotify so that changes to these files are automatically picked up, for this reason they must be files and not symlinks to another location as in the case in Debian.

Estou postando essas informações aqui, já que o Ubuntu é baseado no Debian, e essas diferenças podem ser importantes para alguém que pode assumir que o comportamento é o mesmo.

    

Answer 4

Isso é excelente! Espero corrupção de dados aleatórios em todo o hardware, mas notei que os dispositivos USB são tão ruins que é um pesadelo contínuo. Obviamente, a causa principal foram os chipsets USB ruins combinados com os desenvolvedores de protocolo e sistema de arquivos que não se importam com a integridade dos dados, mas uma solução alternativa que torna os dispositivos USB utilizáveis é muito apreciada.

Você ainda deve esperar corrupção de dados sempre, porque você não sabe quais novos problemas você pode encontrar que causam isso. Mantenha os hashes de todos os seus arquivos antes de copiar um grande conjunto de dados e verifique-os depois.

cd /oldfs
find . -type f -exec md5sum {} \; >& /oldfs.md5
rsync -a . /newfs/
cd /newfs
md5sum -c /oldfs.md5 | grep -v OK$

Agora que foi descoberto que a configuração padrão max_sectors causa corrupção em muitos dispositivos, seria bom apoiar-se em fornecedores de distribuição e desenvolvedores de kernel para distribuir padrões que focam na integridade de dados com dispositivos comuns e não no desempenho com um pouco. Os dispositivos que não são compatíveis dificilmente são um motivo para não usar as configurações esperadas, quando a corrupção de dados é o resultado.