samba - Sep 2002 - samba-2.2.* slow when lock files are on a NFS file system

Note that I also posted this to comp.protocols.smb under the subject
Lock files must not be on an NFS file system.  I don't know how closely
you follow that group.

On Feb 7 2002 I sent out a message titled
samba-2.2.2 slower than samba-2.0.7 on Solaris
where I described a problem where any file access encountered a 3 to 4
second delay to open the file.  After trying again with samba-2.2.5 and
finding the same problem, I decided to work harder to find the cause of
the problem.  What I discovered is that if the lock files are placed on
an NFS file system, samba-2.2.* takes 3 to 4 seconds to open any file.
If the lock files are on a local disk then there is no such delay.
I don't know if this is a bug or just the way it works.  If this is to
be a restriction, it would be a good thing if this were documented
somewhere.  Perhaps a note in the man page for smb.conf under the
lock directory  section.

Some details on how I have this set up.  We are running Samba on four
Solaris 8 machines, one of them is a Sparc 10 (a slow machine).  I
installed Samba in  /opt/local/samba  which is mounted by the automounter.
This ends up being local on one machine and nfs mounted on the other three.
In order to keep the log and lock files seperate, I had the following in
my smb.conf:
log file = /opt/local/samba/var/logs/%h/log.%m
lock directory = /opt/local/samba/var/locks/%h
For samba-2.2.5 I added:
pid directory = /opt/local/samba/var/locks/%h
This worked fine for samba-2.0.7.  It was a big problem for samba-2.2.5.
After changing the lock directory to /var/samba/locks, the 3 to 4 second
delay went away.

After doing the above, I realized that the secrets.tdb file in the private
directory was also on an NFS file system and was being shared by all four
machines.  This did not seem like a good thing.  I replaced the secrets.tdb
file with a symbolic link to /var/samba/private/secrets.tdb and found that
Samba is happy to follow the link and create the secrets.tdb file in
/var/samba/private.  I expect that this is more correct although I had not
observed any problem with it the old way.

Tom schulz
Applied Dynamics Intl.
schulz@adi.com

On Thu, Sep 19, 2002 at 04:16:43PM -0400, Thomas Schulz
wrote:
> Note that I also posted this to comp.protocols.smb under the subject
> Lock files must not be on an NFS file system.  I don't know how closely
> you follow that group.
> 
> On Feb 7 2002 I sent out a message titled
> samba-2.2.2 slower than samba-2.0.7 on Solaris
> where I described a problem where any file access encountered a 3 to 4
> second delay to open the file.  After trying again with samba-2.2.5 and
> finding the same problem, I decided to work harder to find the cause of
> the problem.  What I discovered is that if the lock files are placed on
> an NFS file system, samba-2.2.* takes 3 to 4 seconds to open any file.
> If the lock files are on a local disk then there is no such delay.
> I don't know if this is a bug or just the way it works.  If this is to
> be a restriction, it would be a good thing if this were documented
> somewhere.  Perhaps a note in the man page for smb.conf under the
> lock directory  section.
> 
> Some details on how I have this set up.  We are running Samba on four
> Solaris 8 machines, one of them is a Sparc 10 (a slow machine).  I
> installed Samba in  /opt/local/samba  which is mounted by the automounter.
> This ends up being local on one machine and nfs mounted on the other three.
> In order to keep the log and lock files seperate, I had the following in
> my smb.conf:
> log file = /opt/local/samba/var/logs/%h/log.%m
> lock directory = /opt/local/samba/var/locks/%h
> For samba-2.2.5 I added:
> pid directory = /opt/local/samba/var/locks/%h
> This worked fine for samba-2.0.7.  It was a big problem for samba-2.2.5.
> After changing the lock directory to /var/samba/locks, the 3 to 4 second
> delay went away.
> 
> After doing the above, I realized that the secrets.tdb file in the private
> directory was also on an NFS file system and was being shared by all four
> machines.  This did not seem like a good thing.  I replaced the secrets.tdb
> file with a symbolic link to /var/samba/private/secrets.tdb and found that
> Samba is happy to follow the link and create the secrets.tdb file in
> /var/samba/private.  I expect that this is more correct although I had not
> observed any problem with it the old way.
Do *not* share any of the Samba lock files or the tdb files. This *will*
break Samba.

Also, putting tdb files on an NFS drive is not recommended as tdb makes
heavy use of fcntl locking (slow over NFS).

Jeremy.