From: Volker Lendecke on
On Fri, Jun 20, 2008 at 02:09:22PM +1000, Brian May wrote:
> I am having (weird) issues with XFS, in that open(...) on certain files
> takes 45 seconds to return. After the file has been opened, the next
> file in the same directory takes 45 seconds. If the file was recently
> opened it returns immediately.
>
> I have raised this on several mailing lists, see:
>
> <http://lists.luv.asn.au/wws/arc/luv-main/2008-06/msg00143.html>
> <http://oss.sgi.com/archives/xfs/2008-06/msg00210.html>
> <http://www.archivum.info/linux-fsdevel(a)vger.kernel.org/2008-06/msg00337.html>
>
> So far it would appear to be Samba is not releasing the oplock when
> another process tries to break it.

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".

Volker
From: Brian May on
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
From: Brian May on
Brian May wrote:
> 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.

https://bugzilla.samba.org/show_bug.cgi?id=5557

Brian May

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba