2

ダイレクト I/O 転送が失敗する状況を知りたいですか?

そのために、次の 3 つのサブクエリがあります。「Linuxカーネルを理解する」本によると..

  1. Linux は、ページ キャッシュをバイパスする簡単な方法を提供します。つまり、直接 I/O 転送です。各 I/O 直接転送で、カーネルはディスク コントローラーをプログラムして、セルフ キャッシュ アプリケーションのユーザー モード アドレス空間に属するページとの間でデータを直接転送します。

-- では、失敗を説明するには、アプリケーションにセルフ キャッシング機能があるかどうかを確認する必要がありますか? それがどのようにできるかわかりません。

2.さらに本には、「セルフキャッシングアプリケーションがファイルに直接アクセスしたい場合、O_DIRECTフラグを指定してファイルを開く.open()システムコールを処理している間、dentry_open()関数はdirect_IOメソッドが実装されているかどうかをチェックする.開かれているファイルの address_space オブジェクトに対して、逆の場合はエラー コードを返します。」

- これとは別に、直接の I/O 障害を説明できる他の理由はありますか?

3. このコマンド「dd if=/dev/zero of=myfile bs=1M count=1 oflag=direct」は、Linux で失敗することはありますか?

4

2 に答える 2

1

基盤となるファイルシステムとブロック デバイスはO_DIRECTフラグをサポートする必要があります。tmpfs は をサポートしていないため、このコマンドは失敗しO_DIRECTます。

dd if=/dev/zero of=/dev/shm/test bs=1M count=1 oflag=direct

書き込みサイズは、基になるドライバーのブロック サイズの倍数である必要があります。123 は 512 の乗算ではないため、このコマンドは失敗します。

dd if=/dev/zero of=myfile bs=123 count=1 oflag=direct
于 2012-10-29T06:16:51.503 に答える
0

ダイレクト I/O が失敗し続ける理由は多数あります。

失敗を説明するには、アプリケーションにセルフキャッシング機能があるかどうかを確認する必要がありますか?

これを外部で行うことはできません-ソースコードからこれを推測するか、プログラムが実行中にリソースをどのように使用したかを監視する必要があります(バイナリ逆アセンブリだと思います)。これは、「呼び出しでこの機能をオンにする」というよりも、プログラムがどのように機能するかのプロパティです。使用するすべてのプログラムがセルフ キャッシングを持っていると考えるのは危険な仮定ですO_DIRECT(確率的には可能性が高いと思いますが、確かなことはわかりません)。

  1. 使用には厳密な要件がありO_DIRECT、それらは open の man ページに記載されています ( O_DIRECTNOTES のセクションを参照)。
  2. 最新のカーネルでは、操作対象の領域をディスクのブロック サイズに揃える必要があり、そのサイズはディスクのブロック サイズの倍数にする必要があります。これを正しく行わないと、バッファリングされた I/O へのサイレント フォールバックが発生する可能性さえあります。
  3. はい、たとえば、ファイルシステム ( などtmpfs) で使用しようとすると、 はサポートされませんO_DIRECT。ディスクへのパスが何らかの理由で失敗を返した場合にも失敗する可能性があると思います (たとえば、ディスクが死にかけていて、ライトバックで起こることと比較してはるかに早くエラーを返します)。
于 2018-09-05T06:01:23.020 に答える