On Fri, Jan 26, 2018 at 4:34 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > If I understand correctly (I may be wrong), once this patch is applied a > COPY may fail that previously worked--because we're switching over to > the asynchronous copy implementation before it's actually complete. I will have to double check this with testing but I think after this patch the asynchronous copy is functional but doesn't comply with the spec (eg., doesn't generate the unique stateid). > Of course, that's fixed by the end of this series. But we try to avoid > that situation, where functionality is temporarily broken in the middle > of a patch series and then fixed later. > > Options might be to squash this patch together with some of the later > patches. Or go ahead and add this code but don't actually enable it > till later. (E.g. arrange that the "if (!copy->cp_synchronous)" case > won't be taken till the last patch. Maybe it already works that way, I > can't tell.) Or maybe there's some slicker way that I don't see right > now. I could do if (!copy->cp_synchronous && 0) and then add a patch that removes 0. > > --b. > -- > 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 -- 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
