私はアップロード（圧縮を含む）を除いて実際にtarball / archivedを使用したことがありません。今、私はソフトウェアプロジェクトのための多数のコーディング実験を蓄積しました。デフォルトでは、家をバックアップしたり、他のデバイスの同期操作を実行したりすると、速度が遅くなるように見える多くの小さなファイル（主にソースコードファイルとgitオブジェクト）を含むディレクトリ（私は主にUSBケーブルを介してrsyncを使用します）。
これが文書化された現象（ベンチマーク？）なのか気になります。触れていない長いプロジェクトディレクトリを圧縮すると作業速度が速くなりますか？これは賢明なアプローチですか？
ext4ファイルシステムを使用しています。
答え1
古い、ほとんどアクセスしないディレクトリをtarballに保存すると、ファイルベースのバックアップシステムのパフォーマンスが確実に向上する可能性があります。
これが文書化された現象かと思います（ベンチマーク？）。
これは実際には「ロギング」ではありませんが、バックアップが必要かどうかを確認するためにファイルシステムをチェックし、各ファイルを個別にチェックする必要がある自然な結果です。
バックアップの頻度を減らすことができますFaheem Mithaが提案したようにただし、異なる頻度で複数のバックアップを維持したり（頻繁に更新されるコンテンツや以前にアーカイブされたコンテンツの場合）、ファイル除外リストなどを維持するのは面倒です。近い将来、これらのディレクトリにアクセスする予定がない場合は、パッケージ化するのが非常に良い考えだと思います。私は同じ理由でこれを何度もやってきました。
答え2
私は複製されたリポジトリのディレクトリ（多くの小さなファイル）で小さなベンチマークを実行しました。
パラメータは次のとおりです。
17002 files
4.9G
46 root directories
tar command: tar cf (no compression)
rsync command: rsync -aH --delete --stats
結果：
空のディレクトリのローカルrsync（圧縮解除されたファイル）：
real 5m36.447s
user 0m34.692s
sys 0m56.390s
Second local rsync (unpacked files):
real 0m6.810s
user 0m2.257s
sys 0m3.363s
タール時間：
real 1m14.648s
user 0m14.278s
sys 0m2.175s
空のディレクトリのローカルrsync（圧縮解除されたファイル）：
real 2m6.355s
user 0m20.799s
sys 0m21.122s
空のディレクトリのローカルrsync（パッケージファイル）：
real 0m0.125s
user 0m0.005s
sys 0m0.011s
そのため、タール処理をすると性能が大幅に向上するようです。驚くべきことに、圧縮+2番目のローカルrsyncは、最初のローカルrsyncよりも合計時間がかかりませんでした。
さらに、Tarring はランダムな rsync 実行速度を大幅に向上させます。
圧縮によって炭化も試みた。タールを塗るのにgzip10分ほどかかりましたが、lzopあまり良くなりませんでした（7分くらいで止まりました）。美しいチャートによるとhttp://www.linuxjournal.com/article/8051?page=0,2、使用したい最も遅いリンクがUSBケーブル（約20MBps）の場合、圧縮しても帯域幅は向上しません。
答え3
Rsyncは毎回これらのすべてのファイルとフォルダを確認する必要があります。これは時間、パフォーマンス、およびネットワーク負荷を消費します。各項目をtarballに入れると、何千ものスキャンではなく1つのファイルスキャンを意味します。また、スペースも節約されます。