All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Jeff Layton <jeff.layton@primarydata.com>
Cc: steved@redhat.com, linux-nfs@vger.kernel.org
Subject: Re: [PATCH v3 5/7] nfsdcltrack: update schema to v2
Date: Fri, 12 Sep 2014 11:21:42 -0400	[thread overview]
Message-ID: <20140912152142.GB28915@fieldses.org> (raw)
In-Reply-To: <20140912143621.GA28915@fieldses.org>

On Fri, Sep 12, 2014 at 10:36:21AM -0400, J. Bruce Fields wrote:
> On Fri, Sep 12, 2014 at 10:21:53AM -0400, Jeff Layton wrote:
> > Grace period
> > eventually ends, and its record is purged from the DB.
> > 
> > Now we have a client that has reclaimed some files but that has no
> > record on stable storage.
> > 
> > One possibility is to prematurely expire v4.1+ clients that have not
> > sent a RECLAIM_COMPLETE when the grace period ends.
> > 
> > That seems problematic though -- what about clients that just happen to
> > do an EXCHANGE_ID just before the grace period is going to end, and
> > that get expired before they can issue their RECLAIM_COMPLETE. Will
> > that be a problem for them?
> 
> In that case a client will send a reclaim, get back a NO_GRACE error,
> mark the rest of its state as unrecoverable, send the RECLAIM_COMPLETE,
> and continue normally.  (To the extent it can--signalling affected
> processes or EIOing further attempts to use the unreclaimed state, or
> whatever.)

The one thing the server *could* do in this sort of case is extend the
grace period by a little--I seem to recall the spec giving some leeway
for this kind of thing.

So for example the server could have a heuristics like: extend the grace
period by another second each time we notice there's been an EXCHANGE_ID
or reclaim in the previous second, up to some maximum.  And I suppose it
could also delay the grace period until someone actually attempts a
non-reclaim open.

In isolation a single client slipping in the end like that sounds like a
freak event, but if there's a ton of state to reclaim perhaps it could
become more likely.

I don't think that's a priority, we might just want to make sure we know
how to do that in the future.

But now that I think about it I don't see the existing or proposed
nfsdcltrack stuff tying our hands in any way here.  It just gives the
kernel some extra information, and the kernel still has discretion about
when exactly it wants to end the grace period.

--b.

  reply	other threads:[~2014-09-12 15:21 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-08 16:30 [PATCH v3 0/7] nfs-utils: support for lifting grace period early Jeff Layton
2014-09-08 16:30 ` [PATCH v3 1/7] sm-notify: inform the kernel if there were no hosts to notify Jeff Layton
2014-09-08 16:30 ` [PATCH v3 2/7] nfsdcltrack: update comments in sqlite.c Jeff Layton
2014-09-11 15:53   ` J. Bruce Fields
2014-09-08 16:30 ` [PATCH v3 3/7] nfsdcltrack: rename CLD_* constants with CLTRACK_* prefixes Jeff Layton
2014-09-08 16:30 ` [PATCH v3 4/7] nfsdcltrack: overhaul database initializtion Jeff Layton
2014-09-08 16:30 ` [PATCH v3 5/7] nfsdcltrack: update schema to v2 Jeff Layton
2014-09-11 19:55   ` J. Bruce Fields
2014-09-11 20:28     ` Jeff Layton
2014-09-12 13:36       ` Jeff Layton
2014-09-12 14:21         ` Jeff Layton
2014-09-12 14:36           ` J. Bruce Fields
2014-09-12 15:21             ` J. Bruce Fields [this message]
2014-09-12 15:54               ` Trond Myklebust
2014-09-12 16:05                 ` J. Bruce Fields
2014-09-12 16:07                 ` Jeff Layton
2014-09-12 16:29                   ` Trond Myklebust
2014-09-12 16:33                     ` Jeff Layton
2014-09-12 15:42           ` Trond Myklebust
2014-09-08 16:30 ` [PATCH v3 6/7] nfsdcltrack: grab the NFSDCLTRACK_RECLAIM_COMPLETE env var if it's present Jeff Layton
2014-09-08 16:30 ` [PATCH v3 7/7] nfsdcltrack: fetch NFSDCLTRACK_GRACE_START out of environment Jeff Layton

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=20140912152142.GB28915@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=jeff.layton@primarydata.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=steved@redhat.com \
    /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.