On Thu, Sep 26, 2019 at 08:55:17AM -0700, Chuck Lever wrote: > > On Sep 25, 2019, at 1:07 PM, Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > > > On Wed, Sep 25, 2019 at 11:49:14AM -0700, Chuck Lever wrote: > >> Sounds like the NFS server is dropping the connection. With > >> GSS enabled, that's usually a sign that the GSS window has > >> overflowed. > > > > Would that show up in the rpc statistics on the client somehow? > > More likely on the server. The client just sees a disconnect > without any explanation attached. So watching a count of disconnects might at least tell us something? > gss_verify_header is where the checking is done on the server. > Disappointingly, I see some dprintk's in there, but no static > trace events. Kevin, was this a Linux server? --b. > > In that case--I seem to remember there's a way to configure the size of > > the client's slot table, maybe lowering that (decreasing the number of > > rpc's allowed to be outstanding at a time) would work around the > > problem. > > > Should the client be doing something different to avoid or recover from > > overflows of the gss window? > > The client attempts to meter the request stream so that it stays > within the bounds of the GSS sequence number window. The stream > of requests is typically unordered coming out of the transmit > queue. > > There is some new code (since maybe v5.0?) that handles the > metering: gss_xmit_need_reencode().
