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@xxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
