でデータ（200 GBのホームディレクトリ）をバックアップしているときにrsync、特定のファイルでI/0エラーが発生しました。その後、rsyncバックアップは「通常通り」続行されました。問題のあるソース ファイルのファイル サイズは 72 バイトと表示されました。
キャンセルしました rsync同じコマンドを再度実行しました。今度は同じファイルがデータを転送していることが示されました。大量のデータ...そしてさらにデータが増えて... 保存先のファイルのサイズを確認したところ、最大13GBでした！そこでCtrl-Cでキャンセルしましたrsync。
Nautilus でソース ファイルのサイズを再度確認すると、60.0 PB500 GB ドライブで (ペタ バイト!) のサイズが表示されました。
さて、このすべての要点は、ファイル システムがこのファイルを実際よりもはるかに大きいと認識するため、このファイルを削除すると他のファイルのデータが失われる可能性があるかどうかです... ファイル システムはext4...
それを飛ばしてrsync例外ですが、削除された場合に何が起こるのかに特に興味があります。
更新: ターゲットとソースの両方がext4
スパースファイルであるという示唆について：もしそれがスパースファイルなら、なぜ1分ごとにサイズが異なるのでしょうか？そのファイルは当時は使われていなかったはずです。それは~/.macromedia/Flash_Player/#SharedObjects/someting-or-other.sol、多くのもっとそのような。ソルそのディレクトリ内のファイル...さらに、最初のパスで I/0 エラーが表示されました。
また、によるとman rsync、推奨される-Sオプションはスパースファイルを処理することである。効率的に、 ないきちんとつまり、私が使用していなかったとしても、-Sどちらの場合でもスパース ファイルを正確にコピーするはずだということになります。しかし、実際にはそうはなりませんでした。スパース ファイルであっても、60.0 ペタ バイトであることは、どこかのファイル システムのエラーであるように思われます... これが私の主な懸念事項です。ファイル システムに不具合がある場合、そのファイルを削除すると他のファイルに影響が出る可能性があります。
もっと具体的に言うと、キャンセルしたときに「13 GB のデータがあり、増加中！」と表示されたので、削除すると 13 GB - 60 PB のデータも削除されるのでしょうか?
答え1
ソース ファイルシステムが破損しているようです。通常はカーネルのバグまたは RAM の不良が原因です (ディスクが破損すると、データが破損するよりもファイルが読み取れなくなる可能性が高くなります)。この時点では、何が起こるかわかりません。ただし、破損が非常に局所的である場合は、破損しているのは 1 つのファイルの inode のみで、他のファイルは破損していないため、ファイルを安全に削除できます。この仮定をテストする方法はないことに注意してください。
私の推奨事項は次のとおりです。
- RAM テストを実行するか、ディスクを別のマシンに接続します。
- すべてのデータをバックアップしたことを確認してください。
- 可能であれば、SMART を使用してディスクの状態を確認します。
- 走る
fsck。 - ディスクがまだ良好な場合は、そのまま使用してください。
答え2
それはスパースファイル-Sファイルが可能な限り適切に処理されるように、の使用を検討する必要があります。
答え3
これはおそらくスパースファイル（そうでない場合は、実行を開始してください今！）そうではない実はこのスペース全体を占める穴があります。おそらく大きな穴が 1 つあるでしょう。
ターゲット側から削除しrsync、-S(sparse) オプションを追加して、rsyncスパース ファイルが認識され、処理されることを確認します。
ターゲットファイルシステムの種類はスパースファイルをサポートするも同様です。(短いバージョン: ext[234]NTFS では可能ですが、FAT では不可能です)