On Mon, Oct 16, 2017 at 02:36:23PM -0400, bfields wrote: > On Mon, Oct 16, 2017 at 01:07:57PM -0400, Olga Kornievskaia wrote: > > Network trace reveals that server is not working properly (thus > > getting Bruce's attention here). > > > > Skipping ahead, the server replies to a SEQUENCE call with a reply > > that has a count=5 operations but only has a sequence in it. > > > > The flow of steps is the following. > > > > Client sends > > call COPY seq=16 slot=0 highslot=1(application at this point receives > > a ctrl-c so it'll go ahead and close 2files it has opened) > > Is cachethis set on that the SEQUENCE op in that copy compound? > > > call CLOSE seq=1 slot=1 highslot=1 > > call SEQUENCE seq=16 slot=0 highslot=1 > > reply CLOSE OK > > reply SEQUENCE ERR_DELAY > > another call CLOSE seq=2 slot=1 and successful reply > > reply COPY .. > > call SEQUENCE seq=16 slot=0 highslot=0 > > reply SEQUENCE opcount=5 > > And that's the whole reply? > > Do you have a binary capture that I could look at? Thanks, yes, the client behavior is arguably out of spec (it's sending a "retry" that doesn't match the original call), but I understand why it's doing this, and clearly responding with a corrupted reply isn't right. (And probably the client can deal with any reply short of one that's actually corrupted.) Do the following patches help? (Actually I think either one on its own should do the job, but I haven't done much testing.) --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
