best strategy for preventing unnecessary oplock breaks on doubly open files

Jeremy Allison jra at
Tue Oct 11 21:51:31 GMT 2005

On Tue, Oct 11, 2005 at 09:54:43AM -0500, Steven French wrote:
> A difficult case for clients to deal with is the common scenario of an
> application opening a file twice with different flags from the same client.
> As an example, the popular standard iozone benchmark in about four places
> opens the target file read-write then reopens it read then uses the first
> handle then closes the first handle then closes the second handle.   The
> second open would cause an oplock break to be sent, and client caching to
> be disabled.   Unfortunately, having the client "cache" the second open is
> not as easy as it sounds because it is not clear what the best thing to do
> on the close of the first handle -
>       1) leave the file open with the wrong flags (leave it open r/w on the
> server, potentially affecting applications on other Windows clients doing
> deny-write, when it is actually open for read on the client)
>       2) close the file and immediately reopen it for read (which risks a
> small window when the file is not open at all - and another app on another
> client could get in and do a deny-read open preventing us from accessing
> it)
>       3) try to change the handle type (there must be a way to do this by
> now in cifs to windows at least)
>       4) just prior to close of handle one, try to do the open for read,
> which will lose the oplock, then close the handle one, then try to reaquire
> oplock on handle two via the fcntl - if it even works)

What about adding a reaquire oplock call into the UNIX extentions ?


More information about the samba-technical mailing list