On Mar 7, 2014, at 2:59, NeilBrown <neilb@xxxxxxx> wrote: > On Thu, 6 Mar 2014 17:02:32 -0500 Jim Rees <rees@xxxxxxxxx> wrote: > >> Signed-off-by: Jim Rees <rees@xxxxxxxxx> >> --- >> utils/mount/nfs.man | 53 ++++++----------------------------------------------- >> 1 file changed, 6 insertions(+), 47 deletions(-) >> >> diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man >> index ef09a31..2ab369c 100644 >> --- a/utils/mount/nfs.man >> +++ b/utils/mount/nfs.man >> @@ -125,6 +125,12 @@ option may mitigate some of the risks of using the >> .B soft >> option. >> .TP 1.5i >> +.BR intr " / " nointr >> +This option is provided for backward compatibility. >> +It is ignored after kernel 2.6.25. >> +System calls return EINTR if an in-progress NFS operation is interrupted by >> +a signal. > > That isn't correct. > "A process that is waiting for a reply for an NFS server can be killed > by any signal which would normally kill the process. If a signal would not > normally kill the process (i.e. it is caught or ignored) then that signal > will not abort and NFS request". > > This is really a fairly horrible semantic. It makes perfect sense from an > internal implementation perspective and provides good backwards compatibility > and cross-compatibility with other filesystems (where 'read' and 'write' > never ever return EINTR), but it is very hard to document clearly. > Isn’t the documentation in the signal(7) manpage sufficient? We could simply refer to that… _________________________________ Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
