From: Neil Brown <neilb@suse.de>
To: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: NFSv4 mounts take longer the fail from ENETUNREACH than NFSv3 mounts.
Date: Wed, 20 Oct 2010 18:17:01 +1100 [thread overview]
Message-ID: <20101020181701.232dbeea@notabene> (raw)
If I don't have any network configured (except loop-back), and try an NFSv3
mount, then it fails quickly:
....
mount.nfs: portmap query failed: RPC: Remote system error - Network is unreachable
mount.nfs: Network is unreachable
If I try the same thing with a NFSv4 mount, it times out before it fails,
making a much longer delay.
This is because mount.nfs doesn't do a portmap lookup but just leaves
everything to the kernel.
The kernel does an 'rpc_ping()' which sets RPC_TASK_SOFTCONN.
So at least it doesn't retry after the timeout. But given that we have a
clear error, we shouldn't timeout at all.
Unfortunately I cannot see an easy way to fix this.
The place where ENETUNREACH is in xs_tcp_setup_socket. The comment there
says "Retry with the same socket after a delay". The "delay" bit is correct,
the "retry" isn't.
It would seem that we should just add a 'goto out' there if RPC_TASK_SOFTCONN
was set. However we cannot see the task at this point - in fact it seems
that there could be a queue of tasks waiting on this connection. I guess
some could be soft, and some not. ???
So: An suggestions how to get a ENETUNREACH (or ECONNREFUSED or similar) to
fail immediately when RPC_TASK_SOFTCONN is set ???
This affects people who upgrade from openSUSE11.2 (which didn't support v4
mounts) to openSUSE11.3 (which defaults to v4) and who use network-manager
(which configures networks late) and have NFS mounts in /etc/fstab with
either explicit IP addresses or host names that can be resolved without the
network.
This config will work because when the network comes up, network-manager will
re-run the 'init.d/nfs' script. However since 11.3 there is an unpleasant
pause before boot completes.
Thanks,
NeilBrown
next reply other threads:[~2010-10-20 7:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-20 7:17 Neil Brown [this message]
2010-10-20 14:29 ` NFSv4 mounts take longer the fail from ENETUNREACH than NFSv3 mounts Chuck Lever
2010-10-20 21:29 ` Neil Brown
2010-10-21 0:56 ` Neil Brown
2010-10-21 12:09 ` Jeff Layton
2010-10-21 13:52 ` Chuck Lever
2010-10-21 14:10 ` Chuck Lever
2010-10-20 17:55 ` Jeff Layton
2010-10-20 19:16 ` Jeff Layton
2010-10-20 20:40 ` Neil Brown
2010-10-21 0:45 ` Jeff Layton
2010-10-21 3:25 ` Neil Brown
2010-10-21 14:05 ` Trond Myklebust
2010-10-21 14:31 ` Chuck Lever
2010-10-21 14:42 ` Trond Myklebust
2010-10-21 19:40 ` Jeff Layton
2010-10-21 19:47 ` Trond Myklebust
2010-10-21 20:08 ` Jeff Layton
2010-10-21 20:18 ` Trond Myklebust
2011-03-23 6:41 ` NeilBrown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101020181701.232dbeea@notabene \
--to=neilb@suse.de \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.