다음을 통해 공유

Oplock 해제

  • 아티클

oplock요청되고부여되면 해당 oplock의 소유자는 요청된 oplock 유형에 따라 스트림에 액세스할 수 있습니다. 받은 작업이 현재 oplock과 호환되지 않는 경우 시스템은 oplock을 중단합니다.

oplock이 부여되면 시스템에서 요청 중인 IRP를 보류합니다. oplock이 끊어지면 보류 중인 oplock의 요청 IRP가 STATUS_SUCCESS로 완료됩니다. 수준 1, 일괄 처리 및 필터 oplock의 경우, IRP의 IoStatus.Information 멤버가 oplock이 깨지는 수준을 나타내도록 설정됩니다. 이러한 수준은 다음과 같습니다.

  • FILE_OPLOCK_BROKEN_TO_NONE: oplock이 해제되었고 현재 스트림에 oplock이 없습니다. oplock이 '없음으로 무효화되었다'고 합니다.

  • FILE_OPLOCK_BROKEN_TO_LEVEL_2: 현재 oplock(수준 1 또는 Batch)이 수준 2 oplock으로 변환되었습니다. 필터 oplock은 수준 2로 변경되지 않고 항상 없음으로 변경됩니다.

읽기 핸들, 읽기-쓰기 및 읽기Write-Handle oplock의 경우, oplock이 중단되는 수준은 DeviceIoControl의 lpOutBuffer 매개 변수로 전달된 REQUEST_OPLOCK_OUTPUT_BUFFER 구조체의 NewOplockLevel 멤버 안에서 0개 이상의 플래그 조합인 OPLOCK_LEVEL_CACHE_READ, OPLOCK_LEVEL_CACHE_HANDLE, 또는 OPLOCK_LEVEL_CACHE_WRITE로 설명됩니다. 비슷한 방식으로 FltFsControlFile 및 ZwFsControlFile 사용하여 커널 모드에서 Windows 7 oplock을 요청할 수 있습니다. 자세한 내용은 FSCTL_REQUEST_OPLOCK참조하세요.

시스템의 oplock 패키지가 수준 1, 일괄 처리, 필터, 읽기/쓰기, 읽기-쓰기 핸들을 중단하거나 특정 상황에서는 Read-Handle oplock이 중단되는 경우:

  • oplock 패키지는 보류 중인 oplock 요청 IRP를 완료합니다.
  • oplock 중단을 발생시킨 작업 자체는 보류 중입니다.

I/O 관리자를 사용하면 작업이 다음과 같은 경우 STATUS_PENDING 반환하지 않고 작업이 차단됩니다.

  • 동기 핸들에서 발급됩니다.
  • IRP_MJ_CREATE는 항상 동기식인가요?

I/O 관리자는 oplock 소유자가 처리 완료를 oplock 패키지에 알리고 보류 중인 작업을 안전하게 진행할 수 있도록 승인을 기다립니다. 이 지연을 통해 oplock 소유자는 현재 작업이 진행되기 전에 스트림을 일관된 상태로 되돌릴 수 있습니다. 시스템은 시간 제한이 없기 때문에 승인을 받기 위해 영원히 기다릴 것입니다. 따라서 oplock의 소유자는 그 깨짐을 적시에 인지해야 합니다. 보류 중인 작업의 IRP가 취소 가능한 상태로 설정됩니다. 대기를 수행하는 애플리케이션 또는 드라이버가 종료되면 oplock 패키지는 STATUS_CANCELLED 사용하여 IRP를 즉시 완료합니다.

IRP_MJ_CREATE IRP는 oplock 중단 승인의 일부로 차단되지 않도록 FILE_COMPLETE_IF_OPLOCKED 만들기 옵션을 지정할 수 있습니다. 이 옵션은 oplock 중단 승인을 받을 때까지 iRP 만들기를 차단하지 않도록 oplock 패키지에 지시합니다. 대신 만들기를 계속할 수 있습니다. 성공적인 생성으로 인해 oplock 중단이 발생하는 경우, 반환 코드는 STATUS_SUCCESS가 아니라 STATUS_OPLOCK_BREAK_IN_PROGRESS입니다. FILE_COMPLETE_IF_OPLOCKED 플래그는 일반적으로 교착 상태를 방지하는 데 사용됩니다. 예를 들어 클라이언트가 스트림에서 oplock을 소유하고 동일한 클라이언트가 나중에 동일한 스트림을 여는 경우 클라이언트는 oplock 중단을 승인하기 위해 대기하는 것을 차단합니다. 이 시나리오에서는 FILE_COMPLETE_IF_OPLOCKED 플래그를 사용하면 교착 상태가 방지됩니다.

NTFS 파일 시스템은 공유 위반을 확인하기 전에 Batch 및 필터 oplock에 대한 oplock 중단을 시작합니다. 따라서 FILE_COMPLETE_IF_OPLOCKED가 지정된 생성 작업이 STATUS_SHARING_VIOLATION으로 실패하더라도 Batch 또는 Filter oplock이 깨질 수 있습니다. 이 경우 호출자가 이 사례를 검색할 수 있도록 IO_STATUS_BLOCK 구조의 정보 멤버가 FILE_OPBATCH_BREAK_UNDERWAY 설정됩니다.

Read-Handle 및 읽기Write-Handle oplock의 경우, 공유 위반이 발생하면 NTFS에서 이를 확인하고 이후에 oplock 중단이 시작됩니다. 이 시퀀스는 oplock 소유자에게 핸들을 닫고 방해에서 벗어날 수 있는 기회를 제공하므로 공유 위반을 사용자에게 반환하지 않을 수 있습니다. oplock 캐시 핸들이 새로 생성된 항목과 충돌하지 않는 경우, oplock이 무조건적으로 해제되지 않도록 방지합니다.

수준 2, 읽기 및 특정 상황에서 Read-Handle 차단이 중단되면 시스템은 승인을 기다리지 않습니다. 그 이유는 다른 클라이언트가 파일에 액세스하도록 허용하기 전에 파일로 복원해야 하는 스트림에 캐시된 상태가 없어야 하기 때문입니다.

현재 oplock 상태를 확인하여 oplock을 끊어야 하는지 여부를 확인하는 특정 파일 시스템 작업이 있습니다. 다음 작업 관련 문서에서는 oplock 중단을 트리거하는 항목, oplock이 중단되는 수준을 결정하는 항목 및 중단 승인이 필요한지 여부를 설명합니다.

Windows 7 oplock이 끊어지면, 요청의 출력 매개 변수로 전달된 REQUEST_OPLOCK_OUTPUT_BUFFER 구조의 Flags 멤버에 REQUEST_OPLOCK_OUTPUT_FLAG_ACK_REQUIRED 플래그가 설정되어 있는 경우 승인이 요구됩니다. 이 출력 매개 변수는 DeviceIoControl(lpOutBuffer), FltFsControlFile(OutBuffer) 또는 ZwFsControlFile(OutBuffer)입니다. 자세한 내용은 FSCTL_REQUEST_OPLOCK참조하세요.

나열된 작업별 문서는 Read-Handle oplock의 중단이 해당 작업의 보류로 이어지는 경우의 세부 정보를 설명합니다. 예를 들어 IRP_MJ_CREATE 문서에는 연결된 Read-Handle 세부 정보가 포함되어 있습니다.