On Fri, Feb 02, 2018 at 02:50:01PM -0500, Olga Kornievskaia wrote: > 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. OK. I still don't see the "slick" solution, so let's go with that. --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
