[cifs-protocol] cifs client timeouts and hard/soft mounts

[Steve French]

On Mon, Dec 6, 2010 at 11:06 AM, Christopher R. Hertel <crh at samba.org> wrote:
> simo wrote:
>> On Mon, 2010-12-06 at 10:28 -0600, Steve French wrote:
>>> On Sun, Dec 5, 2010 at 10:34 PM, Volker Lendecke
>>> <Volker.Lendecke at sernet.de> wrote:
>>>> Hi!
>>>>
>>>> On Sun, Dec 05, 2010 at 08:16:46PM -0600, Steve French wrote:
>>>>> I am more worried about firewall rule changes and similar events
>>>>> than about broken servers - but the idea of waiting forever on stat
>>>>> to a server that is never going to respond seems odd.
>>>> That would be a strange fw rule that allows SMBEcho but not
>>>> other SMB requests. I think if someone puts up such a silly
>>>> rule, some pain is deserved :-)
>>> Aaah - remember the proxies that cut out "chatty" smb traffic by
>>> responding on behalf of remote servers in the interest of optimizing
>>> traffic over slow links :)
>>
>> They better send their own smb echos to remote servers then ...
>
> The client-end proxy node is only interested in whether or not its peer node
> is up and running.  The peer node, at the server end of the link, should be
> responsible for knowing when the actual server is down.
>
> ...but this goes back to my question.  How much responsibility does the
> Linux CIFS client have to ensure that the connection and server are both
> working properly, and how much responsibility falls to the WAN accelerator?
>
> I think it makes sense to do a little to mitigate WAN accelerator problems,
> but the CIFS client needs to be as generic as possible so that it works well
> in all environments.

That is a good broad "design goal"
Obviously using smb echo will help.  In the smb2 code, I issued an smb2
at mount time to do a rough estimate of link speed, but with both cifs and
smb2 code we need to be issuing an echo (at least) when the server is
unresponsive, but we may find that the action to take soft/hard, retry forver
vs. giveup after one or two cancel/retry takes some experimentation to
get right.



-- 
Thanks,

Steve