Re: LAYOUTGET and NFS4ERR_DELAY: a few questions

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

On Tue, Jun 25, 2013 at 02:51:48PM +0300, Nadav Shemer wrote:
> On Mon, Jun 24, 2013 at 10:31 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> > Attempting a summary: the constant delay is traditional behavior going
> > back to NFSv3, and the exponential backoff was added to handle DELAY
> > returns on OPEN due to delegation conflicts.
> >
> > And it would likely be tough to justify another client change here
> > without a similar case where the spec clearly has the server returning
> > DELAY to something that needs to be retried quickly.
> >
> > Not understanding your case, it doesn't sound like the result of any
> > real requirement but rather an implementation detail that you probably
> > want to fix in the server.
> Well, a LAYOUTGET may cause a conflicting layout to be recalled (f.e.
> RAID in object storage - RFC 5664, 11.).
> Is that not similar to the
> OPEN case?

I'd expect there to be more options in the LAYOUTGET case, since a
client can always fall back to MDS IO in the case of LAYOUTGET failure,
whereas a failed OPEN is fatal.

> This makes me ponder. If the server blocks while waiting for
> conflicting layouts to be recalled, I think we can theoretically reach
> a deadlock (if we take up all the nfsd threads or all the clients'
> session slots): client A hold layout to file X, and requests layout to
> file Y, while client B holds layout to file Y and requests layout to
> file X.
> To avoid this, we pretty much have to return DELAY for LAYOUTGET

I agree that you wouldn't want to block waiting for a client to return a
layout.  Is this a case for NFS4ERR_LAYOUTTRYLATER?

--b.