[linux-cifs-client] Re: [PATCH 6/6] cifs: don't retry on blocking sends

[Steve French]

The large write case is unique for a few reasons, (the write past end
of file is treated differently for the timeout on waiting for
response, but is not the issue here on tcp send), but primarily
because a shorter timeout will increase the possibility of data
corruption, and the write SMB request is so much larger than the
typical case.

Waiting too long (20 seconds or more) on a firewall or stuck tcp
session could be very annoying for the other 90%+ of the (non-SMB
write) requests though and would make the cifs mount appear
unresponsive.

On Sun, Nov 30, 2008 at 7:21 PM, Jeff Layton <jlayton at redhat.com> wrote:
> On Sun, 30 Nov 2008 19:02:22 -0600
> "Steve French" <smfrench at gmail.com> wrote:
>
>> Presumably there is slightly less overhead (since 99%+ of all tcp
>> kernel send message calls don't timeout/retry) in not having to reset
>> the send timeout over and over.   We need a longer send timeout for
>> large writes (> 56K) than for typical requests (100 bytes or so for
>> the header is all that is sent)... so presumably is more efficient to
>> set a low timeout (somewhere from 1 to 5 seconds) and retry a few
>> times for the large write case.
>>
>
> I'm not sure I buy this...
>
> Why not just set the sndtimeo for the maximum timeout needed? If 99%+
> of all sends will not time out then there's little harm in letting the
> send timeout be a longer for the small calls. If we're out of memory
> to buffer the send, then we're out of memory. How does setting a short
> timeout for small calls make this more efficient?
>
> --
> Jeff Layton <jlayton at redhat.com>
>



-- 
Thanks,

Steve