Date: Sat, 5 Mar 2016 19:42:51 +0300 From: Dmitry Sivachenko <trtrmitya@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Eugene Grosbein <eugen@grosbein.net>, FreeBSD Stable ML <stable@freebsd.org> Subject: Re: nfs_getpages: error 4 Message-ID: <415B1CAA-2728-48D0-96F0-C20F02F8A045@gmail.com> In-Reply-To: <20160305162747.GA67250@kib.kiev.ua> References: <A2A32332-4D9D-40DF-9DEC-EE9000879416@gmail.com> <56DACD4E.3070905@grosbein.net> <550ADE4F-9F60-44FB-BF07-A1384A6B7B1A@gmail.com> <56DAE033.9020304@grosbein.net> <ED06D277-F19B-46F4-BD61-08B6AD10326B@gmail.com> <56DAE6D2.5040309@grosbein.net> <9BBCBDD0-4DAD-4189-9AAA-9FD94A458F7E@gmail.com> <20160305162747.GA67250@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 05 Mar 2016, at 19:27, Konstantin Belousov <kostikbel@gmail.com> = wrote: >=20 > On Sat, Mar 05, 2016 at 05:24:26PM +0300, Dmitry Sivachenko wrote: >>>=20 >>> Again, error 4 is EINTR so you could disable both "soft" and "intr" = options for test. >>=20 >>=20 >> "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". >>=20 >> 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. >>=20 >>=20 >=20 > 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. >=20 > You should at last get the > vm_fault: pager read error, pid ... > messages as well. Is this true ? That is true, see my initial post. > The end result would be SIGSEGV > delivered to the process. >=20 > 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 ? >=20 I have no swap configured, but it is possible that running processes eat = all RAM (I expect them to be killed with OOM rather than stuck?)=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?415B1CAA-2728-48D0-96F0-C20F02F8A045>