All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy@hammerspace.com>
To: "aglo@umich.edu" <aglo@umich.edu>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"Anna.Schumaker@netapp.com" <Anna.Schumaker@netapp.com>
Subject: Re: [PATCH 6/9] pNFS: Handle NFS4ERR_OLD_STATEID on layoutreturn by bumping the state seqid
Date: Thu, 12 Sep 2019 16:29:19 +0000	[thread overview]
Message-ID: <56f43f996e42e970e1633aec5a12c756bbb3e1c7.camel@hammerspace.com> (raw)
In-Reply-To: <CAN-5tyGOjTGft-rvqD7EzhCS9CK1dNKpUq9hRZTqs8ivLZ0_cg@mail.gmail.com>

On Thu, 2019-09-12 at 11:14 -0400, Olga Kornievskaia wrote:
> Hi Trond,
> 
> Can you explain why are we just bumping the seqid by 1 instead of
> what
> it was currently using to update it to the current value which could
> be more than off by one? I'm just speculating that we'll see the same
> behavior that we'll get the ERR_OLD_STATEID incremented by one until
> the current value?

We only bump by 1 if we see that we're already above the seqid of the
current layout stateid. Otherwise, we sync to the value of that layout
stateid before retrying.

> 
> On Tue, Sep 10, 2019 at 4:09 AM Trond Myklebust <trondmy@gmail.com>
> wrote:
> > If a LAYOUTRETURN receives a reply of NFS4ERR_OLD_STATEID then
> > assume we've
> > missed an update, and just bump the stateid.
> > 
> > Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
> > ---
> >  fs/nfs/nfs4proc.c |  2 +-
> >  fs/nfs/pnfs.c     | 18 ++++++++++++++----
> >  fs/nfs/pnfs.h     |  4 ++--
> >  3 files changed, 17 insertions(+), 7 deletions(-)
> > 
> > diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> > index a5deb00b5ad1..cbaf6b7ac128 100644
> > --- a/fs/nfs/nfs4proc.c
> > +++ b/fs/nfs/nfs4proc.c
> > @@ -9069,7 +9069,7 @@ static void nfs4_layoutreturn_done(struct
> > rpc_task *task, void *calldata)
> >         server = NFS_SERVER(lrp->args.inode);
> >         switch (task->tk_status) {
> >         case -NFS4ERR_OLD_STATEID:
> > -               if (nfs4_layoutreturn_refresh_stateid(&lrp-
> > >args.stateid,
> > +               if (nfs4_layout_refresh_old_stateid(&lrp-
> > >args.stateid,
> >                                         &lrp->args.range,
> >                                         lrp->args.inode))
> >                         goto out_restart;
> > diff --git a/fs/nfs/pnfs.c b/fs/nfs/pnfs.c
> > index abc7188f1853..bb80034a7661 100644
> > --- a/fs/nfs/pnfs.c
> > +++ b/fs/nfs/pnfs.c
> > @@ -359,9 +359,10 @@ pnfs_clear_lseg_state(struct
> > pnfs_layout_segment *lseg,
> >  }
> > 
> >  /*
> > - * Update the seqid of a layout stateid
> > + * Update the seqid of a layout stateid after receiving
> > + * NFS4ERR_OLD_STATEID
> >   */
> > -bool nfs4_layoutreturn_refresh_stateid(nfs4_stateid *dst,
> > +bool nfs4_layout_refresh_old_stateid(nfs4_stateid *dst,
> >                 struct pnfs_layout_range *dst_range,
> >                 struct inode *inode)
> >  {
> > @@ -377,7 +378,15 @@ bool
> > nfs4_layoutreturn_refresh_stateid(nfs4_stateid *dst,
> > 
> >         spin_lock(&inode->i_lock);
> >         lo = NFS_I(inode)->layout;
> > -       if (lo && nfs4_stateid_match_other(dst, &lo->plh_stateid))
> > {
> > +       if (lo &&  pnfs_layout_is_valid(lo) &&
> > +           nfs4_stateid_match_other(dst, &lo->plh_stateid)) {
> > +               /* Is our call using the most recent seqid? If so,
> > bump it */
> > +               if (!nfs4_stateid_is_newer(&lo->plh_stateid, dst))
> > {
> > +                       nfs4_stateid_seqid_inc(dst);
> > +                       ret = true;
> > +                       goto out;
> > +               }
> > +               /* Try to update the seqid to the most recent */
> >                 err = pnfs_mark_matching_lsegs_return(lo, &head,
> > &range, 0);
> >                 if (err != -EBUSY) {
> >                         dst->seqid = lo->plh_stateid.seqid;
> > @@ -385,6 +394,7 @@ bool
> > nfs4_layoutreturn_refresh_stateid(nfs4_stateid *dst,
> >                         ret = true;
> >                 }
> >         }
> > +out:
> >         spin_unlock(&inode->i_lock);
> >         pnfs_free_lseg_list(&head);
> >         return ret;
> > @@ -1475,7 +1485,7 @@ int pnfs_roc_done(struct rpc_task *task,
> > struct inode *inode,
> >                 *ret = -NFS4ERR_NOMATCHING_LAYOUT;
> >                 return 0;
> >         case -NFS4ERR_OLD_STATEID:
> > -               if (!nfs4_layoutreturn_refresh_stateid(&arg-
> > >stateid,
> > +               if (!nfs4_layout_refresh_old_stateid(&arg->stateid,
> >                                         &arg->range, inode))
> >                         break;
> >                 *ret = -NFS4ERR_NOMATCHING_LAYOUT;
> > diff --git a/fs/nfs/pnfs.h b/fs/nfs/pnfs.h
> > index 3ef3756d437c..f8a38065c7e4 100644
> > --- a/fs/nfs/pnfs.h
> > +++ b/fs/nfs/pnfs.h
> > @@ -261,7 +261,7 @@ int pnfs_destroy_layouts_byfsid(struct
> > nfs_client *clp,
> >                 bool is_recall);
> >  int pnfs_destroy_layouts_byclid(struct nfs_client *clp,
> >                 bool is_recall);
> > -bool nfs4_layoutreturn_refresh_stateid(nfs4_stateid *dst,
> > +bool nfs4_layout_refresh_old_stateid(nfs4_stateid *dst,
> >                 struct pnfs_layout_range *dst_range,
> >                 struct inode *inode);
> >  void pnfs_put_layout_hdr(struct pnfs_layout_hdr *lo);
> > @@ -798,7 +798,7 @@ static inline void
> > nfs4_pnfs_v3_ds_connect_unload(void)
> >  {
> >  }
> > 
> > -static inline bool nfs4_layoutreturn_refresh_stateid(nfs4_stateid
> > *dst,
> > +static inline bool nfs4_layout_refresh_old_stateid(nfs4_stateid
> > *dst,
> >                 struct pnfs_layout_range *dst_range,
> >                 struct inode *inode)
> >  {
> > --
> > 2.21.0
> > 
-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com



      reply	other threads:[~2019-09-12 16:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-09 14:00 [PATCH 1/9] pNFS: Ensure we do clear the return-on-close layout stateid on fatal errors Trond Myklebust
2019-09-09 14:00 ` [PATCH 2/9] NFSv4: Clean up pNFS return-on-close error handling Trond Myklebust
2019-09-09 14:00   ` [PATCH 3/9] NFSv4: Handle NFS4ERR_DELAY correctly in return-on-close Trond Myklebust
2019-09-09 14:00     ` [PATCH 4/9] NFSv4: Handle RPC level errors in LAYOUTRETURN Trond Myklebust
2019-09-09 14:01       ` [PATCH 5/9] NFSv4: Add a helper to increment stateid seqids Trond Myklebust
2019-09-09 14:01         ` [PATCH 6/9] pNFS: Handle NFS4ERR_OLD_STATEID on layoutreturn by bumping the state seqid Trond Myklebust
2019-09-09 14:01           ` [PATCH 7/9] NFSv4: Fix OPEN_DOWNGRADE error handling Trond Myklebust
2019-09-09 14:01             ` [PATCH 8/9] NFSv4: Handle NFS4ERR_OLD_STATEID in CLOSE/OPEN_DOWNGRADE Trond Myklebust
2019-09-09 14:01               ` [PATCH 9/9] NFSv4: Handle NFS4ERR_OLD_STATEID in LOCKU Trond Myklebust
2019-09-16 19:37                 ` Olga Kornievskaia
2019-09-11 20:13               ` [PATCH 8/9] NFSv4: Handle NFS4ERR_OLD_STATEID in CLOSE/OPEN_DOWNGRADE Olga Kornievskaia
2019-09-11 20:56                 ` Trond Myklebust
2019-09-12 15:01                   ` Olga Kornievskaia
2019-09-12 15:04                     ` Olga Kornievskaia
2019-09-16 19:39                     ` Olga Kornievskaia
2019-09-12 15:14           ` [PATCH 6/9] pNFS: Handle NFS4ERR_OLD_STATEID on layoutreturn by bumping the state seqid Olga Kornievskaia
2019-09-12 16:29             ` Trond Myklebust [this message]

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=56f43f996e42e970e1633aec5a12c756bbb3e1c7.camel@hammerspace.com \
    --to=trondmy@hammerspace.com \
    --cc=Anna.Schumaker@netapp.com \
    --cc=aglo@umich.edu \
    --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.