From: Mike Waychison <michael.waychison@sun.com>
Subject: [PATCH 0/2] [RFC] Making mount operation soft + intr
Date: Thu, 9 Dec 2004 16:22:36 -0500
Message-ID: <11026273562@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
To: nfs@lists.sourceforge.net
Sender: nfs-admin@lists.sourceforge.net
Errors-To: nfs-admin@lists.sourceforge.net

While implementing and testing autofsng, I found myself getting frustrated at
NFS mounts that fail and stay hung.

A typical example is to try and mount from a bogus NFS port:

mount -o port=10000 host:/export /mnt

If the default is hard, the kernel will never time out trying to get initial
contact with the server.

If the default is nointr, then there is no way for userspace to kill the mount
process.

Both of these options make sense while the filesystem is mounted, but in the
case where the server will never respond with a live nfs export, can easily
hang processes and leave locked super_block's live in the system (impeding a
reboot).

The solution I am suggesting is to force the initial rpc calls used in setting
up a mount to be soft + intr, regardless of what the real options are.  We can
do this by passing RPC_TASK_SOFT to the rpc_calls for NFS3PROC_FSINFO,
NFS3PROC_GETATTR, NFSPROC_GETATTR and NFSPROC_STATFS.

To force 'intr' regardless of whether clnt->cl_intr is set or not, we use a
similar technique to the recently added RPC_TASK_NOINTR flag used for
transaction integrity.  We introduce RPC_TASK_FORCEINTR, which overrides
RPC_TASK_NOINTR (the latter is dependent on clnt->cl_intr).

AFAICT, making these ops soft+intr is safe because there is no data to be lost
in the event of a cancelled/timed-out operation.

The first patch following this message adds RPC_TASK_FORCEINTR and makes the
rootfh ops use it and RPC_TASK_SOFT.

The second patch adds a parameter to rpc_clnt_sigmask that takes an optional
set of task flags, of which only RPC_TASK_FORCEINTR is inspected for.  This
keeps the mount paths from blocking signals SIGINT and SIGQUIT.

mount(8) still needs to be taught not to block these signals if it doesn't care
whether the mount operation succeeded or not (in the case of it not being a
loop device and mtab isn't being updated).

(I haven't touched the nfsv4 stuff as I haven't yet wrapped my head around that
code.)

Comments?


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs