Date: Sun, 1 Sep 2013 21:16:31 +0300 From: Mikolaj Golub <trociny@FreeBSD.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: FreeBSD FS <freebsd-fs@freebsd.org> Subject: Re: NFS on ZFS pure SSD pool Message-ID: <20130901181630.GB15654@gmail.com> In-Reply-To: <258054624.15907722.1377905324980.JavaMail.root@uoguelph.ca> References: <CAOFF%2BZ2C26V3Ktuvj5RFwGN%2BH657OPXm796TqA54xOpQj1TVFg@mail.gmail.com> <258054624.15907722.1377905324980.JavaMail.root@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 30, 2013 at 07:28:44PM -0400, Rick Macklem wrote: > Sam Fourman Jr. wrote: > > $ cat /var/log/messages | grep failed > > Aug 30 10:22:20 students nfsd[1978]: accept failed: Software caused > > connection abort > > Aug 30 10:27:16 students nfsd[1978]: accept failed: Software caused > > connection abort > > Aug 30 11:46:30 students nfsd[1978]: accept failed: Software caused > > connection abort > > Aug 30 11:47:10 students nfsd[1978]: accept failed: Software caused > > connection abort > > > Since the master socket that is accepting connections isn't being closed, > I believe this error (ECONNABORTED returned by accept()) occurs when the > client closes the new TCP connection before it has been accepted. Why > would an NFS client do this? I have no idea. May be because nfsd is too slow accepting new connections and the client aborts due to its timeout? May nfssvc(2) block for some considerable time? Sam, you could monitor nfsd listen queue running netstat -nL periodically and current client connections to nfsd with netstat -na, to see what is going on. Also enabling ktrace on the nfsd process when the issue is observed could tell if it is due to nfssvc(2) is slow. BTW, I noticed that nfsd sets listen backlog to 5. Isn't it a bit low for servers that might have hundreds clients? -- Mikolaj Golub
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130901181630.GB15654>