On Jul. 12, 2010, 22:14 +0300, Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> wrote: > On Mon, 2010-07-12 at 21:58 +0300, Benny Halevy wrote: >> [pnfs@xxxxxxxxxxxxx -> linux-nfs@xxxxxxxxxxxxxxx] >> >> On Jul. 12, 2010, 21:29 +0300, Jim Rees <rees@xxxxxxxxx> wrote: >>> Does anyone still care about this? >>> >>> WARNING: nfs41_sequence_done: Operation in progress slot=1 seq=7 highest_used_slotid=1: please report to pnfs@xxxxxxxxxxxxx if you saw this message >> >> Heh, need to update hard-coded instructions to point to the new list... >> >>> >>> I'm getting this on the client side of a pnfs block layout mount against the >>> spnfs server. Kernel is benny's pnfs-all-2.6.35-rc3-2010-07-01 plus EMC >>> complex block layout patches. It's possible the complex layout code is to >>> blame, but I doubt it because this isn't a complex layout mount. I can >>> provide more details. >> >> I agree. This is a generic issue. >> The patch that adds this check is >> d6ce9ad DEVONLY: nfs41: Do not free slot if retried while operation was in progress >> >> It was originally rejected (http://www.spinics.net/lists/linux-nfs/msg09562.html) >> due to noise regarding where nfs41_sequence_free_slot is called >> but that masked the real issue. >> >> Can you readily reproduce this? >> Can you debug also the server side to see if indeed the client retries the RPC >> while it is in progress on the server? > > So what is the root cause here? Is it the known issue that we don't deal > correctly with an NFS4ERR_DELAY on the SEQUENCE operation? Yes. > > Trond > -- > 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
