On Thu, 2019-01-24 at 11:17 -0800, Chuck Lever wrote: > > On Jan 24, 2019, at 4:29 AM, zhangxiaoxu (A) < > > zhangxiaoxu5@xxxxxxxxxx> wrote: > > > > > > > > On 1/19/2019 4:59 AM, Chuck Lever wrote: > > > > On Jan 17, 2019, at 9:48 PM, zhangxiaoxu (A) < > > > > zhangxiaoxu5@xxxxxxxxxx> wrote: > > > > > > > > > > > > > > > > On 1/17/2019 10:33 PM, Chuck Lever wrote: > > > > > Hi, what is the harm of sending more than one MON request for > > > > > a peer? > > > > Maybe no harm. > > > > The rpc.statd won't record the peer twice. > > > > > > > > I found this when I tested the xfstest generic/089. > > > > The rpc task for that msg sometimes take very long time. > > > > rpc took 57 sec who t_mtab/2377 srv rpc.statd xid 2453489031 > > > > prog statd/100024/1 proc 2 prot 6 flags 0x680 > > > MON is supposed to be a call to a local service (on the same > > > host). > > > It would be interesting if you could determine why it takes so > > > long. > > Yes, I'm working for that. > > I think this is an optimization point. > > Why do we have to send multiple requests? > > I agree that multiple requests are unnecessary, but > they are harmless too. I don't think it's worth the > trouble to change this behavior. > > The problem is MON requests on your system takes too long. 57 seconds is pretty much unheard of. Is rpc.statd correctly registered with rpcbind, and is the port that rpc.statd is listening on open to connections from localhost (i.e. no firewall blockage)? -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
