[Bug 15136] New: Access to cifs gets stuck for a while (>20s) after disconnecting from network

[Bug 15136] New: Access to cifs gets stuck for a while (>20s) after disconnecting from network

[samba-bugs]

https://bugzilla.samba.org/show_bug.cgi?id=15136

            Bug ID: 15136
           Summary: Access to cifs gets stuck for a while (>20s) after
                    disconnecting from network
           Product: CifsVFS
           Version: 4.x
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: kernel fs
          Assignee: sfrench@samba.org
          Reporter: wangrong@uniontech.com
        QA Contact: cifs-qa@samba.org
  Target Milestone: ---

Created attachment 17460
  --> https://bugzilla.samba.org/attachment.cgi?id=17460&action=edit
patch for code update

After the network is interrupted, a new SMB request will wait for a
fixed 10 seconds for network reconnection before sending, and return an
error if it times out.

Because 10 seconds is too long and there are operation retries, system
calls (such as stat) take a long time (greater than 20 seconds), which
makes application respond slowly.

Here, the duration of waiting for network reconnection is exposed to
the user space through the mount option, which is convenient for users
and applications to set according to the actual situation.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

[Bug 15136] Access to cifs gets stuck for a while (>20s) after disconnecting from network

[samba-bugs]

https://bugzilla.samba.org/show_bug.cgi?id=15136

--- Comment #1 from Enzo Matsumiya <ematsumiya@suse.de> ---
Hi, thanks for the patch. This is also a problem I've been trying to solve, but
haven't came up with a good solution so far.

You set SMB_WAIT_RECONNECT_TIMEOUT_MIN to 0, but that would conflict with the
socket timeout which is 7 seconds. This is also stated above the loop in
smb2pdu.c:

> ...
>  189         /*
>  190          * Give demultiplex thread up to 10 seconds to each target available for
>  191          * reconnect -- should be greater than cifs socket timeout which is 7
>  192          * seconds.
>  193          */
>  194         while (server->tcpStatus == CifsNeedReconnect) {
> ...

Those 7 seconds are also hardcoded (connect.c):

> 2951         /*
> 2952          * Eventually check for other socket options to change from
> 2953          * the default. sock_setsockopt not used because it expects
> 2954          * user space buffer
> 2955          */
> 2956         socket->sk->sk_rcvtimeo = 7 * HZ;

(bear in mind that this value predates the 2.6 kernel, IOW I don't know the
reasoning to choosing such value)

Maybe we could reduce the hardcoded values and/or apply such mount option to
the socket instead, and, then, base the reconnect on sk_rcvtimeo? Just an idea.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

[Bug 15136] Access to cifs gets stuck for a while (>20s) after disconnecting from network

[samba-bugs]

https://bugzilla.samba.org/show_bug.cgi?id=15136

--- Comment #2 from wangrong <wangrong@uniontech.com> ---
Hi, Thanks for your reply and suggestion

I want to explain the design intent of wait_reconnect_timeout, it is used to
set the strategy for the application to wait for reconnection.
    wait_reconnect_timeout == 0, the application does not want to wait, and
returns as soon as it detects that the connection is unavailable.
    0 < wait_reconnect_timeout <= sk_rcvtimeo, the application wants to try to
wait, but is not guaranteed to complete a connection attempt.
    sk_rcvtimeo < wait_reconnect_timeout, the application wants to make sure a
connection attempt completes. This is the behavior of the current code, but
providing the wait_reconnect_timeout mount option gives the application more
choices.

Would it be better to provide both sk_rcvtimeo and wait_reconnect_timeout mount
options? it avoids hardcode.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.