O_DIRECTを無視しても安全ですか？

~によるとopen(2) マニュアルページ:

   O_DIRECT (since Linux 2.4.10)
          Try to minimize cache effects of the I/O to and from this
          file.  In general this will degrade performance, but it is
          useful in special situations, such as when applications do
          their own caching.  File I/O is done directly to/from user-
          space buffers.  The O_DIRECT flag on its own makes an effort
          to transfer data synchronously, but does not give the
          guarantees of the O_SYNC flag that data and necessary metadata
          are transferred.  To guarantee synchronous I/O, O_SYNC must be
          used in addition to O_DIRECT.  See NOTES below for further
          discussion.

コメントセクションで：

   O_DIRECT support was added under Linux in kernel version 2.4.10.
   Older Linux kernels simply ignore this flag.  Some filesystems may
   not implement the flag and open() will fail with EINVAL if it is
   used.

したがって、O_DIRECTは単に無視されました。そしてLKMLから、わずか数ヶ月前：

データが壊れていない限り、ファイルシステムがO_DIRECTをどのように実装しているのか、誰が気にしますか？ ext3は多くの場合バッファリングされたIOに置き換えられますが、これに対する唯一の苦情はパフォーマンスです。 IOW、長期的（ユーザーがO_DIRECTに興味がある場合）パフォーマンスその後、ファイルシステムを慎重に選択する必要があります。

ただし、各ファイルシステムにO_DIRECTをサポートするコード行が5行しかない場合 正しくバッファリングされたIOを使用すると、なぜユーザースペースがパブリック（O_DIRECT）障害を明示的に処理するために難関を超えなければなりませんか？

特に、彼らができることは、バッファリングされたIO自体にフォールバックするだけであることを考慮すると...

私はこれらすべてについて異議を申し立てましたが、より良い方法を考えました。以前のバージョンのカーネルはO_DIRECTを無視していたので、明らかに先例があります。

この点を考慮すると無視しても構わないようです。キーワードは「データ破損なし」のようです。

現在。

またリンクの問題パフォーマンス上の理由から、O_DIRECTが役に立たないという答えがあります。これは完全に間違っています。ページキャッシュを介したデータの配信いいえページキャッシュを通過します。これは、毎秒ギガバイトを転送できるハードウェアにとって重要です。キャッシュは、各データビットを一度だけ処理する場合、事実上役に立たないが、システム全体に不必要に影響を与える。

Linuxファイルシステムモジュールを作成してから数年が経ちました。残念ながら、VFSシステムがキャッシュを処理する方法を覚えていません。