Linuxでは、「blockdev --flushbufs」と「sync」の違いは何ですか？

ファイルシステム階層を介さずにドライブ（ddなど）にI / Oが行われた場合、同期は本当に効率的ではありませんか？

これは次の質問を投げます：デバイスノードへの書き込みは「ファイルシステム階層」を迂回します。ある意味では明らかにそうだと思いますが…

とにかくそれは問題ではありません。キャッシュに関連しないタスクを実行する場合、そのsyncタスク（または同様のタスク）を実行するのはとにかく「非効率的」ではありません。同期する項目がない場合は、マイナーな呼び出しです。

いつ他のものを使うべきですか？

私はこれが特定のパーティションを目指したいときにblockdev意味があると思います。sync他の方法に比べて特別な利点があるとは思わない（またはその逆）。

blockdev --flushbufsデフォルトのドライバ/ハードウェアによって実装されると、デバイス自体の書き込みバッファがフラッシュされます。エンタープライズハードウェアブロックデバイスでは、ダーティライトバッファは通常、バッテリがサポートされていない限り保持されず、ハードウェアを移動またはバッテリを交換する前にまだフラッシュする必要があります（この操作は通常、シャットダウンプロセスの最後に自動的に実行されます。）終了またはリセット前)。

ほとんどの企業および高度なデスクトップメカニカルドライブには、書き込みキャッシュを実行するかどうかを設定できる読み取り/書き込みキャッシュがあり、これはこのioctlを使用してフラッシュされるキャッシュです。同期を実行した後でも、USBまたはeSATAに接続されているブロックデバイスを取り外す前に、すべてのデータがフラッシュされていることを確認すると便利です。

このioctlは常に信頼できるわけではなく、一部のドライバやデバイスは実装不足や呼び出しを傍受する可能性があります。 IIRC以前のLVMも論理ボリュームで使用されている場合、このioctlを傍受し、物理デバイスを更新できません。

sync()/syncfs()/fsync()/fdatasync()他の目的があり、記録されていないすべてのデータ/メタデータをデバイスに再同期します。このデータには、ダーティmmap()ページ、VFSレイヤのダーティバッファ、およびコミットされていないファイルシステムの変更を含めることができます。fdadasync()特定のファイルのデータのみがフラッシュされるため、これはデータの変更をフラッシュする最も効率的な方法です（必要でない場合は、ファイルサイズの変更などの一部のメタデータ更新がまだ遅延する可能性があります）。他のすべてのsync()呼び出しは、ファイル、ファイルシステム、またはすべてのファイルシステムからすべてをフラッシュします。データが重要だと思われる場合は、データを同期することがプログラムの作業でなければなりません。すべてが正しく記録されていることを確認するために完全な同期呼び出しに頼る必要がある場合、明らかにはるかに効率的ではありません（プログラムは特定のsyncファイルシステムまたはファイルデータを同期させることもできます）。 、よりman sync）。

ターゲットがデバイスを削除することであり、デバイスをマウント解除できる場合は、同期する必要さえありません。ファイルシステムをアンマウントすると、OSレベルですべてのバッファがすでにフラッシュされます（大きなblockdev --flushbufs書き込みキャッシュがあり、すぐにデバイスを切断した場合）。それでも必要かもしれません）。システムの状態が悪く、削除できない場合は、再起動する前に同期するのがおそらく次善策です。

fsckさらに、ブロックデバイスの書き込みキャッシュは簡単にデータ損失につながる可能性がありますが、ほとんどの最新のジャーナルファイルシステムは、停電後も実行する必要がないほどうまく処理します（ファイルシステムのジャーナルには既知の状態に変更されたメタデータがあります）。 OTOHこれはファイルシステムのファイルデータには当てはまらないことが多く、誤って設計されたアプリケーションが正しく更新されないとファイルが破損する可能性があります。