Re: User process NFS write hang in wait_on_commit with kworker

[Alan Post <adp@prgmr.com>]

On Tue, Jul 02, 2019 at 05:55:10AM -0400, Benjamin Coddington wrote:
> > As far as I understand it, for a particular xid, there should be a
> > call and a reply.  The approach I took then was to pull out these
> > fields from my capture and ignore RPC calls where both are present
> > in my capture.  It seems this is simplistic, as the number of RPC
> > calls I have without an attendant reply isn't lining up with my
> > incident window.
> 
> Does your capture report dropped packets?  If so, maybe you need to increase
> the capture buffer.
> 

I'm not certain, but I do have a capture on both the NFS server and
the NFS client--comparing them would show me if I was under most
circumstances.  Good catch.

> > In one example, I have a series of READ calls which cease
> > generating RPC reply messages as the offset for the file continues
> > to increases.  After a couple/few dozen messages, the RPC replies
> > continue as they were.  Is there a normal or routine explanation
> > for this?
> >
> > RFC 5531 and the NetworkTracing page on wiki.linux-nfs.org have
> > been quite helpful bringing me up to speed.  If any of you have
> > advice or guidance or can clarify my understanding of how the
> > call/reply RPC mechanism works I appreciate it.
> 
> Seems like you understand it.  Do you have specific questions?
> 

Is it true that for each RPC call there is an RPC reply with the
same xid?  Is it a-priori an error if an otherwise correct RPC
call is not eventually paired with an RPC reply?

Thank you,

-A
-- 
Alan Post | Xen VPS hosting for the technically adept
PO Box 61688 | Sunnyvale, CA 94088-1681 | https://prgmr.com/
email: adp@prgmr.com