On May 2, 2009, at 4:12 AM, Peter =C5strand wrote:
> On Fri, 1 May 2009, Chuck Lever wrote:
>
>> The "intr" mount option has been deprecated for a while, but
>> /proc/mounts continues to display "nointr" whether "intr" or "nointr=
"
>> has been specified for a mount point.
>>
>> Since these options do not have any effect, simply do not display
>> them.
>
> Does this mean that "intr" is default now? Will the "intr" mount =20
> option
> still be accepted/ignored in the future?
Since 2.6.25, the behavior of the NFS client has been a mix of the =20
two. I believe the current behavior is that SIGKILL can terminate an =20
NFS operation, but all other signals are deferred until pending NFS =20
operations complete.
The mount command continues to accept both options, but neither have =20
any effect on the client's behavior (both options are no-ops).
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Mon, 2009-05-04 at 10:27 -0400, Chuck Lever wrote:
> On May 2, 2009, at 4:12 AM, Peter =C3=85strand wrote:
> > On Fri, 1 May 2009, Chuck Lever wrote:
> >
> >> The "intr" mount option has been deprecated for a while, but
> >> /proc/mounts continues to display "nointr" whether "intr" or "noin=
tr"
> >> has been specified for a mount point.
> >>
> >> Since these options do not have any effect, simply do not display
> >> them.
> >
> > Does this mean that "intr" is default now? Will the "intr" mount =20
> > option
> > still be accepted/ignored in the future?
>=20
> Since 2.6.25, the behavior of the NFS client has been a mix of the =20
> two. I believe the current behavior is that SIGKILL can terminate an=
=20
> NFS operation, but all other signals are deferred until pending NFS =20
> operations complete.
>=20
> The mount command continues to accept both options, but neither have =
=20
> any effect on the client's behavior (both options are no-ops).
Note that this behaviour is true of local filesystems too, since
generic_file_read() has been changed to call lock_page_killable()
instead of the uninterruptible lock_page().
Trond