On Mar 19, 2012, at 5:49 PM, Myklebust, Trond wrote: > On Mon, 2012-03-19 at 21:32 +0000, Adamson, Andy wrote: >> On Mar 16, 2012, at 11:12 AM, Andy Adamson wrote: >> >>> On Thu, Mar 15, 2012 at 8:27 PM, Myklebust, Trond >>> <Trond.Myklebust@xxxxxxxxxx> wrote: >>>> On Thu, 2012-03-15 at 14:40 -0400, andros@xxxxxxxxxx wrote: >>>>> From: Andy Adamson <andros@xxxxxxxxxx> >>>>> >>>>> Register a new filelayout DS rpc_action callback for sleeping on the fore >>>>> channel slot table waitq. Avoid any additional RPC FSM states >>>>> (such as timeout) when waking up to an invalid deviceid and reset >>>>> the task for io to the MDS. >>>> >>>> Why can't you simply put this call to filelayout_write_sleepon_cb in >>>> filelayout_write_prepare (before calling nfs41_setup_sequence())? >>> >>> I guess I can. Will do. >> >> Actually, I that won't work. >> >>> >>> -->Andy >>> >>>> >>>> Since nothing is going to change the task->tk_action if >>>> nfs41_setup_sequence() puts you to sleep, what value does the callback >>>> add? >> >> The rpc_action remains rpc_call_prepare. But! We want the tasks coming off the failed DS fore channel slot table queue to be redirected to the MDS nfs_XXX_prepare, not the filelayout_xxx_prepare. > > So? Calling rpc_restart_call_prepare() will have exactly the same effect > if you do it within filelayout_xxx_prepare as it will within a callback. Sigh. For some reason I removed the call to rpc_restart_call_prepare. Got it. -->Andy > >> Note that filelayout_reset_read and filelayout_reset_write set the data->ds_clp to NULL which makes the call to nfs41_setup_sequence() in filelayout_write/read_prepare Oops….. >> >> So, I'll keep this patch as is. > > NACK. Adding a parameter to the sequence arguments is way too ugly a > hack. This has nothing to do with the sequence op. > > -- > 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
