Is there a "proper" way to put in a pause after network initialization to make sure the network *really* is up? I've had this issue for a while with e1000 cards (even on 100MB networks), where the first NFS mount will fail b/c the network reports up but isn't, really. Now, I'm also seeing the same issue on cluster nodes hooked to a switch with jumbo frames enabled.
I used to hack it with a 'sleep 60' at the end of the "start" function in /etc/init.d/network, but that goes away whenever initscripts gets updated. My new hack is to put 'mount -a -t nfs' in /etc/rc.local. Any other suggestions?
On Thu, 13 Apr 2006, Joshua Baker-LePain wrote:
Is there a "proper" way to put in a pause after network initialization to make sure the network *really* is up? I've had this issue for a while with e1000 cards (even on 100MB networks), where the first NFS mount will fail b/c the network reports up but isn't, really. Now, I'm also seeing the same issue on cluster nodes hooked to a switch with jumbo frames enabled.
I used to hack it with a 'sleep 60' at the end of the "start" function in /etc/init.d/network, but that goes away whenever initscripts gets updated. My new hack is to put 'mount -a -t nfs' in /etc/rc.local. Any other suggestions?
If NFS is the only issue, have you considered using the 'bg' mount option? The nfs(5) man page discusses it:
bg If the first NFS mount attempt times out, retry the mount in the background. After a mount operation is backgrounded, all subsequent mounts on the same NFS server will be backgrounded immediately, without first attempting the mount. A missing mount point is treated as a timeout, to allow for nested NFS mounts.
It's not the default behavior, so you have to specify it in /etc/fstab, e.g.,
server:/export /mnt/point nfs bg,hard,intr 0 0
-- Paul Heinlein <> heinlein@madboa.com <> www.madboa.com
On Thu, 13 Apr 2006 at 11:56am, Paul Heinlein wrote
If NFS is the only issue, have you considered using the 'bg' mount option? The nfs(5) man page discusses it:
That seems to do the trick. I was a bit worried that the failure would just migrate to the next network service (ypbind on the cluster nodes), but the delay waiting for the initial try at the NFS mount to fail seems to be long enough.
Thanks!
Paul Heinlein said:
On Thu, 13 Apr 2006, Joshua Baker-LePain wrote:
Is there a "proper" way to put in a pause after network initialization to make sure the network *really* is up? I've had this issue for a while with e1000 cards (even on 100MB networks), where the first NFS mount will fail b/c the network reports up but isn't, really. Now, I'm also seeing the same issue on cluster nodes hooked to a switch with jumbo frames enabled.
If NFS is the only issue, have you considered using the 'bg' mount option? The nfs(5) man page discusses it:
Good idea if you can survive with the temporary unavailability of the mount.
Just a thought as well... you running a Cisco switch? Some switches including Cisco are kinda slow to pass traffic after the link initializes (spanning tree recalculation). You might consider, if appropriate, enabling fast port switching on that switch port. -Alan
=========== Alan Sparks, UNIX/Linux Systems Administrator asparks@doublesparks.net
On Thu, 13 Apr 2006 at 1:15pm, Alan Sparks wrote
Paul Heinlein said:
On Thu, 13 Apr 2006, Joshua Baker-LePain wrote:
Is there a "proper" way to put in a pause after network initialization to make sure the network *really* is up? I've had this issue for a while with e1000 cards (even on 100MB networks), where the first NFS mount will fail b/c the network reports up but isn't, really. Now, I'm also seeing the same issue on cluster nodes hooked to a switch with jumbo frames enabled.
If NFS is the only issue, have you considered using the 'bg' mount option? The nfs(5) man page discusses it:
Good idea if you can survive with the temporary unavailability of the mount.
I can, especially since the mounts are still up before the system is done booting.
Just a thought as well... you running a Cisco switch? Some switches including Cisco are kinda slow to pass traffic after the link initializes (spanning tree recalculation). You might consider, if appropriate, enabling fast port switching on that switch port.
It's a SMC, but I'll have a look at the settings. Thanks.
-
Alan Sparks -
Joshua Baker-LePain -
Paul Heinlein