Re: [BUG?] Maybe NFS bug since 2.6.37 on SPARC64

[Jim Rees <rees@umich.edu>]

Lukas Razik wrote:

  I've connected the systems directly (without a switch between them).
  It seems that the problem came from the switch because now the newer kernels also mount their NFSROOTs during start up without problems.
  
  Assuming that the ports of the switch really run in STP mode - two questions:
  1. Is it unusual that the ports of a switch where computers are connected to run in STP mode?
  2. If that's not unusual: Wouldn't it be useful if the new linux kernels could mount an NFSROOT even when the system is plugged into an STP port?

STP ports are normally won't start forwarding packets until they have
decided there are no loops.  The usual way to configure a data center switch
is to leave the trunks in this configuration, and set portfast on the ports
that have end systems (like your server) on them.  I think "portfast" is the
Cisco term for this, other vendors might call it something else.  Portfast
ports are still running stp, they just start out in forwarding mode and only
switch to learning mode if they detect a problem.

The question for us is how long should an nfsroot client wait for the server
to reply.  It sounds like the client used to wait longer than it does now.
It seems to me the client should wait at least 90 seconds so that the
situation you're in (servers on non-portfast ports) will work.  I would
think they should wait indefinitely, since there's not much else they can
do.