Bagaimana saya bisa memverifikasi bahwa file 1TB ditransfer dengan benar?


25

Saya sering mentransfer gambar VM dari hypervisor ke server arsip untuk penyimpanan jangka panjang.

Saya mentransfer menggunakan netcat karena lebih cepat daripada scp, rsync, dll ..

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

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

Setelah file selesai ditransfer, saya memverifikasi tidak ada korupsi dengan menjalankan md5sumtarget dan sumbernya.

Sayangnya, menjalankan md5sum pada file besar dapat memakan waktu yang sangat lama. Bagaimana saya bisa lebih cepat membandingkan integritas dua file besar?

Memperbarui:

  • Transmisi saya jarang terganggu sehingga kemampuan me-restart tidak menjadi masalah.
  • Biasanya dibutuhkan 3-4 jam untuk mentransfer melalui NC dan kemudian 40 menit untuk mendapatkan md5sum.
  • Keamanan hash tidak menjadi masalah dalam kasus ini.

2
Anda dapat mencoba checksum yang berbeda: en.wikipedia.org/wiki/Checksum . Saya tidak tahu tentang kinerja mereka
tumchaaditya

Berapa lama waktu transfer sebenarnya, dan berapa lama md5sum berlangsung?
Keith Thompson

Transfer umumnya memakan waktu antara 3-4 jam, dan md5sum membutuhkan waktu sekitar 40 menit untuk menghitung.
tbenz9

Jawaban:


18

Anda dapat menggunakan tee untuk melakukan penjumlahan dengan cepat seperti ini (sesuaikan perintah netcat untuk kebutuhan Anda):

Server:

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

Klien:

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

1
Hanya sebuah pemikiran: md5deepmemiliki mode "chunk" ( md5deep.sourceforge.net/md5deep.html ) yang mungkin berguna untuk ini.
LawrenceC

@ultrasawblade - Tautan yang luar biasa, saya harus memeriksanya untuk tujuan lain. Terima kasih telah menyebutkannya!
nerdwaller

10

Jawaban Nerdwaller tentang penggunaan teeuntuk secara bersamaan mentransfer dan menghitung checksum adalah pendekatan yang baik jika Anda terutama khawatir tentang korupsi melalui jaringan. Itu tidak akan melindungi Anda dari korupsi dalam perjalanan ke disk, dll., Karena mengambil checksum sebelum hits disk.

Tetapi saya ingin menambahkan sesuatu:

1 TiB / 40 menit ≈ 437 MiB / detik 1 .

Sebenarnya itu cukup cepat. Ingatlah bahwa kecuali Anda memiliki banyak RAM, itu harus kembali dari penyimpanan. Jadi hal pertama yang harus diperiksa adalah menonton iostat -kx 10saat Anda menjalankan checksum Anda; khususnya Anda ingin memperhatikan %utilkolom. Jika Anda mengelompokkan disk (mendekati 100%), maka jawabannya adalah membeli penyimpanan yang lebih cepat.

Jika tidak, seperti poster lain yang disebutkan, Anda dapat mencoba berbagai algoritma checksum. MD4, MD5, dan SHA-1 semuanya dirancang untuk hash kriptografi (meskipun tidak ada yang harus digunakan untuk tujuan itu lagi; semua dianggap terlalu lemah). Dari segi kecepatan, Anda dapat membandingkannya openssl speed md4 md5 sha1 sha256. Saya telah melempar SHA256 untuk memiliki setidaknya satu hash yang masih cukup kuat.

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

Dari hal di atas, Anda dapat melihat bahwa MD4 adalah yang tercepat, dan SHA256 yang paling lambat. Hasil ini khas pada perangkat keras seperti PC, setidaknya.

Jika Anda ingin lebih banyak kinerja (dengan biaya sepele untuk mengutak-atik, dan juga lebih kecil kemungkinannya untuk mendeteksi korupsi), Anda ingin melihat CRC atau hash Adler. Dari keduanya, Adler biasanya lebih cepat, tetapi lebih lemah. Sayangnya, saya tidak mengetahui adanya implementasi command line yang sangat cepat; program pada sistem saya semua lebih lambat dari md4 OpenSSL.

Jadi, kecepatan terbaik taruhan Anda adalah openssl md4 -r( -rmembuatnya terlihat seperti output md5sum).

Jika Anda bersedia melakukan kompilasi dan / atau pemrograman minimal, lihat kode Mark Adler di Stack Overflow dan juga xxhash . Jika Anda memiliki SSE 4.2, Anda tidak akan bisa mengalahkan kecepatan instruksi CRC perangkat keras.


1 1 TiB = 1024⁴ byte; 1 MiB = 1024² byte. Datang ke ≈417MB / detik dengan kekuatan-of-1000 unit.


Cepat, saya menyalin dari satu array RAID besar ke array RAID besar ke-2.
tbenz9

@ tbenz9 saya pikir, tidak mungkin itu disk tunggal! Saya telah menambahkan beberapa petunjuk ke beberapa hash yang sangat cepat, yang sayangnya akan membutuhkan setidaknya kompilasi mereka ... Tapi mereka pasti akan berjalan secepat disk Anda (atau bahkan RAM Anda) dapat memberikan data. (Dan jika Anda bertanya-tanya tentang Mark Adler v. Adler32, ya, itu tampaknya adalah pencipta Adler32)
derobert

@derobert, Alih-alih menggunakan file kecil untuk menguji, bukankah Anda harus mengujinya dengan file besar seperti 1TB?
Pacerier

@derobert, Kenapa tidak Anda gunakan shasumsaja?
Pacerier

@Pacerier adalah output dari tolok ukur bawaan OpenSSL. Tidak diragukan lagi dengan blok yang lebih panjang, ini akan menjadi sedikit lebih cepat, tetapi peringkat tidak mungkin berubah (konsisten di semua ukuran yang diuji). Apakah shasum memiliki implementasi yang lebih cepat daripada OpenSSL? Meskipun saat ini jujur ​​jika Anda menginginkan hash kriptografi cepat, Anda akan menggunakan BLAKE2.
derobert

9

The opensslperintah mendukung beberapa mencerna pesan. Dari yang saya dapat mencoba, md4tampaknya berjalan di sekitar 65% dari waktu md5, dan sekitar 54% dari waktu sha1(untuk satu file yang saya uji dengan).

Ada juga md2dalam dokumentasi, tetapi tampaknya memberikan hasil yang sama md5.

Sangat kasar, kecepatan tampaknya berbanding terbalik dengan kualitas, tetapi karena Anda (mungkin) tidak peduli tentang musuh yang menciptakan tabrakan yang disengaja, itu seharusnya tidak menjadi masalah.

Anda mungkin mencari-cari pesan yang lebih tua dan lebih sederhana (apakah ada md1, misalnya)?

Poin kecil: Anda sudah menggunakan Useless ofcat . Daripada:

cat foo.box | nc <archive IP> 1234

Anda dapat gunakan:

nc <archive IP> 1234 < foo.box

atau bahkan:

< foo.box nc <archive IP> 1234

Melakukan hal itu menghemat suatu proses, tetapi mungkin tidak akan memiliki efek signifikan pada kinerja.


1
Terima kasih atas tip pada kucing, tidak terkait dengan pertanyaan tetapi tip bermanfaat. Tepuk tangan!
tbenz9

@ tbenz9: kode yang dapat dibaca lebih mudah untuk di-debug, dipelihara, dan diubah. "Tidak berguna cat" karenanya tidak selalu sepenuhnya buruk. Jika tidak ada peningkatan kinerja dengan menghindarinya, maka lebih baik untuk pergi dengan apa pun yang Anda merasa lebih nyaman, dengan asumsi Anda akan menjadi pemelihara kode ini.
iconoclast

1
@Keith, Tautkan ke bawah ..
Pacerier

4

Dua pilihan:

Menggunakan sha1sum

sha1sum foo.box

Dalam beberapa keadaan, sha1sum lebih cepat .


Menggunakan rsync

Ini akan memakan waktu lebih lama untuk transfer, tetapi rsync memverifikasi bahwa file tersebut tiba utuh.

Dari halaman manual rsync

Perhatikan bahwa rsync selalu memverifikasi bahwa setiap file yang ditransfer direkonstruksi dengan benar di sisi penerima dengan memeriksa checksum seluruh file yang dihasilkan ketika file ditransfer ...


1
Terima kasih atas tip tentang sha1sum, rsync membutuhkan waktu lebih dari 10 jam untuk mentransfer, saya dapat mentransfer file yang sama dan menjalankan md5sums dalam waktu sekitar 4 jam menggunakan nc dan md5sum. Saya mencoba untuk mendapatkan 4 jam saya lebih rendah lagi.
tbenz9

3

Ilmu pengetahuan mengalami kemajuan. Tampaknya fungsi hash BLAKE2 baru lebih cepat daripada MD5 (dan secara kriptografis lebih kuat untuk mem-boot).

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

Dari slide Zooko:

siklus per byte pada 
siklus fungsi Intel Core i5-3210M (Ivy Bridge) per byte
panjang msg 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

Anda mungkin tidak bisa melakukan yang lebih baik daripada hash yang baik. Anda mungkin ingin memeriksa fungsi hash / checksum lainnya untuk melihat apakah ada yang secara signifikan lebih cepat daripada md5sum. Perhatikan bahwa Anda mungkin tidak membutuhkan sesuatu yang sekuat MD5. MD5 (dan hal-hal seperti SHA1) dirancang agar kuat secara kriptografis, sehingga tidak mungkin bagi penyerang / penipu untuk membuat file baru yang memiliki nilai hash yang sama dengan nilai yang ada (yaitu, untuk membuatnya sulit untuk mengutak-atik e yang ditandatangani). -mail dan dokumen lainnya). Jika Anda tidak khawatir tentang serangan pada komunikasi Anda, tetapi hanya kesalahan comms run-of-the-mill, sesuatu seperti pemeriksaan redundansi siklik (CRC) mungkin cukup baik. (Tapi aku tidak tahu apakah akan lebih cepat.)

Pendekatan lain adalah mencoba melakukan hash secara paralel dengan transfer. Ini mungkin mengurangi waktu keseluruhan, dan pasti bisa mengurangi faktor iritasi karena harus menunggu transfer selesai, dan kemudian menunggu lagi sampai MD5 selesai. Saya belum menguji ini, tetapi mungkin bisa melakukan sesuatu seperti ini:

  • Di mesin sumber:

    mkfifo myfifo
    tee myfifo < source_file | nc dest_host  port_number & md5sum myfifo
    
  • Di mesin tujuan:

    mkfifo myfifo
    nc -l -p port_number | tee myfifo> dest_file & md5sum myfifo
    

Tentu saja memeriksa ukuran file adalah cara yang baik dan cepat untuk mendeteksi jika ada byte yang jatuh.


2

Mengirim file besar sangat merepotkan. Mengapa tidak mencoba memotong-motong file yang menghasilkan hash untuk setiap chunk dan kemudian mengirimkannya ke tujuan dan kemudian memeriksa hash dan bergabung dengan potongan.

Anda juga dapat mengatur jaringan BitTorrent pribadi. Itu akan memastikan bahwa semuanya mencapai dengan aman.


Pemahaman saya adalah karena ini adalah satu sumber dan satu tujuan jaringan BitTorrent tidak akan bermanfaat. Bukankah itu hanya menguntungkan ketika pergi ke banyak tujuan dari banyak sumber?
tbenz9

Saya mempertimbangkan untuk menyarankan pendekatan ini (memecah file input menjadi potongan-potongan, mengirimkannya secara terpisah, dan menyusunnya kembali di ujung yang lain) dan saya tidak dapat menemukan cara untuk menjadikannya kinerja yang netral, apalagi perbaikan. Anda masih memiliki jumlah waktu transfer jaringan yang sama, tetapi Anda memiliki overhead yang lebih banyak di setiap ujungnya. Ini pada dasarnya mengharuskan menyalin file dari mesin sumber ke mesin sumber , kemudian menyalinnya ke mesin tujuan, & kemudian menyalinnya dari mesin tujuan ke mesin tujuan . Bahkan dengan disk RAM besar, ini tidak gratis.
Scott

1
Satu-satunya manfaat dari pendekatan ini adalah kemampuan untuk memulai kembali, termasuk pemulihan yang lebih cepat dari kegagalan transmisi. OP tidak mengatakan seberapa sering ia mengalami kegagalan, dan tidak menunjukkan bahwa ini adalah sesuatu yang ia inginkan dioptimalkan.
Scott

@ tben9 Bittorrent adalah alat pilihan saat ini untuk transfer file tunggal. Memiliki informasi hash dengan file berarti bahwa klien akhir dapat memverifikasi data yang diunduh dan memperbaikinya jika perlu. Banyak sumber untuk kecepatan. Jadi, ya, dalam hal ini bermanfaat untuk menggunakan BT untuk memastikan file ditransfer dengan benar.
Undervers
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.