Oplock timing issue.

[Jeremy Allison]

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.