Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Thoughts on mount option to configure client lease renewal time.
Date:   Tue, 16 Aug 2022 09:35:07 +1000
Message-id: <166060650771.5425.13177692519730215643@noble.neil.brown.name>
Precedence: bulk


Currently the Linux NFS renews leases at 2/3 of the lease time advised
by the server.
Some server vendors (Not Exactly Targeting Any Particular Party)
recommend very short lease times - as short a 5 seconds in fail-over
configurations.  This means 1.7 seconds of jitter in any part of the
system can result in leases being lost - but it does achieve fast
fail-over. 

If we could configure a 5 second lease-renewal on the client, but leave
a 60 second lease time on the server, then we could get the best of both
worlds.  Failover would happen quickly, but you would need a much longer
load spike or network partition to cause the loss of leases.

As v4.1 can end the grace period early once everyone checks in, a large
grace period (which is needed for a large lease time) would rarely be a
problem.

So my thought is to add a mount option "lease-renew=5" for v4.1+ mounts.
The clients then uses that number providing it is less than 2/3 of the
server-declared lease time.

What do people think of this?  Is there a better solution, or a problem
with this one?

NeilBrown