|
From: Volker Lendecke on 20 Jun 2008 03:50 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 22 Jun 2008 19:20 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 22 Jun 2008 20:00 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
|
Pages: 1 Prev: [Samba] samba oplocks not breaking Next: [Samba] Problems with the Samba Client |