From: Andrew Suarez on

I am looking for some more information on how to make smbd and nfsd play
nicely together in regards to file locking as well as some help
understanding the mechanics of the smbd process and how to clean up
stale connections.

Setup: centos 5, newest smbd and nfsd available, XFS filesystems (for
nice Windows ACL usage)

Certain shares must be shared to both user bases, cifs cannot be used
widely across UNIX environment due to some very old Solaris systems
needing access

Symptoms: Every so often (2 weeks or so) the NFS users will see a
definite lag in performance. The smbd users also see a lag but it's
quite less. By lag, a good example would be a simple ls taking upwards
of 45 seconds to complete. The smbd users might see a fraction of that,
perhaps 8 or 9 seconds but certainly not as long as the nfs users.

My theory is that there is some locking going on based on the above
information. I'm sure plenty of you all run both of these together so I
was looking for any advice on how to make this interaction more smooth.
I can add hardware at will if needed, change filesystem types to one
with better file locking support, etc. Anything to make this phantom lag
go away as it's very crucial that no slowness is observed.

An interesting note and here is where I would like some insight into how
the smbd process works. There are listener processes out there owned by
root that get used up as a connection is made and then the PID owner
changes to the samba user. Once complete, they are returned back to the
system and await new connection attempts. I am noticing that some of
these processes are held open for quite some time (the problem comes up
after about a week) and whatever the user is doing is sending keep
alives; samba is working as intended. However, if the user ran a search
in Windows for example but neglected to close the search window, that
process is held open indefinitely until he closes that or logs out. The
problem I am seeing is after awhile, these processes come 'back to life'
if you will, out of nowhere, they will start to chew up 30% of the CPU
and a heap of memory despite doing absolutely nothing. I am not entirely
comfortable attributing my overall slowness issues to this but it's an
interesting phenomenon. Is there a way for Samba to reclaim these
threads without potentially impacting a user? (Case in point, I don't
care about the user's search window but I do care about a user who is
reading files off a mapped drive.. how to make that distinction is where
I'm looking for clarification). It may be that nothing can be done but
it's worth noting.

From a performance standpoint, are there recommended tuning settings
that you all would suggest? Increasing listeners, etc? I'd love to get
to the bottom of what is causing this random slowness but I am betting
that it's not going to be possible due to the vast array of variables at
play here. If there's anything I can do to make this work with maximum
performance I would love some insight. If there's anything I can clarify
please let me know


To unsubscribe from this list go to the following URL and read the