Oplock timing issue.

[Scott Prather]

Yes it is, 2.4.2 from SuSe.  We also have problems on AIX (no kernel oplocks), but it takes longer for this to show up.  I think the problem is the smbd trying to open the file is not waiting long enough for the oplock to break before calling fd_open, as it seems from the timestamps that the oplock break is still processing during the actual open of the file.   This is Samba 2.2.0, we have not had any problems with 2.0.7.

A network trace shows that the response to the close of the file is sent at almost the same time as the response to the open from the second file.  In previous files that are opened with oplock (for examlpe cpuid32.dll), the client that is requested to break the oplock sends a LockAndX response.  In the case of client.cfg, the client returs a close in response to the oplock break request.


On Thu, Jun 07, 2001 at 09:54:30AM -0700, Jeremy Allison wrote:
> On Thu, Jun 07, 2001 at 10:24:03AM -0500, Scott Prather wrote:
> > We have tested our Netbench problems using SuSE Linux 7.1 on an RS/6000 43p/150.  The problem seems to be a timing issue, one smbd process is still processing the oplock break  while the other is doing fd_open on it.
> > 
> > In this case, Netbench v6.0 was used.  The first client that executes oplocks client.cfg, the second one, when it does an NT_create_and_X on the file also attempts an oplock.  The first client responds to the oplock break request with a close.  While the oplock break is processing, the second client is refused acces to the file.
> > 
> > I have attached 2 log files with level 10 debugging turned on, log.greedo is the first system which is running the controller and the first client, log.falcon is the second client that recieves an access denied message when trying to open client.cfg.
> > 
> > You can find these at around 04:44:35.613878 (these are per client logs taken at the same time).
> > 
> > I have pared down the logs to just the file open and oplock break, I have much larger logs that have the entire session.
> > 
> 
> I take it this is on a Linux 2.4 kernel ? The EAGAIN error
> is not usual for a standard open() call. Can you confirm this
> please ?
> 
> Andrew, if this is the case, when can the Linux kernel oplock
> code return EAGAIN (I will eventually grub through this source
> code, I'm just busy with large file write issues for 2.2.1
> right now).
> 
> Jeremy.

-- 
Scott Prather
MCSE, MCP+I
Software Engineer
AIX PC Interoperability
sprather at austin.ibm.com
(512)838-3313