freebsd stable - Mar 2016 - nfs_getpages: error 4

> On 05 Mar 2016, at 17:01, Eugene Grosbein <eugen at grosbein.net>
wrote:
> 
> 05.03.2016 20:42, Dmitry Sivachenko ?????:
> 
>>> and to discover what version is broken. And show full mount
command/option set.
>> I already included mount flags from fstab in my original e-mail:
>> 
>> rw,bg,intr,soft
> 
> If that's only options you use, there is another workaround: add
options
> rsize=1024,wsize=1024 to avoid possible packet reassemply/defragmentation
> related bugs.
I wonder how rsize=wsize=1024 will affect performance?  I have 10GBit network
and I expect to achieve comparable throughput.

> 
> Again, error 4 is EINTR so you could disable both "soft" and
"intr" options for test.

"soft" is meaningless in such setup, because "file system calls
will fail after retrycnt round trip timeout intervals" but "The
default is a retry count of zero, which means to keep retrying forever".

If I understand "intr" correctly, it matters only when server becomes
unresponsive, that is "server is not responding" message should be in
my logs.  But I have no such a message.

> Anyway, re-read mount_nfs(8) manual page, section BUGS before switch to
NFSv4.
That is why I chose to use NFSv3, I thought it is more mature and stable
implementation.

On Sat, Mar 05, 2016 at 05:24:26PM +0300, Dmitry Sivachenko
wrote:
> > 
> > Again, error 4 is EINTR so you could disable both "soft" and
"intr" options for test.
> 
> 
> "soft" is meaningless in such setup, because "file system
calls will fail after retrycnt round trip timeout intervals" but "The
default is a retry count of zero, which means to keep retrying forever".
> 
> If I understand "intr" correctly, it matters only when server
becomes unresponsive, that is "server is not responding" message
should be in my logs.  But I have no such a message.
> 
> 
The intr NFS mount option allows signals to interrupt NFS waits for the
RPC responses.  This is almost certainly the reason for the EINTR error
you get from the pager.

You should at last get the
vm_fault: pager read error, pid ...
messages as well.  Is this true ?  The end result would be SIGSEGV
delivered to the process.

OTOH, I do not quite understand why did your threads requesting page-in
fall into the wait for a free page.  I assume that there is enough free
pages in the system ?