私は頻繁にVMイメージをハイパーバイザーから長期保存用のアーカイブサーバーに転送します。
Scp、rsyncなどよりも高速なので、netcatを使用して転送します。
hypervisor$ cat foo.box | nc <archive IP> 1234
archive$ nc -l -p 1234 > foo.box
ファイルの転送が完了したら、ターゲットとソースの両方でmd5sum
を実行して、破損がないことを確認します。
残念ながら、大きなファイルでmd5sumを実行すると、非常に長い時間がかかる場合があります。 2つの大きなファイルの整合性をより迅速に比較するにはどうすればよいですか?
更新:
tee を使用して、次のようなものでその場で合計を計算できます(必要に応じてnetcatコマンドを適合させます)。
サーバ:
netcat -l -w 2 1111 | tee >( md5sum > /dev/stderr )
クライアント:
tee >( md5sum > /dev/stderr ) | netcat 127.0.0.1 1111
Nerdwallerの答えtee
を使用して同時にチェックサムを転送および計算することは、主にネットワーク上の破損を心配する場合に適したアプローチです。ただし、ディスクに到達する前にチェックサムを取るため、ディスクへの途中での破損などからユーザーを保護することはできません。
しかし、私は何かを追加したいと思います:
1 TiB/40分≈437 MiB /秒1。
それは実際にはかなり高速です。 lotのRAMがない限り、ストレージから取得する必要があることに注意してください。したがって、最初に確認することは、チェックサムを実行するときにiostat -kx 10
を監視することです。特に、%util
列に注意を払います。ディスクをペギングしている場合(100%に近い)、答えはより高速なストレージを購入することです。
それ以外の場合は、他の投稿者が述べたように、別のチェックサムアルゴリズムを試すことができます。 MD4、MD5、およびSHA-1は、すべて暗号化ハッシュとして設計されています(ただし、これらはいずれもその目的で使用する必要はありません。すべてが弱すぎると見なされています)。速度に関しては、openssl speed md4 md5 sha1 sha256
と比較できます。私はSHA256を投入して、少なくとも1つのハッシュが十分に強力であることを確認しました。
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
上記のうち、MD4が最も速く、SHA256が最も遅いことがわかります。この結果は、少なくともPCのようなハードウェアでは一般的です。
(些細なを改ざんすることを犠牲にして、さらに破損を検出する可能性を低くして)パフォーマンスをさらに高めたい場合は、 CRCまたはAdlerハッシュ。 2つのうち、Adlerは一般的に高速ですが、弱いです。残念ながら、本当に高速なコマンドライン実装については知りません。私のシステムのプログラムはすべてOpenSSLのmd4よりも遅いです。
したがって、速度的に最善の策はopenssl md4 -r
です(-r
はmd5sum出力のようになります)。
コンパイルや最小限のプログラミングを行う場合は、スタックオーバーフローで Mark Adlerのコードを上書き および xxhash を参照してください。 SSE 4.2の場合、ハードウェアCRC命令の速度を超えることはできません。
1 1 TiB = 1024バイト。 1 MiB =1024²バイト。 1000の累乗のユニットで≈417MB/秒に達します。
openssl
コマンドは、いくつかのメッセージダイジェストをサポートしています。私が試すことができたもののうち、md4
はmd5
の時間の約65%、sha1
の時間の約54%で実行されているようです(1つのファイルについてテスト済み)。
ドキュメントにはmd2
もありますが、md5
と同じ結果になるようです。
非常に大まかに言えば、速度は品質に反比例するように見えますが、意図的な衝突を作成する敵が(おそらく)心配していないので、それほど問題にはなりません。
古くて単純なメッセージダイジェストを探し回るかもしれません(たとえば、md1
はありましたか?)
マイナーなポイント: cat
の無用な使用 があります。のではなく:
cat foo.box | nc <archive IP> 1234
あなたは使うことができます:
nc <archive IP> 1234 < foo.box
あるいは:
< foo.box nc <archive IP> 1234
そうすることでプロセスが節約されますが、おそらくパフォーマンスに大きな影響はありません。
2つのオプション:
使用する sha1sum
sha1sum foo.box
状況によっては sha1sumの方が速い 。
rsync
を使用
転送には時間がかかりますが、rsyncはファイルがそのまま到着したことを確認します。
Rsyncのmanページから
Rsyncは常に、ファイルが転送されるときに生成されるファイル全体のチェックサムをチェックすることにより、転送された各ファイルが受信側で正しく再構築されたことを確認します...
科学は進歩しています。新しいBLAKE2ハッシュ関数はMD5よりも高速である(そして、ブートするのに暗号的にはるかに強い)ようです。
リファレンス: https://leastauthority.com/blog/BLAKE2-harder-better-faster-stronger-than-MD5.html
Zookoのスライドから:
Intel Core i5-3210M(Ivy Bridge)のバイトあたりのサイクル
バイトあたりの関数サイクル
long 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
おそらく、良いハッシュ以上のことはできません。他のハッシュ/チェックサム関数をチェックアウトして、md5sum
よりも大幅に高速なものがあるかどうかを確認することができます。 MD5ほど強力なものは必要ない場合があることに注意してください。 MD5(およびSHA1のようなもの)は暗号学的に強力になるように設計されているため、攻撃者/偽者が既存の値と同じハッシュ値を持つ新しいファイルを作成することは不可能です(つまり、署名されたeを改ざんすることを難しくします) -メールおよびその他のドキュメント)。通信への攻撃を気にせず、一般的な通信エラーのみの場合は、巡回冗長検査(CRC)のようなもので十分です。 (しかし、もっと速くなるかどうかはわかりません。)
別のアプローチは、転送と並行してハッシュを実行することです。これにより、全体の時間が短縮される可能性があり、転送が完了するのを待ってから、MD5が完了するのを再び待つ必要があるという苛立ち要因を確実に減らすことができます。私はこれをテストしていませんが、次のようなことができるはずです:
ソースマシン:
mkfifo myfifo Tee myfifo < ソースファイル | nc dest_Hostポート番号 &md5sum myfifo
宛先マシン:
mkfifo myfifo nc -l -p ポート番号 |ティーmyfifo> dest_file &md5sum myfifo
もちろん、ファイルのサイズをチェックすることは、バイトがドロップされたかどうかを検出するための優れた、迅速な方法です。
巨大なファイルを送信するのは面倒です。チャンクごとにハッシュを生成するファイルをチャンクアップしてから宛先に送信してから、ハッシュをチェックしてチャンクを結合してみてはどうでしょう。
個人的なBitTorrentネットワークを設定することもできます。それはすべてが安全に到達することを保証します。