Hello,
We are running into the problem in slower performance on oplock.
Here is the oplock scenario.
- We are using 3.0.22.
- Kernel oplock has been implemented on hp-ux 11v3.
- smb.conf
kernel oplocks = Yes
oplock break wait time = 0
fake oplocks = No
locking = Yes
oplocks = Yes
level2 oplocks = Yes
oplock contention limit = 2
posix locking = Yes
- Running a Windows application that have to access to data on Samba share.
- Read data is ok.
- A single user to write data is ok.
- Multiple users to write data experience oplock delay. For example, two clients
tried to edit data at the same time in the application, there are following
processing from my observation:
* The first open on a file with an exclusive oplock.
* The second open on the same file needs to call defer_open() and send oplock
break msg to itself.
* Most of time, the msg can be received. Performance is OK. But sometimes for
some reason, the msg couldn't be received. I don't know why. So there
was a delay(probably 60s) after open_was_deferred(). After this, Windows client
tried to send SMBntcreate to open it again. This time still failed. Since we
have "Trying to delay for oplocks twice" in open_file_ntcreate(), it
leaded to close the connection.
- Whether IS the defer_open on the second open necessary? Because this is the
same process, and the same file.
- What kind of reasons to cause the smbd did not receive the break msg?
- Is there any way to remove the delay, or a specific fix around this?
Any help greatly appreciated.
Thanks very much.
-Ying
On Sat, Feb 16, 2008 at 12:33:38AM +0000, Li, Ying (ESG) wrote:> - Whether IS the defer_open on the second open necessary? > Because this is the same process, and the same file. > - What kind of reasons to cause the smbd did not receive the break msg?No idea. A signal sometimes not delivered? Does the message end up in messages.tdb? As this is a message to the process itself, you could implement a shortcut in messages.c if signals on HP/UX are unreliable. But this will not help with oplocks to other processes. Volker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.samba.org/archive/samba/attachments/20080216/38569bb6/attachment.bin
Hi Volker, Thanks for your response.> No idea. A signal sometimes not delivered?No. If that signal was received, there was no delay. If it's not received, the delay occurred. Look at the message from a client log file. [2008/01/31 11:58:41, 3] smbd/open.c:delay_for_oplocks(683) Sending break request to PID 24330 [2008/01/31 11:58:41, 3] smbd/open.c:defer_open(741) defer_open_sharing_error: time [1201809521.237026] adding deferred open entry for mid 6 5344 [2008/01/31 11:58:41, 3] smbd/process.c:push_deferred_smb_message(220) push_deferred_open_smb_message: pushing message len 148 mid 65344 timeout time [1201809 581.237026] [2008/01/31 11:58:41, 3] smbd/process.c:push_queued_message(113) push_message: pushed message length 148 on deferred_open_queue [2008/01/31 11:58:41, 3] smbd/process.c:open_was_deferred(179) open_was_deferred [*** a delay for the time OPLOCK_TIMEOUT*2 ***] [2008/01/31 11:59:41, 3] smbd/process.c:switch_message(1010) switch message SMBntcreateX (pid 25366) conn 0x8b2a10> Does the message end up in messages.tdb?How to check out if it's end up. I use tdbdump on messages.tdb. Looks like ending up. Just a huge data with 8192bytes presented on the entry for that pid. I'm wondering whether there was possibility of msgbuf overflow because its length is 1600 in message.c. key(10) = "PID/24330\00" data(2992) = "<huge data>" I'm looking for what reason to cause the signal missing. Thanks. -Ying