Linux-NFS Archive on lore.kernel.org
 help / color / Atom feed
* v3 timeout behavior
@ 2020-06-17 16:04 Olga Kornievskaia
  2020-06-17 17:20 ` Olga Kornievskaia
  0 siblings, 1 reply; 2+ messages in thread
From: Olga Kornievskaia @ 2020-06-17 16:04 UTC (permalink / raw)
  To: linux-nfs

Hi folks,

I have a question whether or not the current client's behaviour is
desirable. Current behaviour: every time a v3 operation is re-sent to
the server we update (double) the timeout. There is no distinction
between whether or not the previous timer had expired before the
re-sent happened.

Here's the scenario:
1. Client sends a v3 operation
2. Server RST-s the connection (prior to the timeout) (eg., connection
is immediately reset)
3. Client re-sends a v3 operation but the timeout is now 120sec.

As a result, an application sees 2mins pause. Where as if a connection
reset didn't change the timeout value, the client would have re-tried
(the 3rd time) after 60secs.

Question: so in sunrcp if we get errors CONNREST/CONNABORTED, should
we skip adjusting the timeout?

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: v3 timeout behavior
  2020-06-17 16:04 v3 timeout behavior Olga Kornievskaia
@ 2020-06-17 17:20 ` Olga Kornievskaia
  0 siblings, 0 replies; 2+ messages in thread
From: Olga Kornievskaia @ 2020-06-17 17:20 UTC (permalink / raw)
  To: linux-nfs

On Wed, Jun 17, 2020 at 12:04 PM Olga Kornievskaia <aglo@umich.edu> wrote:
>
> Hi folks,
>
> I have a question whether or not the current client's behaviour is
> desirable. Current behaviour: every time a v3 operation is re-sent to
> the server we update (double) the timeout. There is no distinction
> between whether or not the previous timer had expired before the
> re-sent happened.
>
> Here's the scenario:
> 1. Client sends a v3 operation
> 2. Server RST-s the connection (prior to the timeout) (eg., connection
> is immediately reset)
> 3. Client re-sends a v3 operation but the timeout is now 120sec.
>
> As a result, an application sees 2mins pause. Where as if a connection
> reset didn't change the timeout value, the client would have re-tried
> (the 3rd time) after 60secs.
>
> Question: so in sunrcp if we get errors CONNREST/CONNABORTED, should
> we skip adjusting the timeout?

This is what I have in mind:
aglo@localhost linux-nfs]$ git diff
diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
index 61b21daf..26be473 100644
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -2413,7 +2413,8 @@ void rpc_force_rebind(struct rpc_clnt *clnt)
                goto out_exit;
        }
        task->tk_action = call_encode;
-       rpc_check_timeout(task);
+       if (status != -ECONNRESET && status != -ECONNABORTED)
+               rpc_check_timeout(task);
        return;
 out_exit:
        rpc_call_rpcerror(task, status);

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-17 16:04 v3 timeout behavior Olga Kornievskaia
2020-06-17 17:20 ` Olga Kornievskaia

Linux-NFS Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-nfs/0 linux-nfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-nfs linux-nfs/ https://lore.kernel.org/linux-nfs \
		linux-nfs@vger.kernel.org
	public-inbox-index linux-nfs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-nfs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git