> On Jan 25, 2017, at 2:58 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > >> >> On Jan 24, 2017, at 3:23 PM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: >> >> On Tue, 2017-01-24 at 14:15 -0500, J. Bruce Fields wrote: >>> On Tue, Jan 24, 2017 at 02:06:16PM -0500, Chuck Lever wrote: >>>> >>>>> On Jan 23, 2017, at 11:49 AM, bfields@xxxxxxxxxxxx wrote: >>>>> >>>>> On Mon, Jan 23, 2017 at 10:01:27AM -0500, Chuck Lever wrote: >>>>>> >>>>>>> On Jan 22, 2017, at 2:04 PM, Chuck Lever <chuck.lever@oracle. >>>>>>> com> wrote: >>>>>>> >>>>>>> Xuan Qi reports that the Linux NFSv4 client failed to lock a >>>>>>> file >>>>>>> that was migrated. The steps he observed on the wire: >>>>>>> >>>>>>> 1. The client sent a LOCK request >>>>>>> 2. The server replied NFS4ERR_MOVED >>>>>>> 3. The client switched to the destination server >>>>>>> 4. The client sent the LOCK request again with a bumped >>>>>>> ย lock sequence ID >>>>>>> 5. The server rejected the LOCK request with >>>>>>> NFS4ERR_BAD_SEQID >>>>>> >>>>>> The list of steps could be more clear: >>>>>> >>>>>> 1. The client sent a LOCK request to the source server >>>>>> 2. The source server replied NFS4ERR_MOVED >>>>>> 3. The client switched to the destination server >>>>>> 4. The client sent the same LOCK request to the destination >>>>>> ย server with a bumped lock sequence ID >>>>>> 5. The destination server rejected the LOCK request with >>>>>> ย NFS4ERR_BAD_SEQID >>>>>> >>>>>> >>>>>>> RFC 3530 section 8.1.5 provides a list of NFS errors which do >>>>>>> not >>>>>>> bump a lock sequence ID. >>>>>>> >>>>>>> However, RFC 3530 is now obsoleted by RFC 7530. In RFC 7530 >>>>>>> section >>>>>>> 9.1.7, this list has been updated by the addition of >>>>>>> NFS4ERR_MOVED. >>>>> >>>>> I guess we figured the backwards-incompatible change was OK since >>>>> essentially the Solaris server is the first we know of to be >>>>> making real >>>>> use of NFS4ERR_MOVED? >>>>> >>>>> And probably it's required for the their implementation because >>>>> the old >>>>> server no longer has the ability to update the state once it's >>>>> reached >>>>> the point of returning ERR_MOVED. >>>>> >>>>> OK, makes sense to me, I think. >>>> >>>> Hi Bruce- >>>> >>>> Does this mean you will take this patch, or should >>>> I just add your Reviewed-by: ? >>> >>> I can take it if nobody objects.ย ย Mind if I append the above to the >>> changelog?ย ย (Just want to document why we think the apparently >>> backwards-incompatible change is OK.) >>> >> I've already added it to my linux-next branch as a stable patch. > > This patch alone might not be enough. > > Our test results show that even with this patch applied, the Linux > client still increments the lock sequence ID after NFS4ERR_MOVED. Looks like nfs_increment_seqid() also needs to be updated? -- Chuck Lever -- 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
