oplock 요청 및 부여
네트워크 리다이렉터에서 원격 서버의 파일에 액세스하면 원격 서버에서 oplock을 요청합니다. 클라이언트 애플리케이션은 잠금이 로컬 서버의 파일에 대한 경우에만 oplock을 직접 요청합니다.
Oplock은FSCTL을 통해 요청됩니다. 다음 FSCTL은 사용자 모드 애플리케이션과 커널 모드 드라이버가 모두 발급할 수 있는 다양한 oplock 형식에 사용됩니다.
- 레거시 oplock을 요청하려면 다음을 수행합니다.
- Windows 7 oplock을 요청하려면 다음을 수행합니다.
사용자 모드에서 Windows 7 oplock을 요청하려면 DeviceIoControl을 호출합니다.
- dwIoControlCode를 FSCTL_REQUEST_OPLOCK 설정합니다.
- lpInBuffer 매개 변수로 전달되는 REQUEST_OPLOCK_INPUT_BUFFER 구조체의 Flags 멤버에 REQUEST_OPLOCK_INPUT_FLAG_REQUEST 플래그를 지정합니다.
비슷한 방식으로 커널 모드에서 Windows 7 oplock을 요청하려면 다음을 수행합니다.
- 파일이 아닌 시스템 미니필터는 ZwFsControlFile을 호출할 수 있습니다.
- 파일 시스템 미니필터는 FltAllocateCallbackData 및 FltPerformAsynchronousIo를 사용해야 합니다.
필요한 4개의 Windows 7 oplock 중 하나를 지정하려면 REQUEST_OPLOCK_INPUT_BUFFER 구조체의 RequestedOplockLevel 멤버에서 다음 플래그 중 하나 이상을 설정합니다.
- OPLOCK_LEVEL_CACHE_READ
- OPLOCK_LEVEL_CACHE_HANDLE
- OPLOCK_LEVEL_CACHE_WRITE
자세한 내용은 FSCTL_REQUEST_OPLOCK 참조하세요.
요청된 oplock을 부여할 수 있으면 파일 시스템은 STATUS_PENDING 반환합니다. 이러한 이유로 oplock은 동기 I/O에 대해 부여되지 않습니다. FSCTL IRP는 oplock이 끊어질 때까지 완료되지 않습니다.
oplock을 부여할 수 없는 경우 파일 시스템에서 적절한 오류 코드가 반환됩니다. 가장 일반적으로 반환되는 오류 코드는 STATUS_OPLOCK_NOT_GRANTED 및 STATUS_INVALID_PARAMETER(및 해당 사용자 모드 유사체)입니다.
필터 oplock을 사용하면 다른 애플리케이션/클라이언트가 동일한 스트림에 액세스하려고 할 때 애플리케이션이 "백아웃"할 수 있습니다. 이 메커니즘을 사용하면 스트림을 열려고 할 때 다른 스트림 접근자가 공유 위반을 수신하지 않고도 애플리케이션이 스트림에 액세스할 수 있습니다. 위반 공유를 방지하려면 특수한 3단계 프로시저를 사용하여 필터 연산자(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 필터 Batch |
다음 조건이 모두 충족되는 경우에만 허용됩니다.
현재 oplock 상태가 인 경우:
|
수준 2 |
다음 조건이 모두 충족되는 경우에만 허용됩니다.
현재 oplock 상태가 인 경우:
|
읽기 |
다음 조건이 모두 충족되는 경우에만 허용됩니다.
현재 oplock 상태가 다음과 같은 경우 주의해야 합니다.
|
Read-Handle |
다음 조건이 모두 충족되는 경우에만 허용됩니다.
현재 oplock 상태가 인 경우:
|
읽기-쓰기 |
다음 조건이 모두 true인 경우에만 부여됩니다.
현재 oplock 상태가 인 경우:
|
읽기-쓰기-핸들 |
다음이 모두 true인 경우에만 부여됩니다.
현재 oplock 상태가 인 경우:
|
참고
읽기 및 수준 2 oplock은 동일한 스트림에서 공존할 수 있으며 읽기 및 Read-Handle oplock은 공존할 수 있지만 수준 2 및 Read-Handle oplock은 공존할 수 없습니다.
피드백
https://aka.ms/ContentUserFeedback
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요.다음에 대한 사용자 의견 제출 및 보기