On Fri, 7 Mar 2014 08:13:00 -0500 Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> wrote: > > 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… > I would certainly be good if we could delegation the documentation. But I couldn't find anything in signal(7) that seemed particularly relevant. Which bit were you thinking of? Thanks, NeilBrown
Attachment:
signature.asc
Description: PGP signature
