best strategy for preventing unnecessary oplock breaks on doubly open files

[Steven French]

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)

Ideas?




Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com