On Feb 9, 2011, at 3:58 PM, Brian Downing wrote: > On Wed, Feb 09, 2011 at 03:12:22PM -0500, Chuck Lever wrote: >> 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! > >> 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. -- 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
