On Wed, Apr 29, 2015 at 11:24:02AM -0400, Trond Myklebust wrote: > On Wed, Apr 29, 2015 at 11:14 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Wed, Apr 29, 2015 at 10:55:10AM -0400, Chuck Lever wrote: > >> > >> On Apr 28, 2015, at 4:21 PM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > >> > >> > Currently the client will just crap out if a CB_NULL comes in at the > >> > same time as a slot controlled CB_COMPOUND that includes a CB_SEQUENCE. > >> > >> Under what circumstances does the server send a CB_NULL while a CB_COMPOUND > >> is in flight? > > > > When a client is under heavy loads from fsx or aio-stress, and we lose > > the connection (nfsd4_conn_lost is called) while doing heavy recalls. > > > > xfstests against a server offering pnfs layouts for which the client > > can't reach the storage devices is an easy reproducer. > > Why does it need to do this? If the client has sent the > BIND_CONN_TO_SESSION (which I believe that knfsd asks for), then the > server knows that this is a bi-directional connection. > The difference between NFSv4 and NFSv4.1 is that the CB_NULL should > almost always be redundant, because the client initiates the > connection and it explicitly tells the server whether or not it is to > be used for the callback channel. > > The CB_NULL should always be redundant. I'd be fine with suppressing it. I think I actually intended to but screwed it up. (Chuck or somebody convinced me the NFSD4_CB_UP/UNKNOWN/DOWN logic is totally broken but I never got around to fixing it.) --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
