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

Jeff Layton jlayton at redhat.com
Mon Dec 1 12:35:48 GMT 2008


On Sun, 30 Nov 2008 20:31:54 -0600
"Steve French" <smfrench at gmail.com> wrote:

> 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.
> 

One of the things I'm working toward here is some consistency in how
"hard" and "soft" mount options are implemented. While I haven't tested
them extensively, I'm pretty convinced from looking at the code that
neither really works as advertised. Thinking this through...

We should only block if we're unable to buffer the data for the send.
Either:

a) the system is low on memory and can't allocate enough to copy

b) the socket buffers are full, and can't be grown any larger

I think "b" is the main worry. That should mainly happen when we've
buffered up a bunch of sends and the receive window on the other end is
closed.

We could do different timeouts for "large" and "small" calls, but what
will that mean in practice? In many (most?) cases though we're not
going to return an error to the user with a timeout, we're going to
return -EAGAIN to the caller of SendReceive or SendReceive2 and then
that caller is going to retry. A smaller timeout doesn't seem like
it's going to make a difference in most cases...

If we do decide that different timeouts here give us something, I still
think it would be better to just set the socket timeout properly before
doing the call. We can call kernel_setsockopt or just set sk_sndtimeo
directly (they're equivalent AFAICT). The perf impact there will be low.

While we're at it, my testing shows that blocking sends give better
performance in general than non-blocking. Is there any reason to keep
non-blocking sends in this code at all? As a mount option, it's not
very helpful -- most users are going to have no idea when to use it.

-- 
Jeff Layton <jlayton at redhat.com>


More information about the linux-cifs-client mailing list