Re: [PATCH] nfsd/blocklayout: accept any minlength

["J. Bruce Fields" <bfields@fieldses.org>]

On Fri, Oct 09, 2015 at 01:54:22PM -0400, Trond Myklebust wrote:
> 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.

I had some ideas that layouts were something a server could decline just
on random whim.  Rereading that section.... OK, looks like I was
confused, TRYLATER is the closest we come to random whim.

So the following condition on the alignments of the offset also looks
wrong.  Christoph, should it be rounding the offset down instead of
rejecting in that case?

And other layoutunavailable cases might need review too.

--b.