oplock の要求と許可
ネットワーク リダイレクタは、リモート サーバー上のファイルにアクセスするときに、リモート サーバーに oplock を要求します。 クライアント アプリケーションは、ロックがローカル サーバー上のファイルを対象とする場合にのみ、oplock を直接要求します。
Oplocks は FSCTLs.を通じてリクエストされます。 次の FSCTL はさまざまな用途に使用されます oplock の種類、ユーザー モード アプリケーションとカーネル モード ドライバーの両方が発行できます。
- 従来の oplock をリクエストするには:
- Windows 7 の oplock を要求するには:
ユーザー モードで Windows 7 oplock を要求するには、デバイスIoControl を呼び出します:
- 設定 dwIoControlCode to FSCTL_REQUEST_OPLOCK.
- REQUEST_OPLOCK_INPUT_BUFFER 構造体の Flagsメンバーに REQUEST_OPLOCK_INPUT_FLAG_REQUEST フラグを指定し、lpInBuffer パラメータとして渡します。
同様の方法で、カーネル モードで Windows 7 oplock を要求するには、次のようにします。
- 非ファイル システム ミニフィルターは ZwFsControlFile を呼び出すことができます。
- ファイル システム ミニフィルター FltAllocateCallbackData と、 FltPerformAsynchronousIo を使用する必要があります。
4 つの Windows 7 oplock のうちどれが必要かを指定するには、REQUEST_OPLOCK_INPUT_BUFFER 構造の RequestedOplockLevel を 1 つ以上を設定します。
- OPLOCK レベル キャッシュの読み取り
- OPLOCK レベル キャッシュ ハンドル
- OPLOCK レベル キャッシュ書き込み
詳細については、FSCTL_REQUEST_OPLOCK を参照してください。
要求された oplock が許可される場合、ファイル システムは STATUS_PENDING を戻します。 このため、同期 I/O に対して oplock は決して許可されません。 FSCTL IRP は、oplock が解除されるまで完了しません。
oplock を付与できない場合、ファイル システムは適切なエラー コードを戻します。 最も一般的に返されるエラー コードは、STATUS_OPLOCK_NOT_GRANTED および STATUS_INVALID_PARAMETER (およびそれらと同等のユーザー モード類似コード) です。
フィルター oplock を使用すると、他のアプリケーション/クライアントが同じストリームにアクセスしようとしたときに、アプリケーションが「バックアウト」できます。 このメカニズムにより、アプリケーションは、ストリームを開こうとするときに、ストリームの他のアクセサーが共有違反を受け取ることなく、ストリームにアクセスできます。 共有違反を回避するには、特別な 3 ステップの手順を使用してフィルター oplock (FSCTL_REQUEST_FILTER_OPLOCK) を要求する必要があります。
必要なアクセスは FILE_READ_ATTRIBUTES で、共有モードは FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE です。
ステップ 1 のハンドルに対してフィルター oplock を要求します。
読み取りアクセスのためにファイルを再度開きます。
手順 1 で開いたハンドルは、データ アクセス (FILE_READ_DATA) ではなく、属性アクセス (FILE_READ_ATTRIBUTES) に対してのみ開かれるため、他のアプリケーションが共有違反を受けることはありません。 このハンドルは、フィルター oplock の要求には適していますが、データ ストリーム上で実際の I/O を実行する場合には適していません。 ステップ 3 で開いたハンドルにより、oplock の所有者はストリームに対して I/O を実行できるようになります。 手順 2 で oplock を付与すると、oplock の所有者は、ストリームにアクセスしようとする別のアプリケーションに共有違反を引き起こすことなく「邪魔にならないように」できます。
NTFS ファイル システムは、FILE_RESERVE_OPFILTER 作成オプション フラグを通じてこのプロシージャを最適化します。 このフラグが前の手順のステップ 1 で指定されている場合、ファイル システムがステップ 2 が失敗すると判断できれば、ファイル システムは STATUS_OPLOCK_NOT_GRANTED で作成リクエストを失敗できます。 ステップ 1 が成功した場合、作成リクエストに FILE_RESERVE_OPFILTER が指定されていたとしても、ステップ 2 が成功する保証はありません。
次の表は、oplock を許可するために必要な条件を示しています。
要求の種類 | 条件 |
---|---|
レベル 1 Assert Batch |
これは、次の条件がすべて満たされている場合にのみ当てはまります。
現在の oplock 状態が次の場合:
|
レベル 2 |
これは、次の条件がすべて満たされている場合にのみ当てはまります。
現在の oplock 状態が次の場合:
|
読み込み |
これは、次の条件がすべて満たされている場合にのみ当てはまります。
現在の oplock 状態が次の場合は注意してください。
|
読み取りハンドル |
これは、次の条件がすべて満たされている場合にのみ当てはまります。
現在の oplock 状態が次の場合:
|
読み取り/書き込み |
これは、次の条件がすべて満たされている場合にのみ当てはまります。
現在の oplock 状態が次の場合:
|
読み取り/書き込みハンドル |
次のすべてが当てはまる場合にのみ許可されます。
現在の oplock 状態が次の場合:
|
Note
読み取り oplock とレベル 2 oplock は同じストリーム上に共存でき、読み取り oplock と読み取りハンドル oplock は共存できますが、レベル 2 oplock と読み取りハンドル oplock は共存できません。