Batch OpLocks: Are they used much these days ...

Urban Widmark urban at
Thu Jan 10 06:22:06 GMT 2002

On Thu, 10 Jan 2002, David Collier-Brown wrote:

> Urban Widmark wrote:
> > Batch oplocks allow a lot more caching on the client side. smbfs can read
> > pages into memory and does not have to invalidate them even when the file
> > is closed, because the batch oplock allows the close to be cached. If the
> > file is opened again the pages remain valid.
> > 
> > The smbfs code doesn't actually do that, but it could.
> > Why would anyone want just an exclusive oplock?
> 	Arguably for sharing: if the file needs
> 	to be single-writer multiple-reader an
> 	exclusive write lock is appropriate.

But an exclusive _oplock_ does not allow anyone else to have the file
open. When someone else opens you get a notification and your oplock is
broken. After that you can no longer cache any data.

(An oplock is not the same as a write lock, you can get a write
 lock with a SMB_COM_LOCKING_ANDX, oplocks are requested at file open

> 	If the file is read-only, caching a close
> 	is harmless if and only if doing so does
> 	not leave the file locked against writers!

A batch oplock would do that. When the other client tries to open the file
my client is notified and must drop the cached data.

An exclusive oplock can be emulated with a batch oplock. All the client 
has to do is to close the file.

So what is it about them that is not in the documentation?


More information about the samba-technical mailing list