rsyncとxfr＃1、to-chk = 0/1、これはどういう意味ですか？ [コピー]

問題が解決しました——

-z, --compress              compress file data during the transfer
    --compress-level=NUM    explicitly set compression level

この部分が面白い部分のようです。

    --progress

このオプションは、rsync に転送の進行状況を示す情報を印刷するように指示します。これは退屈なユーザーに見どころを提供します。最新の rsync の場合、これは以下を指定するのと同じです。

    --info=flist2,name,progress

ただし、これらの情報フラグに対してユーザーが提供したすべての設定が優先されます（例： " --info=flist0 --progress"）。

rsync が通常のファイルを転送すると、次の進行行を更新します。

782448  63%  110.64kB/s    0:00:04

この例では、受信者は送信者ファイルの63％である782448バイトを再構築しました。これは毎秒110.64KBの速度で再構築されており、現在の速度を最後まで維持すると4秒で転送が完了します。

rsyncの増分転送アルゴリズムを使用している場合、これらの統計は誤解を招く可能性があります。たとえば、送信者のファイルが基本ファイルと追加データで構成されている場合、受信者がリテラルデータを受信すると報告された割合が急激に低下する可能性があり、受信者がファイルの完了にかかると予想するよりも転送が完了しましたするのにはるかに長い時間がかかることがあります。 。一致する部分。

ファイル転送が完了すると、rsync は進行状況行を次の要約行に置き換えます。

1,238,099 100%  146.38kB/s    0:00:08  (xfr#5, to-chk=169/396)

この例では、ファイルの長さは合計1,238,099バイトであり、ファイル全体の平均転送速度は1秒あたり146.38KBで8秒以内に完了します。今回の期間の5番目の正規ファイル転送です。 受信者がチェックできるように、169個のファイルが残っているrsyncセッション （最新バージョンであることを確認してください）残り396件中 ファイルリスト内のファイル。

増分再帰チェックでは、rsync はスキャンが完了するまでファイルリスト内のファイルの総数を知ることはできませんが、スキャン中にファイル転送を開始するため、「ir-chk」というテキスト行を表示します。 （増分再帰チェックの場合）リストの合計サイズがわかるまで、「to-chk」の代わりに「to-chk」を使用するように切り替えます。したがって、「ir-chk」を見ると、ファイルリスト内のファイルの総数が増え続けることがわかります（そして、ファイル数が増えるたびに、リストに追加されたファイルの数に応じて確認する必要がある残りのファイル数が増えます）。 。