[Samba] Oplocks with concurrent access from same client
Peter J. Holzer
hjp+samba at wsr.ac.at
Fri Jan 28 16:46:57 GMT 2005
I am observing the following behaviour with samba-2.2.12 (Yes, I know,
it's old) and MS-Access XP on a Win2K box:
The client opens a .mdb file and gets a level2 oplock.
Then it opens the .mdb file again and loses the oplock (at least I
assume it does: The server sends an SMBlockingX request to the client
and waits for another SMBlockingX request from the client before sending
the Reply to the SMBntcreateX request).
Then the client closes the second file handle to the .mdb file and
continues to use the first one, which has now lost the oplock, so there
is a lot of network traffic and the query is rather slow.
My question is, is this the expected behaviour from the server?
Could the server, if a file is opened a second time from the same
client, assume that it is the client's responsibility to keep data in
its cache of the file consistent, and keep the oplock (and maybe even
grant it on the second filehandle, too)?
Or to ask the same question from a different viewpoint: On the client
system, who is managing oplocks and caching? The application or the OS?
If it's the application, the server can clearly not assume that two
different filehandles will maintain a consistent state of the file (they
may belong to different processes). If it's the OS, it would at least be
technically feasible to maintain a common cache on the client side for
all file handles, and if Windows does this, it would be possible for the
server to take advantage of this.
Finally, if the server can make this optimization, does a newer version
of Samba (3.x or 4.x) do it?
_ | Peter J. Holzer | If the code is old but the problem is new
|_|_) | Sysadmin WSR / LUGA | then the code probably isn't the problem.
| | | hjp at wsr.ac.at |
__/ | http://www.hjp.at/ | -- Tim Bunce on dbi-users, 2004-11-05
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 388 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba/attachments/20050128/2846951f/attachment.bin
More information about the samba