今日、私はFreeBSDがブロックデバイスのサポートを完全に削除したことを知りました。この決定の根拠を読んで、私は次の事実を見つけました。
ブロックデバイスは、カーネルがキャッシュを提供するディスクデバイスです。このようなキャッシュは、ブロックデバイスをほとんど使用できないようにするか、少なくとも危険なほど信頼できないものにする。キャッシュは書き込み操作の順序を再指定し、アプリケーションがどの時点でも正確なディスク内容を認識できないようにします。これにより、ディスクデータ構造（ファイルシステム、データベースなど）の予測可能で信頼性の高い競合回復が不可能になりました。書き込みが遅れる可能性があるため、カーネルはどの特定の書き込み操作で書き込みエラーが発生したかをアプリケーションに報告できず、一貫性の問題がさらに悪化します。
（からhttps://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/driverbasics-block.html)
しかし、私はLinuxがほとんど排他的にブロックデバイスを使用していることを知っています（rawデバイスを要求できますが）。
もしそうなら、Linuxはこの引用に記載されている問題をどのように回避できますか？それとも、ほとんどのドライバがRAWデバイスのみを要求しますか？
ベストアンサー1
BSDの人々は本当にハードコアで、しばしば驚くべきことをします。 :-)私の考えでは、ブロックデバイス階層を削除することは問題ではありません（たとえば、nfsにはデフォルトのブロックデバイスもありません）。しかし、この推論はブロックデバイスに関するものではありません。書き込みキャッシュに反対します。私の考えでは、書き込みキャッシュを削除するのは非常に悪いことです。プロセスがディスクに何かを書き込んだ場合、成功するまで制御を取り戻しませんか？
しかし、私は彼らが何をしているのかわからなかったと思います。誰かが別の答えで理由を説明できることを願っています。
これを明確に説明するには、ファイルシステムがどのように機能するかを説明する必要があります。ファイルシステムドライバは、本質的にファイルシステム操作（ディレクトリのオープン、ファイルの作成、読み取り、書き込み、削除など）とブロック操作（「0xfce2ea31ページをディスクブロック0xc0deebedに書き込む」）との間の変換レイヤです。
ただし、ブロック操作はその場でハードドライブに到達しません。まずブロックキャッシュに移動します。これは、ファイルシステムがディスクにメモリページを書き込もうとすると、最初に予約されたメモリ領域に書き込むことを意味します。カーネルのメモリ管理が最適であると判断した場合、このデータはハードディスクに書き込まれます。これにより、様々な速度向上が可能です。たとえば、ディスクの先頭と終わりに多くの書き込みが発生した場合、カーネルはディスクヘッドができるだけ少なく独自に再配置されるようにそれらを組み合わせることができます。
別の改善点があります。プログラムがファイルに書き込むと、あたかもRAMディスクのように非常に速い速度で作業が行われます。もちろん、これはシステムRAMがいっぱいになっていない場合にのみ可能です。その後、書き込みキャッシュがクリアされるのを待つ必要があります。ただし、これは並行書き込みが多い場合にのみ発生します（たとえば、大容量ファイルをコピーする場合など）。
ファイルシステムの場合、ディスク上で実行されるファイルシステム（ブロックデバイスなど）とそうでないファイルシステム（fe nfs）の間には大きな違いがあります。 2番目のケースではブロックがないため、ブロックキャッシュはできません。これらの場合、いわゆる「バッファキャッシュ」があります。これは、デフォルトではまだキャッシュ（読み書き）がありますが、メモリブロックを中心に構成されておらず、すべてのサイズのI / Oフラグメントを中心に構成されていることを意味します。
はい、Linuxには、ブロックキャッシュメカニズムなしでディスクデバイスを使用できる「raw」ブロックデバイスがあります。しかし、この問題は彼らによって解決されませんでした。
代わりに「ジャーナリングファイルシステム」というものがあります。ジャーナルファイルシステムを使用すると、ファイルシステムは他のページの前に作成する必要があるページをカーネルに指示できます。ファイルシステムにジャーナリングメカニズムがない場合は、ブロックをディスクに書き込み（より正確にはブロックキャッシュに書き込み）、カーネルは最適であると思われる場合は実際の書き込み操作を実際に実行します。
ジャーナル・ファイル・システムは、各書き込み操作が 2 回発生すると考えることができます。まず、「ログ」（ディスクの予約済み領域）と実際の場所でのみ発生します。システムのクラッシュやディスク障害が発生した場合は、ディスクの最後の破損した状態の内容をログから非常に迅速かつ簡単に再構成できます。
ただし、これにより各書き込みが2回完了する必要があるため、書き込みパフォーマンスが大幅に低下します。これが実際にジャーナリングファイルシステムがより洗練された方法で動作する理由です。さまざまな複雑なデータ構造操作を使用して、これらのオーバーヘッドをほとんど目立たないレベルに減らします。しかし、難しいです。たとえば、ext2と比較してext3の主な改善点は、ロギング機能が含まれているため、コードサイズが指数関数的に増加することです。
Linuxでは、ブロック層APIには「バリア」メカニズムがあります。ファイルシステムは、書き込み操作の間に「障壁」を置くことができる。バリアはデータを意味します。後ろにバリアはディスクにのみ書き込みます。後ろに各データ今後障害物が記録されました。ジャーナリングファイルシステムは、バリアメカニズムを使用して、実際の書き込み操作に必要な順序についてブロック階層に指示します。私が知っている限り、彼らは生のデバイスマッピングを使用しません。
FreeBSDがこれにどのように反応するのかわかりません。おそらく、ブロックデバイスを削除すると、すべてがブロックキャッシュではなくバッファキャッシュとして機能することを意味します。またはここに記録されていない内容があります。内部的には、* BSDとLinuxファイルシステムの世界の間に大きな違いがあります。