Bagikan melalui

Memutus Oplock

  • Artikel

Setelah oplockdiminta dan diberikan, pemilik oplock tersebut memiliki akses ke aliran berdasarkan jenis oplock yang diminta. Jika operasi yang diterima tidak kompatibel dengan oplock saat ini, sistem akan membatalkan oplock.

Ketika oplock diberikan, sistem menunggu IRP yang mengajukan permohonan. Ketika oplock rusak, IRP permintaan oplock yang tertunda diselesaikan dengan STATUS_SUCCESS. Untuk Level 1, Batch, dan Filter, anggota IRP oplock IoStatus.Information diatur untuk menunjukkan tingkat saat oplock tersebut mengalami pemutusan. Tingkat-tingkat ini adalah:

  • FILE_OPLOCK_BROKEN_TO_NONE: Oplock telah rusak dan tidak ada oplock saat ini pada stream. Oplock dikatakan "rusak ke Tidak Ada."

  • FILE_OPLOCK_BROKEN_TO_LEVEL_2: Oplock saat ini (Level 1 atau Batch) dikonversi ke oplock Level 2. Filter oplock tidak pernah turun ke Tingkat 2, mereka selalu turun menjadi Tidak Ada.

Untuk Read-Handle, Read-Write, dan Read-Write-Handle oplock, tingkat ketika oplock dibatalkan dijelaskan sebagai kombinasi dari nol atau lebih bendera OPLOCK_LEVEL_CACHE_READ, OPLOCK_LEVEL_CACHE_HANDLE, atau OPLOCK_LEVEL_CACHE_WRITE dalam anggota NewOplockLevel dari struktur REQUEST_OPLOCK_OUTPUT_BUFFER yang diteruskan sebagai parameter lpOutBuffer dari DeviceIoControl. Dengan cara yang sama, FltFsControlFile dan ZwFsControlFile dapat digunakan untuk meminta oplock Windows 7 dari mode kernel. Untuk informasi selengkapnya, lihat FSCTL_REQUEST_OPLOCK.

Ketika paket oplock sistem merusak Level 1, Batch, Filter, Read-Write, Read-Write-Handle, atau, dalam keadaan tertentu, Read-Handle oplock:

  • Paket oplock menyelesaikan permintaan IRP oplock yang tertunda.
  • Operasi yang menyebabkan jeda oplock itu sendiri ditunda.

Manajer I/O menyebabkan operasi diblokir, bukan mengembalikan STATUS_PENDING, jika operasi:

  • Diterbitkan pada pegangan sinkron.
  • Adalah IRP_MJ_CREATE, yang selalu sinkron.

Manajer I/O menunggu pengakuan dari pemilik oplock untuk memberi tahu paket oplock bahwa pemrosesannya telah selesai dan aman bagi operasi yang tertunda untuk melanjutkan. Penundaan ini memungkinkan pemilik oplock untuk menempatkan aliran kembali ke status konsisten sebelum operasi saat ini berlanjut. Sistem akan menunggu selamanya untuk menerima pengakuan karena tidak ada waktu habis. Oleh karena itu, pemilik oplock harus secara tepat waktu mengakui pemutusan hubungan. IRP dari operasi yang tertunda diatur ke dalam status yang bisa dibatalkan. Jika aplikasi atau driver yang sedang menunggu dihentikan, paket oplock segera menyelesaikan IRP dengan STATUS_CANCELLED.

IRP IRP_MJ_CREATE dapat menentukan opsi pembuatan FILE_COMPLETE_IF_OPLOCKED untuk menghindari pemblokiran sebagai bagian dari pengakuan pembatalan oplock. Opsi ini memberi tahu paket oplock untuk tidak memblokir buat IRP sampai pengakuan jeda oplock diterima. Sebaliknya, prosesnya diizinkan untuk berlanjut. Jika pembuatan yang berhasil menyebabkan jeda oplock, nilai pengembalian adalah STATUS_OPLOCK_BREAK_IN_PROGRESS, bukan STATUS_SUCCESS. Flag FILE_COMPLETE_IF_OPLOCKED biasanya digunakan untuk menghindari kebuntuan. Misalnya, jika klien memiliki oplock pada aliran dan klien yang sama kemudian membuka aliran yang sama, klien akan terblokir sambil menunggu sendiri untuk mengakui pemutusan oplock. Dalam skenario ini, penggunaan flag FILE_COMPLETE_IF_OPLOCKED menghindari kebuntuan.

Sistem berkas NTFS memulai jeda oplock untuk Batch dan Filter oplock sebelum memeriksa pelanggaran berbagi. Oleh karena itu, dimungkinkan bagi proses pembuatan yang menggunakan FILE_COMPLETE_IF_OPLOCKED mengalami kegagalan dengan STATUS_SHARING_VIOLATION namun masih menyebabkan oplock Batch atau Filter terputus. Dalam hal ini, informasi anggota dari struktur IO_STATUS_BLOCK diatur ke FILE_OPBATCH_BREAK_UNDERWAY untuk memungkinkan pemanggil mendeteksi kasus ini.

Untuk oplock Read-Handle dan Read-Write-Handle, jeda oplock dimulai setelah NTFS memeriksa dan mendeteksi pelanggaran berbagi. Urutan ini memberi pemegang oplock kesempatan untuk menutup handel mereka dan keluar dari jalan, sehingga memungkinkan kemungkinan tidak mengembalikan pelanggaran berbagi kepada pengguna. Ini juga menghindari memecah oplock secara tanpa syarat dalam kasus di mana handel yang di-cache oleh oplock tidak bertentangan dengan penciptaan baru.

Ketika Level 2, Read, dan, dalam keadaan tertentu Read-Handle oplocks rusak, sistem tidak menunggu tanggapan. Alasannya adalah bahwa seharusnya tidak ada status cache pada aliran yang perlu dipulihkan ke file sebelum mengizinkan klien lain mengaksesnya.

Ada operasi sistem file tertentu yang memeriksa status oplock saat ini untuk menentukan apakah oplock perlu dibatalkan. Artikel khusus operasi di bawah ini menjelaskan apa yang memicu pemutusan oplock, apa yang menentukan tingkat di mana oplock terputus, dan apakah pengakuan pemutusan diperlukan:

Jeda oplock Windows 7 memerlukan pengakuan jika bendera REQUEST_OPLOCK_OUTPUT_FLAG_ACK_REQUIRED diatur dalam Bendera anggota struktur REQUEST_OPLOCK_OUTPUT_BUFFER yang diteruskan sebagai parameter output DeviceIoControl(lFltFsControlFile(OutBuffer), atau ZwFsControlFile(OutBuffer). Untuk informasi selengkapnya, lihat FSCTL_REQUEST_OPLOCK.

Artikel per operasi yang tercantum menjelaskan detail kapan jeda Read-Handle oplock menghasilkan tertundanya operasi yang merusak oplock. Misalnya, artikel IRP_MJ_CREATE berisi detail Read-Handle terkait.