空の生ブロックデバイスにファイルを書き込むたびに。
# dd if=image.iso of=/dev/sdb status=progress
私はいかなるタイプも使用したことがありませんsync（例：sync;;;;）。conv=fsyncconv=fdatasyncoflag=syncoflag=dsync
私はこれではddないことがわかりました。一度すべての書き込みが完了するまで終了します。
私はいつもConkyのI / Oツールを使用していますがgrep Dirty /proc/meminfo、デバイスのチェックサムは常にそのデバイスに作成されたファイルのチェックサムと一致します。したがって、私は常にファイル全体がデバイスに書き込まれたと確信しています。
比較のために、ファイルをext4ボリュームに書き込んだ。たとえば、次のようにします。
$ dd if=/dev/urandom of=~/file bs=1M count=50 iflag=fullblock
ext4ボリュームに書き込むとき、ddデータが実際にディスクに書き込まれる前にシャットダウン後、常に約20秒の遅延があります。
多くの人は、ブロックデバイスに書き込むときにコマンドの後にこのコマンドを使用するか、コマンドにいくつかのsyncオプションddの1つを含めることを勧めます。例えばsyncddここそしてここ。しかし、私はこれが必要であることを実際に証明した人をまだ知っていません。
コメントの1つはこのページ例:
syncここでは意味がありません[つまり、直接作成/dev/sdX]。ファイルシステムの操作にのみ影響します。
5人がこのレビューに同意しましたが、これは私の経験と一致しています。
ddそれでは、ブロックデバイスへの書き込み時にすべての書き込みが完全に完了する前に終了する状況はありますか？このようなことは本当に誰にでも起こりますか？
などの他の書き込みオプションはcpどうですかcat？ブロックデバイスへの書き込みが完了する前に終了できますか？
ベストアンサー1
今この質問に答える時間です。
長い間、私はブロックデバイスではなくファイルシステムへの書き込みだけがキャッシュされていると思いましたが、わかりましたが、私の考えは間違っていました。ブロックデバイスへの書き込みはキャッシュされます。。
技術的に言えば、公式ソースを明らかにして回答を受け取ったら、更新します。しかし、ここでいくつかの情報を見つけることができます。linux - ブロックデバイスキャッシュとファイルシステム。申し訳ありません。あなたもこの質問を見たことが確認されました。
実際に画像をUSBスティックに追加してから、操作が完了したら取り出すのに問題があり、画像が破損していることがわかりました。完全な同期がデバイスで最後に完了したように見えるため、これを行うことはできませんclose()。そのため、デバイスにデータが破損しているか、まだブロックデバイスが開いているプロセスがありません。しかし、どちらにしてももう冒険しないでください。
はい。ブロックデバイスに書き込むときに同期オプションを追加することはdd都市伝説ではないようです。私はconv=fdatasyncこれで十分で最高のパフォーマンスを発揮する必要があると思います（最終的にはファイルメタデータは追加されず、プロセスの終わりに同期するだけです）。しかし、私たちの極端主義者はoflag=sync（すべての書き込み後にデータ全体とメタデータを同期させる）を好むかもしれません。確認して、man 2 openよりman 2 fdatasync多くのインサイトを入手してください。
私が読んだところ（残念ながらまだ正式なものはありません）、デバイスが起動したときにいくつかのSYNCフラグを使用して明示的に要求しない限り、他のプロセスがまだ開いているcp場合、ブロックデバイスは同期する前に実際にシャットダウンする可能性があります。はい、またはもっと誇張して言うと、これらのコマンドのどれもありません...catopen()fdatasync()fsync()sync()