On Fri, Sep 23, 2016 at 2:34 PM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > >> On Sep 23, 2016, at 14:25, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: >> >> On Fri, Sep 23, 2016 at 2:08 PM, Trond Myklebust >> <trondmy@xxxxxxxxxxxxxxx> wrote: >>> >>>> On Sep 23, 2016, at 13:59, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: >>>> >>>> On Fri, Sep 23, 2016 at 1:45 PM, Trond Myklebust >>>> <trondmy@xxxxxxxxxxxxxxx> wrote: >>>>> >>>>>> On Sep 23, 2016, at 13:40, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: >>>>>> >>>>>> If we instead bump the sequence number in the case of interrupted and do: >>>>> >>>>> You have no guarantees that the server has seen and processed the operation. >>>> >>>> That is correct, i have tested the patch and made server never to >>>> receive the operation and client have an interrupted slot. On the next >>>> operation the server will complain back with SEQ_MISORDERED. Client >>>> can recover from this operation. Client can not recover from "Remote >>>> EIO”. >>>> >>> >>> Why not? >> >> When XDR layer returns EREMOTEIO it's not handled by the NFS error >> recovery (are you suggesting we should?) and returns that to the >> application. >> > > I’m saying that if we get a SEQ_MISORDERED due to a previous interrupt on that slot, then we should ignore the error in task->tk_status, and just retry after bumping the slot seqid. > I'm confused where your objection lies. Are you ok with bumping the sequence # when task->tk_status = 1 and saying that we should still keep the code that I deleted in the 2nd chunk of the patch that bumped the seqid on getting SEQ_MISORDERED due to a previously interrupted slot? Wouldn't that create a difference of 2 slots for the server that has received the original request? -- 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
