On Tue, 2013-06-25 at 17:00 +0300, Nadav Shemer wrote: > On Tue, Jun 25, 2013 at 4:43 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Tue, Jun 25, 2013 at 02:51:48PM +0300, Nadav Shemer wrote: > >> 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? > Yes, I believe it is. > Specifically the Linux client treats them all the same (LAYOUTTRYLATER > and RECALLCONFLICT are both mapped to DELAY before passing to > nfs4_async_handle_error) > Do you think there is a case for an exponential backoff in this case > for a specific (non-DELAY) error code? Why do we care? If this is about passing some unit test somewhere, then I frankly don't give a damn. If. OTOH, there is a valid use case where 2 clients must request conflicting layouts for the same file, then let's discuss that specific case. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- 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
