これは拡張ですrsyncがすでに最新のファイルをコピーしようとしているのはなぜですか？
--copy-devicesこのパッチを使用してrsyncディスクドライブ全体をコピーし、別のコンピュータに画像として保存しようとします。
コピーが正常になるようですが、rsync同じ値で再実行すると、毎回一部のデータが再コピーされるようです。
私はrsync詳細を持って実行し、これを得ました：
$ sudo rsync -vvz --partial --progress --copy-devices /dev/sdb me@otherserver:/backupdisks/mydisk.img
opening connection using: ssh -l me otherserver rsync --server -vvze.Lsfx --partial --copy-devices . /backupdisks/mydisk.img (11 args)
me@otherserver's password:
delta-transmission enabled
sdb
320,071,851,520 100% 63.47MB/s 1:20:09 (xfr#1, to-chk=0/1)
total: matches=2441955 hash_hits=2441955 false_alarms=204015955 data=0
sent 188 bytes received 21,979,001 bytes 2,837.31 bytes/sec
total size is 0 speedup is 0.00
rsyncは時間の経過とともに変更を決定しますが、ディスクはrsync間で変更されないことを知っています（ディスクの修正時間をどのように決定しますか？）。ただし、リモートイメージの時間は毎回更新されます。だからこれが問題になる可能性があります。
もう1つの可能性は、ディスクに不良セクタがあるため、毎回異なる値を返し、使用中のチェックサムが無効になることです。
私の質問は2つあります。
私の画像は正常に送信されましたか？それでは、再実行時にほとんどのディスクを再送信するのはなぜですか？ （これは私の推論の質問の一部として部分的に答えることができます。rsync出力の「matches」、「hash_hits」、「false_alarms」とは何ですか？「data = 0」は成功を意味しますか？)
これを行うために欠落しているスイッチはありますか？ （おそらく
--checksum？）rsyncアルゴリズムで使用されるブロックレベルのエラーを一覧表示することは可能ですか？
ベストアンサー1
デフォルトでは、rsyncはサイズとタイムスタンプに基づいてファイルを比較しますが、デバイスにはサイズがないため、このセクションで説明する違いを計算するにはデルタアルゴリズムを使用する必要があります。技術レポート。概して、リモートファイルは選択されたサイズのチャンクに分割され、これらのチャンクのチェックサムが再送信されます。ローカルファイルもブロック単位でチェックサムされ、リストと比較されます。その後、リモートデバイスは、ファイルを再作成するためにチャンクを再構築し、一致しないチャンクに関するデータを送信する方法を通知します。
optionsを使用してデルタサムアルゴリズムに対してのみレベル3でデバッグ出力を要求すると、それを確認できます--debug=deltasum3。-B数値を単純化するためにブロックサイズを指定できます。たとえば、一度コピーしたファイルの場合は、2番目に実行します。
rsync -B 100000 --copy-devices -avv --debug=deltasum3 --no-W /dev/sdd /tmp/mysdd
各ブロックのチェックサムを示す次の出力を生成します。
count=164 rem=84000 blength=100000 s2length=2 flength=16384000
chunk[0] offset=0 len=100000 sum1=61f6893e
chunk[1] offset=100000 len=100000 sum1=32f30ba3
chunk[2] offset=200000 len=100000 sum1=45b1f9e5
...
これは違いがないので、非常に簡単に他のデバイスのチェックサムと一致することを確認できます。
potential match at 0 i=0 sum=61f6893e
match at 0 last_match=0 j=0 len=100000 n=0
potential match at 100000 i=1 sum=32f30ba3
match at 100000 last_match=100000 j=1 len=100000 n=0
potential match at 200000 i=2 sum=45b1f9e5
match at 200000 last_match=200000 j=2 len=100000 n=0
...
最後に、このdata=フィールドはゼロで、新しいデータが送信されないことを示します。
total: matches=164 hash_hits=164 false_alarms=0 data=0
これでファイルの中央部分を上書きしてコピーを破損した場合：
echo test | dd conv=block,notrunc seek=80 bs=100000 of=/tmp/mysdd
touch -r /dev/sdd /tmp/mysdd
その後、rsync デバッグを通じてブロック 80 の新しいチェックサムが表示されましたが、一致するものはありませんでした。ゲーム79からゲーム81に進みます。
chunk[80] offset=8000000 len=100000 sum1=a73cccfe
...
potential match at 7900000 i=79 sum=58eabec6
match at 7900000 last_match=7900000 j=79 len=100000 n=0
potential match at 8100000 i=81 sum=eba488ba
match at 8100000 last_match=8000000 j=81 len=100000 n=100000
最後に、data=100000まったく新しいデータブロックを転送する必要があることを示します。
total: matches=163 hash_hits=385 false_alarms=0 data=100000
一致しない破損したブロックチェックサムの場合、一致の数が1つに減少しました。おそらく、シーケンシャルマッチングを失うため、ハッシュヒット率が高くなった可能性があります。
私たちが見るともっと遠く同じ技術レポートにはいくつかのテスト結果が表示されます。偽の肯定 「32ビットローリングチェックサムは一致しましたが、強力なチェックサムは一致しませんでした」と説明されています。各ブロックには単純なチェックサムとmd5チェックサム（以前のバージョンではmd4）があります。単純チェックサムは32ビット整数なので、ハッシュテーブルを使用して簡単に検索できます。エントリが一致すると、より長い16バイトのmd5チェックサムが比較されます。一致するものがない場合、偽の肯定が報告され、検索が続行されます。
私の例では、非常に小さい（そして古い）16 MB USBキーデバイスを使用し、最小ハッシュテーブルサイズは2 ** 16（65536項目）なので、私が持っている164ブロック項目を保存するときは非常にnullです。このように多くの誤った肯定は正常な現象であり、何よりも効率性を示しています。