samba - Apr 2009 - Occasional loss of connection between Windows clients and Samba under stress

Problem seen on more than 1 server, and more than 1 client type.

Windows clients = Windows Server 2003 or Windows XP sp3.

Samba = 3.0-25b or 3.2.3 (clustered)

My clients connect ok, and I have no problems with basic operations - copying
files etc. However, if I run applications in a cygwin
environment that create decent stress e.g. writing a 1GB file with iozone - I
get a failure with 'no route to host or network' reported.
I've a perl script that hits similar issues - multiple processes run
creating files, and some - but not all - of the processes tend to hit
an issue that stops the process opening a file. Generally, the share remains
accessible, but sometimes it gets listed as disconnected
and I need to disconnect and re-mount.

I'm guessing this is somehow a bad reaction to a slow response. Is there a
timeout
I could experiment with ? Anyone else seen this  ? Debug suggestions ?

Thanks,

Gavin

On Fri, 2009-04-10 at 12:30 +0000, Brebner, Gavin wrote:
> Problem seen on more than 1 server, and more than 1 client type.
> Windows clients = Windows Server 2003 or Windows XP sp3.
> Samba = 3.0-25b or 3.2.3 (clustered)
> My clients connect ok, and I have no problems with basic operations -
copying files etc. However, if I run applications in a cygwin
> environment that create decent stress e.g. writing a 1GB file with iozone -
I get a failure with 'no route to host or network' reported.
> I've a perl script that hits similar issues - multiple processes run
creating files, and some - but not all - of the processes tend to hit
> an issue that stops the process opening a file. Generally, the share
remains accessible, but sometimes it gets listed as disconnected
> and I need to disconnect and re-mount.
> I'm guessing this is somehow a bad reaction to a slow response. Is
there a timeout
> I could experiment with ? Anyone else seen this  ? Debug suggestions ?
bad NIC - and/or - bad switch

Would be my first guesses.

I'd try to duplicate the failure using non-CIFS traffic. Generate myriad
HTTP requests, or ping floods with large packet size, etc...