[cifs-protocol] [Pfif] [REG: 110120160951867] Requesting clarification of CIFS client timeout behavior

[Volker Lendecke]

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.

Volker