[cifs-protocol] [Pfif] [REG: 110120160951867] Requesting clarification of CIFS client timeout behavior
Volker.Lendecke at SerNet.DE
Fri Dec 3 13:21:28 MST 2010
On Fri, Dec 03, 2010 at 01:50:11PM -0500, Jeff Layton wrote:
> > Probably needs two tests. One to see what happens if the (single)
> > connection is lost, and another to see what happens if a single operation
> > takes a very, very long time to complete (as you describe).
> I did an experiment with this on win2k8. I first doctored an smbd to
> discard write requests. When I try to copy a file to this host (via
> copy.exe), the server usually waits a little while (the time seems to
> vary between 30-60s or so), sends a single echo request and then
> reconnects the socket if it still doesn't get a write reply in about
> 30s. copy.exe then says "The specified network name is no longer
> available." Heh.
> That said, the behavior seems to be really inconsistent. In at least
> one case, no echo was sent and the socket was shut down <30s after the
> write request was sent.
> The timeout before sending an echo also seems to vary quite a bit. My
> suspicion is that that indicates that the client has the echo ping on a
> separate timer, and just selectively sends it whenever the timer pops
> based on certain criteria.
Probably all this timeout stuff varies too much with
different application behaviours. I have the same discussion
right now with the opposite direction: How can a server
reliably tell that a client died hard? The question here is:
When can we reliably throw away share mode entries? A
colleague just measured a W2k8 timeout of 5 minutes in this
case, but is this dependable? I suspect we have to develop
our own policies for this.
More information about the cifs-protocol