All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Fields <bfields@fieldses.org>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Dai Ngo <dai.ngo@oracle.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH RFC 1/1] nfsd: Initial implementation of NFSv4 Courteous Server
Date: Wed, 16 Jun 2021 16:30:39 -0400	[thread overview]
Message-ID: <20210616203039.GA6049@fieldses.org> (raw)
In-Reply-To: <50752B0A-A56A-4A80-81AE-32E20754E31F@oracle.com>

On Wed, Jun 16, 2021 at 07:29:37PM +0000, Chuck Lever III wrote:
> 
> 
> > On Jun 16, 2021, at 3:25 PM, Dai Ngo <dai.ngo@oracle.com> wrote:
> > 
> > On 6/16/21 9:32 AM, Chuck Lever III wrote:
> >>> On Jun 16, 2021, at 12:02 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> >>> 
> >>> On Thu, Jun 03, 2021 at 02:14:38PM -0400, Dai Ngo wrote:
> >>>> . instead of destroy the client anf all its state on conflict, only destroy
> >>>> the state that is conflicted with the current request.
> >>> The other todos I think have to be done before we merge, but this one I
> >>> think can wait.
> >> I agree on both points: this one can wait, but the others
> >> should be done before merge.
> > 
> > yes, will do.
> > 
> >> 
> >> 
> >>>> . destroy the COURTESY_CLIENT either after a fixed period of time to release
> >>>> resources or as reacting to memory pressure.
> >>> I think we need something here, but it can be pretty simple.
> >> We should work out a policy now.
> >> 
> >> A lower bound is good to have. Keep courtesy clients at least
> >> this long. Average network partition length times two as a shot
> >> in the dark. Or it could be N times the lease expiry time.
> >> 
> >> An upper bound is harder to guess at. Obviously these things
> >> will go away when the server reboots. The laundromat could
> >> handle this sooner. However using a shrinker might be nicer and
> >> more Linux-y, keeping the clients as long as practical, without
> >> the need for adding another administrative setting.
> > 
> > Can we start out with a simple 12 or 24 hours to accommodate long
> > network outages for this phase?
> 
> Sure. Let's go with 24 hours.
> 
> Bill suggested adding a "clear_locks" like mechanism that could be
> used to throw out all courteous clients at once. Maybe another
> phase 2 project!

For what it's worth, you can forcibly expire a client by writing
"expire" to /proc/fs/nfsd/client/xxx/ctl.  So it shouldn't be hard to
script this, if we add some kind of "courtesy" flag to
client_info_show() and/or a number of seconds since the most recent
renew.

Maybe adding a command like "expire_if_courtesy" would also simplify
that and avoid a race where the renew comes in simultaneously with the
expire command.

Or we could just add a single call to clear all courtesy clients.  But
the per-client approach would allow more flexibility if you wanted (e.g.
to throw out only clients over a certain age).

--b.

  reply	other threads:[~2021-06-16 20:30 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-03 18:14 [PATCH RFC 1/1] nfsd: Initial implementation of NFSv4 Courteous Server Dai Ngo
2021-06-11  8:42 ` dai.ngo
2021-06-16 16:02 ` J. Bruce Fields
2021-06-16 16:32   ` Chuck Lever III
2021-06-16 19:25     ` dai.ngo
2021-06-16 19:29       ` Chuck Lever III
2021-06-16 20:30         ` Bruce Fields [this message]
2021-06-16 19:17   ` dai.ngo
2021-06-16 19:19     ` Calum Mackay
2021-06-16 19:27       ` dai.ngo
2021-06-24 14:02 ` J. Bruce Fields
2021-06-24 19:50   ` dai.ngo
2021-06-24 20:36     ` J. Bruce Fields
2021-06-28 20:23 ` J. Bruce Fields
2021-06-28 23:39   ` dai.ngo
2021-06-29  4:40     ` dai.ngo
2021-06-30  1:35       ` J. Bruce Fields
2021-06-30  8:41         ` dai.ngo
2021-06-30 14:52           ` J. Bruce Fields
2021-06-30 17:51     ` dai.ngo
2021-06-30 18:05       ` J. Bruce Fields
2021-06-30 18:49         ` dai.ngo
2021-06-30 18:55           ` J. Bruce Fields
2021-06-30 19:13             ` dai.ngo
2021-06-30 19:24               ` J. Bruce Fields
2021-06-30 23:48                 ` dai.ngo
2021-07-01  1:16                   ` J. Bruce Fields
2021-06-30 15:13   ` J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210616203039.GA6049@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=dai.ngo@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.