On Fri, Aug 14, 2020 at 04:21:54PM -0400, Chuck Lever wrote: > > > > On Aug 14, 2020, at 3:10 PM, Dan Aloni <dan@xxxxxxxxxxxx> wrote: > > > > On Fri, Aug 14, 2020 at 02:12:48PM -0400, Chuck Lever wrote: > >> Hi Dan- > >> > >>> On Aug 14, 2020, at 1:37 PM, Dan Aloni <dan@xxxxxxxxxxxx> wrote: > >>> > >>> It was observed that on disconnections, these unmaps don't occur. The > >>> relevant path is rpcrdma_mrs_destroy(), being called from > >>> rpcrdma_xprt_disconnect(). > >> > >> MRs are supposed to be unmapped right after they are used, so > >> during disconnect they should all be unmapped already. How often > >> do you see a DMA mapped MR in this code path? Do you have a > >> reproducer I can try? > > > > These are not graceful disconnections but abnormal ones, where many large > > IOs are still in flight, while the remote server suddenly breaks the > > connection, the remote IP is still reachable but refusing to accept new > > connections only for a few seconds. > > Ideally that's not supposed to matter. I'll see if I can reproduce > with my usual tricks. > > Why is your server behaving this way? It's a dedicated storage cluster under a specific testing scenario, implementing floating IPs. Haven't tried, but maybe the same scenario can be reproduced with a standard single Linux NFSv3 server by fiddling with nfsd open ports. -- Dan Aloni