スパースファイルがあります。（du -h3Gをdu -h --apparent-size報告し、100G を報告します。）これまでのところ、とても良い。
今、を使用してファイルを圧縮するtarか、ネットワーク経由で送信rsyncする場合、3Gと同じくらいの時間がかかります。これらのツールはすべてゼロを読み取るようです。
穴はどういうわけかマークされていて、これらのツールはどういうわけかそれらをスキップできると思いましたか？
私のファイルにはおそらく問題はありませんか？
これはスパースファイルの欠落機能でtarありrsync、スパースファイルを検索しないのですか？tarパラメータを使用しました--sparseが、速度は向上しませんでした。rsyncパラメータもしませんでした--sparse。
スパースファイルでこれらのツールを高速化する方法はありますか？
回答:
bsdtar（少なくともlibarchive3.1.2以降）はFS_IOC_FIEMAP、それをサポートするファイルシステムでioctlを使用してスパースセクションを検出できます（ただし、他の多くのAPIもサポートします）。ただし、少なくとも私のテストでは、奇妙なことに、tarそれ自体が生成するファイルを処理できません（ただし、バグのように見えます）。
ただし、GNU tarを使用してそれらを抽出することはできますが、GNU tarは、bsdtarがサポートする拡張属性の一部を処理できません。
そう
bsdtar cf - sparse-files | (cd elsewhere && tar xpf -)
ファイルに拡張属性またはフラグがない限り、機能します。
FS_IOC_FIEMAPioctlが0のエクステントを返し、それがbsdtar適切に処理されないように見える（別のバグ？）ため、完全にスパース（ゼロのみ）のファイルではまだ機能しません。
star（Schily tar）は、スパースファイルを検出できる（-sparseオプションを使用）もう1つのオープンソースtar実装であり、それらのバグはありませんbsdtar（ただし、多くのシステムではパッケージ化されていません）。
この記事にはrsync、少なくとも次のようないくつかの役立つ提案があります。
問題
を使用
rsync --sparse worksしますが、不要なディスク書き込みが大量に発生します。50GBの長さ（1GBを使用）で10バイトを変更すると、1つまたは2つのブロックのみが書き込まれ、1GBが書き込まれます。これは低速であり、ディスクの寿命にとって好ましくない可能性があります。使用は
rsync --inplace機能しますが、非スパースファイルが作成されます。--sparseと--inplaceを同時に使用することはできません:-(これはrsyncでは許可されていません。
解決
--inplaceを使用して既存のスパースファイルを更新すると、ファイルはスパースなままで、少数のブロックのみが書き込まれます。rsync --inplaceがファイルを作成するときのみ、非スパースになります。
したがって、解決策は、ソースマシン上のすべてのファイルについて、対応する正確な長さの空のスパースファイルをターゲットマシンに作成することです（ファイルがまだターゲットマシンに存在しない場合）。
次に、rsync --inplaceは意図したとおりに機能し、スパースファイルをスパースにして、変更されたブロックのみをディスクに書き込みます。
したがって、私がそれを正しく読んだ場合、最初にターゲット上に空のスパースファイルを作成する必要があります。あなたはこれを行うことができます
truncate -s 3G filename
次に、を使用rsync --inplaceしてファイルをコピーできます。これは一度だけ必要です。
同じ記事は、Virtsyncの使用を提案しています
巨大なファイル（仮想マシンのディスクイメージやデータベースなど）のコンテンツを同期するための49ドルの商用Linuxコマンドラインツール。
これは、この種の状況のために特別に書かれているように見えるので、お金を払う気があるなら、最善の解決策かもしれません。