On Wed, Dec 04, 2013 at 04:22:48PM -0500, Trond Myklebust wrote: > > On Dec 4, 2013, at 16:03, Dr Fields James Bruce <bfields@xxxxxxxxxxxx> wrote: > > > On Wed, Dec 04, 2013 at 10:44:45PM +0200, Antti Tönkyrä wrote: > > > >>>> http://daedalus.pingtimeout.net/dbg/eilseq_ioerr.pcap > > > > And I see something I'd overlooked before: the client is sending the > > later opens with the same open owner and sequence id. But NFS4ERR_IO is > > a seqid-mutating error. So now I think this probably *is* a client > > bug.... > > Umm… Yes and no. The client should be able to recover when it discovers that the seqid is out of sync. > > That said, I see that we do > > status = decode_op_hdr(xdr, OP_OPEN); > if (status != -EIO) > nfs_increment_open_seqid(status, res->seqid); > > and since NFS4ERR_IO == EIO, that means we skip the seqid update when you send us NFS4ERR_IO. Oh, OK. Maybe decode_op_hdr could use -NFS4ERR_BADXDR for the two decoding errors it catches and eliminate the need for this special -EIO case? I think NFS4ERR_IO is a legal error for these operations. (Even if the server should have returned something else in this case.) --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
