On 08/26/2014 07:59 PM, Trond Myklebust wrote: > On Tue, Aug 26, 2014 at 12:56 PM, Boaz Harrosh <boaz@xxxxxxxxxxxxx> wrote: >> On 08/26/2014 06:36 PM, Trond Myklebust wrote: >>> On Tue, Aug 26, 2014 at 11:24 AM, Matt W. Benjamin <matt@xxxxxxxxxxxx> wrote: >>>> IIUC, the problem is the forechannel slot count, since the call you want to make synchronously is on the forechannel? >> >> >> Matt no top post on a Linux mailing list ;-) >> >>> Yep. layoutcommit will be sent on the fore channel, which is why it >>> can deadlock with the initial layoutget (or whatever operation that >>> triggered the layout recall). >> >> Trond you said below: >>> The above can deadlock if there are no session slots available to send >>> the layoutcommit, in which case the recall won't complete, and the >>> layoutget won't get a reply (which would free up the slot). >> >> Why would the layoutget not-get-a-reply ? >> This is how it goes with Both ganesha server and knfsd last I tested. >> >> [1] >> The LAYOUT_GET cause LAYOUT_RECALL case: (including the lo_commit) >> >> client Server comments >> ~~~~~~ ~~~~~~ ~~~~~~~~ >> LAYOUT_GET ==> >> <== LAYOUT_GET_REPLAY(ERR_RECALL_CONFLICT) >> <--------- fore-channel is free >> <== RECALL >> LAYOUT_COMMIT ==> >> <== LAYOUT_COMMIT_REPLAY >> <--------- fore-channel is free > > Beep! No free slots, so this hangs. > Beep! does not do a very good of a job to explain. Sorry What do you mean? which slot? which channel? Just above your text it says "fore-channel is free" so are you saying it is not free? why not. Please use more then one line of text to explain. It might be clear to you but not to me. >> RECALL_REPLY(NO_MATCHING) => >> <--------- back-channel is free Thanks Boaz -- 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
