[Samba] Samba process throttled back?

Lang, Rich
Thu, 23 Jun 2011 13:49:23 -0000

Well, it just gets "curiouser and curiouser".

I downloaded, built and installed the latest stable version of Samba (i.e.
3.5.9) on my "inactive" cluster member which is running RedHat ES 5.6.
In case I didn't show this before, here's the output of `uname -a`:
Linux mustang1 2.6.18-238.9.1.el5 #1 SMP Fri Mar 18 12:42:04 EDT 2011 i686 i686
i386 GNU/Linux
Anyway, I create a share and copied the "troublesome" file to that
share and opened it using the VB application that showed such poor performance.
It opened the file and processed it as quickly as if it were on my local hard
drive.  This is more like it.  This is back to how the share used to respond.
When I navigated back to the original copy of the file, the performance went to
pieces again.
Same file, different versions of Samba, different performance.  Looks like I
"fixed" it, although I don't know exactly what was wrong.
So, I wanted to take a wireshark snapshot of the "poor performance" to
see if the client was negotiating the buffer size down over the wire.  In the
meantime, the original file and its folder were moved from the Samba share to a
M$ share on another server.  Oh well - I copied the file back to the Samba
share.  Guess what?  The performance is great - back to where it was before the
problem started.
So - it's not the version of Samba.  It looks like this is an inode
corruption on the disk, although I've run fsck a number of times on the disk
and it always comes up clean.
Hmmmm...there might be some tools that I need to use to keep my shared disk
clean.  We're running the cluster through a pair of HP SmartArray 642 SCSI
interfaces both connected to an MSA 500 G2 disk array with redundant
controllers.  There are four logical disks defined, each of which is defined as
part of a cluster service so it can swing between cluster members in case of a
failure.  Does anyone use this kind of disk array in a shared configuration like
this?