On Feb 24, 2011, at 5:36 AM, Shiraz Hashim wrote:

On Thu, Feb 10, 2011 at 05:26:16AM +0800, Chuck Lever wrote:

quoted

On Feb 9, 2011, at 3:58 PM, Brian Downing wrote:

quoted

On Wed, Feb 09, 2011 at 03:12:22PM -0500, Chuck Lever wrote:

quoted

Based on your console logs, I see that the working case uses UDP to
contact the server's mountd, but the failing case uses TCP.  You can
try explicitly specifying "proto=udp" to force the use of UDP, to test
this theory.

This does indeed make it work again for me, thanks!

quoted

Meanwhile, the patch description explicitly states that the default
mount option settings have changed.  Does it make sense to change the
default behavior of NFSROOT mounts to use UDP again?  I don't see
another way to make this process more reliable across NIC
initialization.  If this is considered a regression, we can make a
patch for 2.6.38-rc and 2.6.37.

I only use nfsroot for development, so I don't have a terribly strong
opinion.  I would point out though that the default u-boot parameters
for nfsrooting a lot of boards will no longer work at this point, so if
it's not patched to work again without specifying nfs options I think
there should at least be a note in the documentation and possibly a
"maybe try proto=udp?" console message on failure.

I assume it's not feasable to either wait until the chosen interface's
link is ready before trying to mount nfsroot, or retrying TCP-based
connections a little bit more aggressively/at all?

Our goal is to use the same mount logic for both normal user
space mounts and for NFSROOT (that was the purpose of the patch
series this particular patch comes from).  It's
exceptionally difficult to add a special case for retrying TCP
connections here, as that would change the behavior of user
space mounts, which often want to fail quickly, and don't need
to worry about NIC initialization.

Sounds like the right thing to do is restore the default UDP behavior.  I'll cook up a patch.

Is there some patch available for this now.

Yes, it was posted a couple of weeks ago (sorry, I don't have an exact reference).  I will ping Trond again about getting this upstream.

There is one more observation (on 2.6.37), when I pass
nfsroot=$(ip):$(rootpath),udp , then it works fine.
If I pass proto=udp then it doesn't work. Is there any difference
between the two methods ?

It may be that proto=udp has an effect only on the transport used for NFS requests, but not for the MNT request.  "udp" means "proto=udp,mountproto=udp."

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com



--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html