On Fri, Oct 12, 2007 at 01:57:04PM +0200, Willeke, Jochen wrote:
Hi,
Possibly a stupid question, but has someone ran
wireshark/tcpdump/windump
on the client side to verify that it is actually the client waiting
after
a filer response, and not just network latency?
Yes i did a tracing. And you see that the client is not waiting. Here some output
No time SRC DEST Protocol Info 282 0.000145 client nafiler SMB Write AndX Request, FID: 0x026b, 36 bytes at offset 0
283 0.001178 nafiler client SMB Write AndX Response, FID: 0x026b, 36 bytes
284 0.056002 client nafiler SMB Close Request, FID: 0x026b
285 0.000391 nafiler client SMB Close Response, FID: 0x026b
This is only one examlpe. The filer seems to be the faster part within this connection, doesn't it?
Assuming this trace was captured on the client, yes I'd say so, although only seeing a Write AndX and a Close, I wouldn't know if those naturally have a delay like that (or in a particular program) without seeing a bunch of calls next to eachother, ideally, the same calls. I'll take your word for it.
But what causes the client to wait so long?? I was only creating a file from my client on that share.
I guess it depends what the client is doing. We have seen Firefox rebuild a configuration cache that gets stored on our server and it writes output one line at a time closing the file inbetween and it is quite slow, the operation takes almost 20 seconds sometimes. When we upgraded our Samba servers infront of the Netapp NFS share, that time was cut down approx in half, but that did not prevent the client from doing something stupid (write line by line to the network). We did not try netapp CIFS to see what happens. We are just starting to use the netapp CIFS at all, we have been 100% NFS up until now with an existing pair of samba servers.