Volker Lendecke wrote:
If both processes are Samba, the kernel oplock break
mechanism should not be involved at all. At least it is
supposed to work so that the oplock break is done with
messages between the smbds. Kernel oplocks are only for
interop with NFS and local unix processes. So if you're
seeing kernel oplock breaks for files just held by Samba,
Samba has a bug. If you can reproduce it, please file a bug
at bugzilla.samba.org and upload a debug level 10 log of
both smbd processes involved. Please also with debug hires
timestamps = yes.
I am not quite clear on this.
It would appear other Unix processes and other Samba processes are
denied access to the file:
2008/06/19 15:24:08, 0] smbd/oplock.c:oplock_timeout_handler(351)
Oplock break failed for file cur/config.xml -- replying anyway
[2008/06/19 15:24:51, 0] smbd/oplock.c:oplock_timeout_handler(351)
Oplock break failed for file cur/profiles.xml -- replying anyway
[2008/06/19 15:25:21, 0] smbd/oplock.c:oplock_timeout_handler(351)
Oplock break failed for file cur/profiles/vpac.xml -- replying anyway
[2008/06/19 15:25:51, 0] smbd/oplock.c:oplock_timeout_handler(351)
Oplock break failed for file cur/hosts.xml -- replying anyway
[2008/06/19 15:26:21, 0] smbd/oplock.c:oplock_timeout_handler(351)
Oplock break failed for file cur/hosts/vpac.xml -- replying anyway
[2008/06/19 15:26:51, 0] smbd/oplock.c:oplock_timeout_handler(351)
Oplock break failed for file cur/packages.xml -- replying anyway
[2008/06/19 15:27:21, 0] smbd/oplock.c:oplock_timeout_handler(351)
Oplock break failed for file cur/packages/winscp.xml -- replying anyway
Something strange going on here.
Yes, you are right, I probably will need to reproduce this with a higher
level of debugging. Will try that now.
In one of my other messages I quoted the kernel stack trace, but I have
been told that cannot be trusted; it could be using old data.
Brian May
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
