]> git.baikalelectronics.ru Git - kernel.git/commit
NFS: Retry mounting NFSROOT
authorChuck Lever <chuck.lever@oracle.com>
Mon, 5 Dec 2011 20:40:30 +0000 (15:40 -0500)
committerTrond Myklebust <Trond.Myklebust@netapp.com>
Thu, 5 Jan 2012 15:42:39 +0000 (10:42 -0500)
commitde699d60d96cac71bc9faf78b1ad27a166027eec
tree0c3465ca158dc0d582a8645edfb6d16377afdf5f
parent3e3b3c0dbdf2102034d1fba72424f1570f6bb19a
NFS: Retry mounting NFSROOT

Lukas Razik <linux@razik.name> reports that on his SPARC system,
booting with an NFS root file system stopped working after commit
be5bb929 "NFS: Use super.c for NFSROOT mount option parsing."

We found that the network switch to which Lukas' client was attached
was delaying access to the LAN after the client's NIC driver reported
that its link was up.  The delay was longer than the timeouts used in
the NFS client during mounting.

NFSROOT worked for Lukas before commit be5bb929 because in those
kernels, the client's first operation was an rpcbind request to
determine which port the NFS server was listening on.  When that
request failed after a long timeout, the client simply selected the
default NFS port (2049).  By that time the switch was allowing access
to the LAN, and the mount succeeded.

Neither of these client behaviors is desirable, so reverting be5bb929
is really not a choice.  Instead, introduce a mechanism that retries
the NFSROOT mount request several times.  This is the same tactic that
normal user space NFS mounts employ to overcome server and network
delays.

Signed-off-by: Lukas Razik <linux@razik.name>
[ cel: match kernel coding style, add proper patch description ]
[ cel: add exponential back-off ]
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Tested-by: Lukas Razik <linux@razik.name>
Cc: stable@kernel.org # > 2.6.38
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
init/do_mounts.c