2014-03-06 22:03:13

by Jim Rees

[permalink] [raw]
Subject: [PATCH] fix intr/nointr to match kernel behavior (ignored)

Signed-off-by: Jim Rees <[email protected]>
---
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.
+.TP 1.5i
.BI timeo= n
The time in deciseconds (tenths of a second) the NFS client waits for a
response before it retries an NFS request.
@@ -668,30 +674,6 @@ Using the
option is also required when mounting exports on NFS servers
that do not support the NLM protocol.
.TP 1.5i
-.BR intr " / " nointr
-Selects whether to allow signals to interrupt file operations
-on this mount point. If neither option
-is specified (or if
-.B nointr
-is specified),
-signals do not interrupt NFS file operations. If
-.B intr
-is specified, system calls return EINTR if an in-progress NFS operation is interrupted by
-a signal.
-.IP
-Using the
-.B intr
-option is preferred to using the
-.B soft
-option because it is significantly less likely to result in data corruption.
-.IP
-The
-.BR intr " / " nointr
-mount option is deprecated after kernel 2.6.25.
-Only SIGKILL can interrupt a pending NFS operation on these kernels,
-and if specified, this mount option is ignored to provide backwards
-compatibility with older kernels.
-.TP 1.5i
.BR cto " / " nocto
Selects whether to use close-to-open cache coherence semantics.
If neither option is specified (or if
@@ -807,29 +789,6 @@ The mount request fails if the server's rpcbind service is not available,
the server's NFS service is not registered with its rpcbind service,
or the server's NFS service is not available on the advertised port.
.TP 1.5i
-.BR intr " / " nointr
-Selects whether to allow signals to interrupt file operations
-on this mount point. If neither option is specified (or if
-.B intr
-is specified), system calls return EINTR if an in-progress NFS operation
-is interrupted by a signal. If
-.B nointr
-is specified, signals do not
-interrupt NFS operations.
-.IP
-Using the
-.B intr
-option is preferred to using the
-.B soft
-option because it is significantly less likely to result in data corruption.
-.IP
-The
-.BR intr " / " nointr
-mount option is deprecated after kernel 2.6.25.
-Only SIGKILL can interrupt a pending NFS operation on these kernels,
-and if specified, this mount option is ignored to provide backwards
-compatibility with older kernels.
-.TP 1.5i
.BR cto " / " nocto
Selects whether to use close-to-open cache coherence semantics
for NFS directories on this mount point.
--
1.9.0



2014-03-07 23:57:08

by Trond Myklebust

[permalink] [raw]
Subject: Re: [PATCH] fix intr/nointr to match kernel behavior (ignored)


On Mar 7, 2014, at 18:42, NeilBrown <[email protected]> wrote:

> On Fri, 7 Mar 2014 08:13:00 -0500 Trond Myklebust
> <[email protected]> wrote:
>
>>
>> On Mar 7, 2014, at 2:59, NeilBrown <[email protected]> wrote:
>>
>>> On Thu, 6 Mar 2014 17:02:32 -0500 Jim Rees <[email protected]> wrote:
>>>
>>>> Signed-off-by: Jim Rees <[email protected]>
>>>> ---
>>>> 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?
>

The table which lists the posix signals, and which indicates whether they are fatal not (i.e. what ?action? they cause).
The same page also explains signal blocking and signal handling, which could also be helpful..

_________________________________
Trond Myklebust
Linux NFS client maintainer, PrimaryData
[email protected]


2014-03-07 23:42:38

by NeilBrown

[permalink] [raw]
Subject: Re: [PATCH] fix intr/nointr to match kernel behavior (ignored)

On Fri, 7 Mar 2014 08:13:00 -0500 Trond Myklebust
<[email protected]> wrote:

>
> On Mar 7, 2014, at 2:59, NeilBrown <[email protected]> wrote:
>
> > On Thu, 6 Mar 2014 17:02:32 -0500 Jim Rees <[email protected]> wrote:
> >
> >> Signed-off-by: Jim Rees <[email protected]>
> >> ---
> >> 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


Attachments:
signature.asc (828.00 B)

2014-03-08 01:39:18

by Jim Rees

[permalink] [raw]
Subject: Re: [PATCH] fix intr/nointr to match kernel behavior (ignored)

Trond Myklebust wrote:

> 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?
>

The table which lists the posix signals, and which indicates whether they
are fatal not (i.e. what ‘action’ they cause). The same page also
explains signal blocking and signal handling, which could also be
helpful..

This seems the relevant part to me, assuming nfs system calls are considered
"slow":

* read(2), readv(2), write(2), writev(2), and ioctl(2) calls on
"slow" devices. A "slow" device is one where the I/O call may
block for an indefinite time, for example, a terminal, pipe, or
socket. (A disk is not a slow device according to this defini‐
tion.) If an I/O call on a slow device has already transferred
some data by the time it is interrupted by a signal handler, then
the call will return a success status (normally, the number of
bytes transferred).

Here's Neil's description:

>>> "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".

So assuming nfs system calls honor the SA_RESTART flag, I think these
behaviors are the same?

2014-03-07 13:13:04

by Trond Myklebust

[permalink] [raw]
Subject: Re: [PATCH] fix intr/nointr to match kernel behavior (ignored)


On Mar 7, 2014, at 2:59, NeilBrown <[email protected]> wrote:

> On Thu, 6 Mar 2014 17:02:32 -0500 Jim Rees <[email protected]> wrote:
>
>> Signed-off-by: Jim Rees <[email protected]>
>> ---
>> 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
[email protected]


2014-03-07 07:59:45

by NeilBrown

[permalink] [raw]
Subject: Re: [PATCH] fix intr/nointr to match kernel behavior (ignored)

On Thu, 6 Mar 2014 17:02:32 -0500 Jim Rees <[email protected]> wrote:

> Signed-off-by: Jim Rees <[email protected]>
> ---
> 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.

NeilBrown


> +.TP 1.5i
> .BI timeo= n
> The time in deciseconds (tenths of a second) the NFS client waits for a
> response before it retries an NFS request.
> @@ -668,30 +674,6 @@ Using the
> option is also required when mounting exports on NFS servers
> that do not support the NLM protocol.
> .TP 1.5i
> -.BR intr " / " nointr
> -Selects whether to allow signals to interrupt file operations
> -on this mount point. If neither option
> -is specified (or if
> -.B nointr
> -is specified),
> -signals do not interrupt NFS file operations. If
> -.B intr
> -is specified, system calls return EINTR if an in-progress NFS operation is interrupted by
> -a signal.
> -.IP
> -Using the
> -.B intr
> -option is preferred to using the
> -.B soft
> -option because it is significantly less likely to result in data corruption.
> -.IP
> -The
> -.BR intr " / " nointr
> -mount option is deprecated after kernel 2.6.25.
> -Only SIGKILL can interrupt a pending NFS operation on these kernels,
> -and if specified, this mount option is ignored to provide backwards
> -compatibility with older kernels.
> -.TP 1.5i
> .BR cto " / " nocto
> Selects whether to use close-to-open cache coherence semantics.
> If neither option is specified (or if
> @@ -807,29 +789,6 @@ The mount request fails if the server's rpcbind service is not available,
> the server's NFS service is not registered with its rpcbind service,
> or the server's NFS service is not available on the advertised port.
> .TP 1.5i
> -.BR intr " / " nointr
> -Selects whether to allow signals to interrupt file operations
> -on this mount point. If neither option is specified (or if
> -.B intr
> -is specified), system calls return EINTR if an in-progress NFS operation
> -is interrupted by a signal. If
> -.B nointr
> -is specified, signals do not
> -interrupt NFS operations.
> -.IP
> -Using the
> -.B intr
> -option is preferred to using the
> -.B soft
> -option because it is significantly less likely to result in data corruption.
> -.IP
> -The
> -.BR intr " / " nointr
> -mount option is deprecated after kernel 2.6.25.
> -Only SIGKILL can interrupt a pending NFS operation on these kernels,
> -and if specified, this mount option is ignored to provide backwards
> -compatibility with older kernels.
> -.TP 1.5i
> .BR cto " / " nocto
> Selects whether to use close-to-open cache coherence semantics
> for NFS directories on this mount point.


Attachments:
signature.asc (828.00 B)