一部のファイルコピープログラムは、失敗した転送/コピーを回復する可能性rsyncがあります。curl
このような失敗にはいくつかの原因があり、場合によってはプログラムが「クリーンアップ」し、場合によってはそうでない場合があります。
これらのプログラムが再起動すると、正常に転送されたファイル/データのサイズを計算してから、ソースから次のバイトを読み取ってファイルの断片に追加し始めるようです。
たとえば、ターゲットに「到着」するファイルスライスのサイズは1378バイトなので、元のファイルの1379バイトから読み取ってスライスに追加するだけです。
私の質問は、バイトがビットで構成されており、すべてのファイルがデータをクリーンなバイトサイズのチャンクに分割するわけではないことを知っていますが、これらのプログラムがデータの追加を開始することを選択したポイントが正しいかどうかはどうすればわかりますか？
ターゲットファイルに書き込むと、プログラム、カーネル、またはファイルシステムレベルで一種のSQLデータベースに似たバッファリングまたは「トランザクション」が発生し、きれいで正しい形式のバイトのみがデフォルトのブロックデバイスに渡されますか？
それとも、プログラムで最新のバイトが不完全であると仮定して破損していると仮定して削除し、バイトを再コピーしてからそこから追加を開始しますか？
すべてのデータがバイトで表されるわけではないことがわかると、これらの推測は間違っているようです。
これらのプログラムが「再開」したら、正しい場所から始まったかどうかはどうすればわかりますか？
ベストアンサー1
明確にするために、実際のメカニズムは、より良いセキュリティを提供するためにより複雑です。次のディスクへの書き込み操作を想像できます。
- 申請書の作成バイト(1)
- カーネル（および/またはファイルシステムIOSS）はそれをバッファリングします。
- バッファがいっぱいになるとフラッシュファイルシステムへ：
- ブロックが割り当てられました(2)
- ブロックが作成されました。 (3)
- ファイルおよびブロック情報の更新(4)
プロセスが(1)で中断されると、ディスクには何も残らず、ファイルはそのまま残り、前のブロックで切り捨てられます。 5000バイトを送信し、ディスクには4096バイトのみがあり、オフセット4096で転送を再開します。
(2)の場合、メモリ以外には何も起こりません。 (1)と同じです。 (3)の場合、データが記録されます。しかし、それを覚えている人は誰もいません。。 9000バイトを送信し、4096バイトを記録し、4096バイトを記録しました。そして道を失った、残りは失われます。転送はオフセット４０９６で再開される。
（4）段階にある場合は、データをディスクにコミットする必要があります。ストリームの次のバイトが失われる可能性があります。 9000バイトが送信され、8192バイトが記録され、残りは失われ、転送はオフセット8192で再開されました。
これは簡単に取る。たとえば、手順3〜4の各「論理的」書き込みは「原子的」書き込みではありませんが、チャンクをターゲットデバイス（ハードディスクなど）に適したブロックに分割する別のシーケンス（＃5で指定）を生成します。 ) はデバイスのホストコントローラに送信されます。キャッシュ機構もあります。、最終的にディスクに保存されます。このサブシーケンスは常にシステムで完全に制御できるわけではないため、データをハードディスクに送信することは、そのデータが実際に書き込まれ、再読み込みできることを保証しません。
複数のファイルシステムの実装日記を書く、最も脆弱な点（4）実際に脆弱なメタデータを作成すると推測できるように取引（5）段階で何が起こっても一貫して動作します。
トランザクション中にシステムがリセットされると、最新の完全チェックポイントに戻すことができます。作成されたデータは（1）と同様に失われますが、回復するとこの問題は解決されます。いいえ情報実際に迷子になりました。