Re: cifs client commands/requests timeout values

On Wed, May 12, 2010 at 10:41 AM, Steve French <[email protected]> wrote:
> On Wed, May 12, 2010 at 10:04 AM, Shirish Pargaonkar
> <[email protected]> wrote:
>> Is it reasonable for a std op command like get path info to expect response
>> in 15 seconds when it happens to be a 50th command lined up behind
>> 49 long op commands like 56 KBytes reads/writes.
>>
>>
>>        if (long_op == CIFS_STD_OP)
>>                timeout = 15 * HZ;
>>        else if (long_op == CIFS_VLONG_OP) /* e.g. slow writes past EOF */
>>                timeout = 180 * HZ;
>>        else if (long_op == CIFS_LONG_OP)
>>                timeout = 45 * HZ; /* should be greater than
>>
>> Should not timeout value be calculated value based on some criterion
>> like what_kind_of and how_many commands/requests are in the pipeline
>> on that socket at the client end?
>
> Samba should be almost completely async for reads/writes, so for
> recent Samba query path infos should not be heavily impacted by
> reads/writes (for other unrelated inodes) that are blocked on disk i/o
>
>> Above timeout values are reasonable if an individual command was the
>> only command/request sent.
>
> Lengthening the timeout based on the current # of requests on the wire
> is worth experimenting with, but can have unpleasant sideeffects (user
> may not want to wait 10 minutes to find out E_HOSTDOWN)
>
>
> --
> Thanks,
>
> Steve
>

I think more than number of commands, it depends on how data intensive
commands are i.e. a 40 read/writes with small data buffers as opposed to
40 read/write with large data (e.g. 56KB) buffers (which would tax network
resources like socket send/receive buffers or other resources like page cache
on both, server and client).
Perhaps calibrate timeout value based on past response time from the server
like a sliding timeout value.

But an indefinite wait interruptible by signals as part of -o hard (by default)
mount option sounds reasonable and doable.