Como posso verificar se um arquivo de 1 TB foi transferido corretamente?


24

Eu freqüentemente transfiro imagens de VM de hipervisores para um servidor de arquivamento para armazenamento a longo prazo.

Eu transfiro usando netcat desde que é mais rápido que scp, rsync, ect ..

hypervisor$ cat foo.box | nc <archive IP> 1234

archive$ nc -l -p 1234 > foo.box

Quando o arquivo terminou de ser transferido, verifiquei que não havia corrupção executando md5sum tanto no alvo quanto na fonte.

Infelizmente, executar um md5sum em um arquivo grande pode levar muito tempo. Como posso comparar mais rapidamente a integridade de dois arquivos grandes?

Atualizar:

  • Minha transmissão raramente é interrompida, portanto a capacidade de reiniciar não é um problema.
  • Geralmente, leva de 3 a 4 horas para transferir via NC e depois 40 minutos para obter o md5sum.
  • A segurança do hash não é um problema neste caso.

2
Você poderia tentar uma soma de verificação diferente: en.wikipedia.org/wiki/Checksum . Eu não sei sobre o desempenho deles
tumchaaditya

Quanto tempo demora a transferência real e quanto tempo demora o md5sum?
Keith Thompson

A transferência geralmente leva entre 3-4 horas e o md5sums leva cerca de 40 minutos para ser computado.
tbenz9

Respostas:


18

Você pode usar camiseta para fazer a soma na hora com algo parecido com isto (adapte os comandos netcat para suas necessidades):

Servidor:

netcat -l -w 2 1111 | tee >( md5sum > /dev/stderr )

Cliente:

tee >( md5sum > /dev/stderr ) | netcat 127.0.0.1 1111

1
Apenas um pensamento: md5deep tem um modo "chunk" ( md5deep.sourceforge.net/md5deep.html ) que pode ser útil para isso.
LawrenceC

@ultrasawblade - Esse link é incrível, vou ter que verificar isso para outros fins. Obrigado por mencionar isso!
nerdwaller

10

Resposta de Nerdwaller sobre o uso tee para transferir e calcular simultaneamente uma soma de verificação é uma boa abordagem se você estiver preocupado principalmente com a corrupção na rede. Ele não irá protegê-lo contra a corrupção no caminho para o disco, etc., porém, já que ele está recebendo a soma de verificação antes de chegar ao disco.

Mas gostaria de acrescentar algo:

1 TiB / 40 minutos ≈ 437 MiB / seg 1 .

Isso é bem rápido, na verdade. Lembre-se que a menos que você tenha um muito de RAM, isso tem que voltar do armazenamento. Então, a primeira coisa a verificar é assistir iostat -kx 10 como você executa suas somas de verificação; em particular, você quer prestar atenção ao %util coluna. Se você está atrelando os discos (perto de 100%), a resposta é comprar um armazenamento mais rápido.

Caso contrário, como outros pôsteres mencionados, você pode tentar diferentes algoritmos de soma de verificação. MD4, MD5 e SHA-1 são todos projetados para serem hashes criptográficos (embora nenhum deles deva ser usado para essa finalidade; todos são considerados muito fracos). Velocidade sábia, você pode compará-los com openssl speed md4 md5 sha1 sha256. Eu joguei SHA256 para ter pelo menos um hash ainda forte o suficiente.

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md4              61716.74k   195224.79k   455472.73k   695089.49k   820035.58k
md5              46317.99k   140508.39k   320853.42k   473215.66k   539563.35k
sha1             43397.21k   126598.91k   283775.15k   392279.04k   473153.54k
sha256           33677.99k    75638.81k   128904.87k   155874.91k   167774.89k

Acima, você pode ver que o MD4 é o mais rápido e o SHA256 o mais lento. Esse resultado é típico de hardware semelhante a um PC, pelo menos.

Se você quiser ainda mais desempenho (ao custo de ser trivial para adulterar, e também menos propensos a detectar corrupção), você quer olhar para um hash CRC ou Adler. Dos dois, Adler é tipicamente mais rápido, mas mais fraco. Infelizmente, não estou ciente de nenhuma implementação de linha de comando realmente rápida; os programas no meu sistema são todos mais lentos que o md4 do OpenSSL.

Então, sua melhor aposta de velocidade é openssl md4 -r (a -r faz com que pareça uma saída md5sum).

Se você estiver disposto a fazer alguma programação e / ou programação mínima, veja O código de Mark Adler acabou no Stack Overflow e também xxhash . Se você tiver o SSE 4.2, não será capaz de superar a velocidade da instrução CRC de hardware.


1 1 TiB = 1024 ⁴ bytes; 1 MiB = 1024 ² bytes. Vem para 17417MB / s com potências de 1000 unidades.


É rápido, estou copiando de uma grande matriz RAID para uma segunda grande matriz RAID.
tbenz9

@ tbenz9 Eu percebi, de jeito nenhum que é um único disco! Eu adicionei alguns ponteiros para alguns hashes realmente rápidos, que infelizmente exigirão pelo menos compilá-los ... Mas eles certamente rodarão tão rápido quanto os seus discos (ou até mesmo sua RAM) puderem fornecer os dados. (E se você está se perguntando sobre Mark Adler v. Adler32, sim, isso parece ser o criador do Adler32)
derobert

@derobert, Em vez de usar pequenos arquivos para testar, você não deveria tê-lo testado com um arquivo grande como 1TB?
Pacerier

@derobert, Por que você não usa shasum em vez de?
Pacerier

@Pacerier é a saída do benchmark integrado do OpenSSL. Sem dúvida, com blocos mais longos, será um pouco mais rápido, mas é improvável que o ranking mude (foi consistente em todos os tamanhos testados). O shasum tem uma implementação mais rápida que o OpenSSL? Embora honestamente hoje em dia, se você quiser um hash criptográfico rápido, você usaria o BLAKE2.
derobert

9

o openssl comando suporta vários resumos de mensagens. Dos que eu pude tentar, md4 parece correr em cerca de 65% do tempo de md5e cerca de 54% do tempo de sha1 (para o arquivo que testei com).

Há também um md2 na documentação, mas parece dar os mesmos resultados que md5.

Mais ou menos, a velocidade parece estar inversamente relacionada à qualidade, mas como você (provavelmente) não está preocupado com a possibilidade de um adversário criar uma colisão deliberada, isso não deve ser um grande problema.

Você pode procurar por compilações de mensagens mais antigas e simples (houve md1, por exemplo)?

Um ponto menor: você tem um Uso inútil de cat. Ao invés de:

cat foo.box | nc <archive IP> 1234

você pode usar:

nc <archive IP> 1234 < foo.box

ou até mesmo:

< foo.box nc <archive IP> 1234

Isso economiza um processo, mas provavelmente não terá nenhum efeito significativo no desempenho.


1
Obrigado pela dica sobre o gato, não relacionado à pergunta, mas uma dica útil, no entanto. Felicidades!
tbenz9

@ tbenz9: código legível é mais fácil de depurar e manter e alterar. "Sem utilidade cat "Portanto, não é necessariamente totalmente ruim. Se não há ganho de desempenho, evitando-o, então é melhor ir com o que você está mais confortável com, assumindo você será o mantenedor deste código.
iconoclast

1
@ Keith, Link para baixo ..
Pacerier

4

Duas opções:

Usar sha1sum

sha1sum foo.box

Em algumas circunstâncias sha1sum é mais rápido .


Usar rsync

Levará mais tempo para ser transferido, mas o rsync verifica se o arquivo chegou intacto.

Na página do manual do rsync

Observe que o rsync sempre verifica se cada arquivo transferido   corretamente reconstruído no lado de recepção, verificando um arquivo inteiro   soma de verificação que é gerada conforme o arquivo é transferido ...


1
Obrigado pela dica sobre o sha1sum, o rsync leva mais de 10 horas para transferir, eu posso transferir o mesmo arquivo e executar o md5sums em aproximadamente 4 horas usando nc e md5sum. Estou tentando diminuir minhas 4 horas.
tbenz9

3

A ciência está progredindo. Parece que a nova função de hash BLAKE2 é mais rápida que a MD5 (e criptograficamente muito mais forte para inicializar).

Referência: https://leastauthority.com/blog/BLAKE2-harder-better-faster-stronger-than-MD5.html

Dos slides de Zooko:

cycles per byte on Intel Core i5-3210M (Ivy Bridge)
ciclos de função por byte
mensagem longa 4096 B 64 B MD5 5,0 5,2 13,1 SHA1 4,7 4,8 13,7 SHA256 12,8 13,0 30,0 Keccak 8,2 8,5 26,0 BLAKE1 5,8 6,0 14,9 BLAKE2 3,5 3,5 9,3

2

Você provavelmente não pode fazer nada melhor do que um bom hash. Você pode querer verificar outras funções hash / checksum para ver se algum é significativamente mais rápido do que md5sum. Note que você pode não precisar de algo tão forte quanto o MD5. MD5 (e coisas como SHA1) são projetados para serem criptograficamente fortes, então é inviável para um atacante / impostor criar um novo arquivo que possui o mesmo valor de hash que um valor existente (isto é, dificultar a falsificação de e-mails assinados e outros documentos). Se você não está preocupado com um ataque às suas comunicações, mas apenas um erro de comunicação comum, algo como uma verificação cíclica de redundância (CRC) pode ser boa o suficiente. (Mas eu não sei se seria mais rápido.)

Outra abordagem é tentar fazer o hash em paralelo com a transferência. Isso pode reduzir o tempo total, e definitivamente poderia reduzir o fator de irritação de precisar esperar a transferência terminar, e espere novamente para o MD5 terminar. Eu não testei isso, mas deveria ser possível fazer algo assim:

  • Na máquina de origem:

    mkfifo myfifo
    tee myfifo <  arquivo fonte  | nc  dest_host   número da porta  & amp; md5sum myfifo 
  • Na máquina de destino:

    mkfifo myfifo
    nc -l -p  número da porta  | tee myfifo & gt;  dest_file  & amp; md5sum myfifo 

É claro que verificar os tamanhos dos arquivos é uma maneira boa e rápida de detectar se algum byte foi descartado.


2

Enviar arquivos enormes é uma dor. Por que não tentar dividir os arquivos gerando um hash para cada fragmento e depois enviá-lo para o destino e, em seguida, verificar o hash e juntar os fragmentos.

Você também pode configurar uma rede BitTorrent pessoal. Isso garantiria que tudo isso chegue com segurança.


Meu entendimento é que uma vez que é uma fonte e um destino, uma rede BitTorrent não seria benéfica. Isso não beneficia apenas quando vai a muitos destinos de muitas fontes?
tbenz9

Considerei sugerir essa abordagem (dividir o arquivo de entrada em partes, enviá-las separadamente e remontá-las na outra extremidade) e não consegui descobrir como torná-las neutras em termos de desempenho, muito menos uma melhoria. Você ainda tem a mesma quantidade de tempo de transferência de rede, mas você tem muito mais sobrecarga em cada extremidade. Isso essencialmente implica copiar o arquivo da máquina de origem para a máquina de origem , copiando-o para a máquina de destino, & amp; copiando então da máquina de destino para a máquina de destino . Mesmo com grandes discos RAM, isso não é gratuito.
Scott

1
O único benefício dessa abordagem é a capacidade de reinicialização, incluindo a recuperação mais rápida de uma falha de transmissão. O OP não disse com que frequência ele recebe falhas e não indicou que isso era algo que ele queria que fosse otimizado.
Scott

@ tben9 Bittorrent é a ferramenta atual de escolha para transferência única de arquivos. Ter as informações de hash com o arquivo significa que o cliente final pode verificar os dados baixados e corrigi-los, se necessário. As múltiplas fontes são para velocidade. Portanto, sim, neste caso, é benéfico usar o BT para garantir que um arquivo seja transferido corretamente.
Underverse
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.