All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@primarydata.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Christoph Hellwig <hch@lst.de>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	Stable Tree Mailing List <stable@vger.kernel.org>
Subject: Re: [PATCH] nfsd/blocklayout: accept any minlength
Date: Fri, 9 Oct 2015 13:54:22 -0400	[thread overview]
Message-ID: <CAHQdGtQN15nChCy8mzrDBdaU+RTTCvqaSbH1D=e56c2B_+5KiA@mail.gmail.com> (raw)
In-Reply-To: <20151009174556.GA8188@fieldses.org>

On Fri, Oct 9, 2015 at 1:45 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
>
> On Fri, Oct 09, 2015 at 07:04:00PM +0200, Christoph Hellwig wrote:
> > On Fri, Oct 09, 2015 at 11:28:03AM -0400, J. Bruce Fields wrote:
> > > OK, planning to apply for 4.3 just on the assumption that you know what
> > > you're doing, but: I don't get it--it looks like the worst that can
> > > happen here is we just reuturn LAYOUTUNAVAILABLE to LAYOUTGET.
> > > Shouldn't the client then just fall back on normal NFS IO?  Why the
> > > hang?
> >
> > I've just retested with Trond's latest tree and can't reproduce the
> > hang anymore.  It used to fence the client due to a lack of response,
> > but that might have been a different client bug that has now been fixed.
>
> OK, makes sense.
>
> This still looks like a harmless enough change, but is it still stable
> and 4.3 material?
>
> If it affected a released client then it's probably worth it even if
> it's really a client bug.  If it's just something you saw once against
> an -rc1, I'd rather leave it for 4.4.

It's not a client bug.

The server is supposed to comply with the requirements in table 13 of
https://tools.ietf.org/html/rfc5661#section-18.43.3
Note that it should also be returning NFS4ERR_BADLAYOUT (or
NFS4ERR_LAYOUTTRYLATER if loga_minlength == 0) instead of
layoutunavailable if the loga_minlength request cannot be met.

Cheers
  Trond

  reply	other threads:[~2015-10-09 17:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-09 13:03 [PATCH] nfsd/blocklayout: accept any minlength Christoph Hellwig
2015-10-09 15:28 ` J. Bruce Fields
2015-10-09 17:04   ` Christoph Hellwig
2015-10-09 17:45     ` J. Bruce Fields
2015-10-09 17:54       ` Trond Myklebust [this message]
2015-10-09 20:04         ` J. Bruce Fields
2015-10-09 20:14           ` J. Bruce Fields
2015-10-11 13:08           ` Christoph Hellwig
2015-10-12 20:18             ` J. Bruce Fields
2015-10-11 13:03       ` Christoph Hellwig

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='CAHQdGtQN15nChCy8mzrDBdaU+RTTCvqaSbH1D=e56c2B_+5KiA@mail.gmail.com' \
    --to=trond.myklebust@primarydata.com \
    --cc=bfields@fieldses.org \
    --cc=hch@lst.de \
    --cc=linux-nfs@vger.kernel.org \
    --cc=stable@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.