Peter J. Holzer
2005-Jan-28 16:47 UTC
[Samba] Oplocks with concurrent access from same client
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? hp -- _ | 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@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 Type: application/pgp-signature Size: 388 bytes Desc: not available Url : http://lists.samba.org/archive/samba/attachments/20050128/2846951f/attachment.bin