호환성이 손상되는 Oplock

  • 아티클

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

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

  • FILE_OPLOCK_BROKEN_TO_NONE - oplock이 끊어졌고 스트림에 현재 oplock이 없습니다. oplock은 "없음으로 부서졌다"고 합니다.

  • FILE_OPLOCK_BROKEN_TO_LEVEL_2 - 현재 oplock(수준 1 또는 일괄 처리)이 수준 2 oplock으로 변환되었습니다. 필터 oplock은 수준 2로 중단되지 않으며 항상 없음으로 중단됩니다.

Read-Handle, Read-Write 및 Read-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 중단을 발생시킨 작업 자체는 보류 중입니다.

연산이 동기 핸들에서 실행되거나 항상 동기식인 IRP_MJ_CREATE 경우 I/O 관리자가 STATUS_PENDING 반환하지 않고 작업이 차단되도록 하여 oplock의 소유자가 oplock 패키지에 처리를 완료했음을 알리고 보류 중인 작업이 계속 진행되도록 안전합니다. 이 지연의 목적은 oplock의 소유자가 현재 작업이 진행되기 전에 스트림을 다시 일관된 상태로 되돌릴 수 있도록 하는 것입니다. 시스템은 시간 제한이 없기 때문에 승인을 받기 위해 영원히 기다립니다. 따라서 적시에 휴식을 인정하는 것은 oplock의 소유자에게 달려 있습니다. 보류 중인 작업의 IRP가 취소 가능한 상태로 설정됩니다. 대기를 수행하는 애플리케이션 또는 드라이버가 종료되면 oplock 패키지는 STATUS_CANCELLED 사용하여 IRP를 즉시 완료합니다.

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

NTFS 파일 시스템은 공유 위반을 확인하기 전에 Batch 및 Filter oplock에 대한 oplock 나누기를 시작하기 때문에 지정된 FILE_COMPLETE_IF_OPLOCKED STATUS_SHARING_VIOLATION 실패하지만 여전히 Batch 또는 Filter oplock이 중단되는 만들기가 가능합니다. 이 경우 호출자가 이 사례를 검색할 수 있도록 IO_STATUS_BLOCK 구조의 정보 멤버가 FILE_OPBATCH_BREAK_UNDERWAY 설정됩니다.

Read-Handle 및 Read-Write-Handle oplock의 경우 NTFS가 공유 위반을 확인하고 검색한 후 oplock 중단이 시작됩니다. 이렇게 하면 이러한 oplock의 소유자가 핸들을 닫고 방해에서 벗어날 수 있으므로 공유 위반을 사용자에게 반환하지 않을 가능성이 있습니다. 또한 oplock 캐시가 새 만들기와 충돌하지 않는 핸들이 있는 경우 oplock을 무조건 중단하지 않도록 방지합니다.

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

oplock이 손상되어야 하는지 여부를 확인하기 위해 현재 oplock 상태를 검사 특정 파일 시스템 작업이 있습니다. 다음 문서에서는 각 작업을 나열하고 oplock 중단을 트리거하는 항목, oplock 중단 수준을 결정하는 요소 및 중단 승인이 필요한지 여부를 설명합니다.

DeviceIoControl(lpOutBuffer), FltFsControlFile(OutBuffer) 또는 ZwFsControlFile(OutBuffer)의 출력 매개 변수로 전달된 REQUEST_OPLOCK_OUTPUT_BUFFER 구조의 Flags 멤버에 REQUEST_OPLOCK_OUTPUT_FLAG_ACK_REQUIRED 플래그가 설정된 경우 Windows 7 oplock의 중단을 승인해야 합니다. 자세한 내용은 FSCTL_REQUEST_OPLOCK 참조하세요.

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