rsyncさまざまなパフォーマンス問題がありました。同期を実行できませんでしたO(#changes)。チェックサムの代わりに変更時間を使用しても、変更されたすべてのファイルのリストを作成する必要があるため、数時間かかり、任意の制限に達する可能性があります。ただし、たとえば、記録中にコピーファイルシステムを使用すると、ハードドライブを再スキャンするのに数分（または数時間）のオーバーヘッドなしですぐに「最小」差を転送できます。
もちろん、次のアルゴリズムを使用すると可能です。
my-ideal-rsync --modified-since "2020-10-10 12:00:00"各フォルダを再帰的に見て、フォルダの最後の修正時間（該当時間以降に修正された場合）を確認し、O（ディスク上の＃ファイル）ファイル）時間リスト/転送/ストリームの代わりに最適なO（修正ファイル＃個）時間を確認してください。変更されたファイルは、指定されたコマンドで最後に送信されました。あるいは、
my-ideal-rsync2各システムのフォルダを固定された方法で再帰的に比較して、上記のフラグなしでこれを達成することもできます。ルートから繰り返し開始して、すべての子inodeをペア（ソース、ターゲット）にソートします。
- ソース inode の最後の変更時刻が同じ場合、再帰はありません。
- ソースinodeの最後の修正時間が最新の場合は繰り返し（ディレクトリの場合）（または転送（ファイルの場合））
- ソース inode の最後の修正時間が古い場合、エラーが発生します。
- ソースまたはターゲットinodeが欠落している場合は、可能な
mv操作のためにキューに入ります。つまり、可能な一致キューです。
- （再帰終了時に一致するものがない場合は、それぞれ削除または作成してください。）
上記のアルゴリズムにバグがあるかもしれませんが、これは概念を示しています。そんなことありますか？
答え1
ディレクトリの変更時間はファイルの変更時間とは関係ありません。 – Emma Luo 1月29日7時41分
ディレクトリ変更時間（少なくともext4など）に対する私の誤解のために、「サブディレクトリのファイル変更」時間を提供するファイルシステムを使用しないと、そのようなアルゴリズムは不可能になるようです。 （または後でrsyncへの変更を追跡するためにファイル変更デーモンが実行されていない限り、fsを読み取り専用に設定してください... duh。）
今の質問に答えるには、「これらのアルゴリズムはおそらく通常のファイルシステムでは元に戻すことはできません。なぜなら、dir mtimesはファイルmtimesから独立しているからです。btrfs send
答え2
rsyncプログラムはそうではありません記録違いがあるため、ディレクトリツリー全体を検索する必要があります。
これとは対照的に、gitバージョン管理システムはファイルとディレクトリに対する修正を追跡し、すべての履歴を維持するので、これはあなたが必要とするものかもしれません。