SSH経由のRsyncを使用して、複数のサーバーから単一のリモートホストにファイルを転送する必要があります。ただし、--remove-from-sourceパラメータを使用してソースからファイルを削除する前に、転送されたファイルが実際に存在することを確認する必要があります。
私が読んだところによると、送信後のチェックサムはなく、rsyncはカーネル応答を信頼しますが、その記事の日付は2005-2009年です。最近のrsyncアップデートでこれが変更されたかどうか疑問に思います。そうでない場合は、それを確認して確認後にソースファイルを削除する方法はありますか?
編集:これがどのように重複しているのかわかりません。私の問題は、同じシステムのローカルドライブとは関係ありません...
答え1
一般化する:rsyncがディスクにデータを書き込むと、失われることなく実行されます。しかし、完全に確信するためにデータは実際にディスクに書き込まれます。fsync.diff
、パッチを適用するか、sync <files>
後で電話する必要があります。
SSH供給データの整合性- 受信したデータは送信したデータと同じです。だからネットワーキングをするのです。
その後、rsyncはwrite
システムコールを使用してカーネルにデータをディスクに書き込むように要求します。また、ハードドライブに障害が発生しない限り(別の問題)、データの整合性を維持します。
しかし、次に、データが実際にディスクにあることを確認してください。迷惑なことにそれほど簡単ではありません。これwrite
マニュアルページ次の説明を試してください。
write() の成功した戻り値は、データがディスクにコミットされたことを保証しません。実際、いくつかのバグがある実装では、データスペースが正常に予約されたという保証さえありません。唯一の確実な方法は、すべてのデータが記録された後にfsync(2)を呼び出すことです。
私ダウンロード最新の(3.1.2pre1)rsyncソースコードであるgreppedではfsync
結果が出ませんでした。デフォルトでは、rsyncは呼び出されません。fsync
(メタデータのないバージョンも見つかりましたfdatasync
。なし)。つまり、write
これらの操作が完了したかどうかはファイルシステムによって異なります。
解決策として、次のことができます。
Runは与えられたファイルを
sync <files>
呼び出します。fsync
戻ってくると、彼らは間違いなくディスクにいます。rsyncソースパッチディレクトリをダウンロードします(別途ダウンロードとして提供されています)。
fsync.diff
Sami Farinのパッチを適用します。 "私たちが作成するすべてのファイルでfsync()を呼び出すには、--fsyncを指定できます。 (これが今後はデフォルトになることを願っています。)
普通でも、最新のファイルシステムは、IO負荷が高いときにキャッシュフリーをしばらく使用して書き込みを非常にすばやく完了します。システムがわかっている場合は、この手順をスキップできます。しかし、より幅広く使用するためのコードを書くときは、結果はファイルシステム、チューニング方法、ドライブのファームウェアに対する神の慈悲にかかっている可能性があることに注意してください。