$ rsync -aPhmS /mnt/data/ /mnt/data1/
今日、一部のデータのコピー中に奇妙な問題が発生しました。
--sparsersync フラグは、使用時に予想よりはるかに遅く実行されます。
time rsync --sparse
real 4m8.791s
user 0m23.558s
sys 2m43.257s
time rsync(-s を除く)
real 2m32.607s
user 0m39.175s
sys 1m33.885s
time cp
real 2m31.811s
user 0m0.254s
sys 0m52.627s
進行状況を監視すると、数秒ごとに書き込みが停止し、転送速度がゼロに低下します。
iostat報告されたデバイス利用率は約50〜60％です（上記の時間と一致 - 時間が速いほど約50％遅くなります）。
なぜこれが起こるのですか？
このパフォーマンスの問題に対する修正や回避策はありますか？ （-Sがないことを除いて、このフラグは一部のデータにスパースファイルが含まれているために存在します。）
断片的なソリューションを想像できます。何らかの方法ですべてのスパースファイルを検出し、すべてのスパースファイルとすべてのスパースファイルのリストを作成し、そのリストからrsyncを2回実行します。 （しかし私はLinuxに初めて触れたので、そのようなスクリプトは私の能力をはるかに超えています。）
rsync バージョン 3.2.7 プロトコル バージョン 31
ベストアンサー1
--sparseforフラグがあるのは、rsyncターゲットにスパースファイルを作成できることを確認するために、コピーしたいすべてのファイル（スパスファイルだけでなく）を分析する必要があることです。
ここに例があります。 1GBファイルを作成しました。いいえ不足しています。
$ dd if=/dev/zero of=bigfile bs=1G count=1
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.65238 s, 1.6 GB/s
$ ls -lsh bigfile
1.0G -rw-r--r-- 1 root root 1.0G May 28 17:18 bigfile
rsync --sparse次のようにこのファイルをコピーすると、〜するソースが希薄でなくても。
$ time -p rsync --sparse bigfile bigfile.sparse
real 2.88
user 4.19
sys 0.56
$ ls -lsh bigfile.sparse
0 -rw-r--r-- 1 root root 1.0G May 28 17:19 bigfile.sparse
これはrsync、ファイルを「スパース」する方法を見つけるためにファイルを分析する必要があることを意味します。ターゲットから潜在的に「まれな」空のスペースブロックを検索する必要があります。これには追加の計算時間が必要です。
ところで、すでにリーンファイルにも同じことを行います。完全な「抽出された」ソースファイルを読み取り、同じ分析を実行し、完了した分析に基づいてターゲットに新しいスパースファイルを生成する必要があります。