[H-GEN] NFS timeout

[Greg Black]

[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]

On 2003-07-04, Jay wrote:
> On Fri, 04 Jul 2003 16:24, David Jericho wrote:
> > NFS doesn't work very well in a clustered environment. It's messy, and
> > can be quite problematic.
> 
> Any particulars to watch out for?

This is covered in millions[1] of articles and hundreds of
books.  You'd be better off to do a bit of general reading to
get some idea of the nature of the beast.  A brief summary is:

    NFS sucks; sometimes, doing without it sucks even more;
    being forced to use it in the kind of environment you have
    described is one good way to become intimate with some of
    the suckage.

> The background simply is that I pre-load many hard drives for deployment in 
> new machines on a target network.
> The pre-loading and testing is done on a different network. The idea then 
> simply is to try to get around this stupidly long NFS timeout.
> [...]
> test network is 10.x.x.x, target network is 192.168.x.x

So surely you know, before the NFS mounts are attempted, which
network you're on?  In that case, it's a simple case[2] of:

    case $IP in
        10.*)
            ;;
	192.*)
            mount $NFS:$DIR $MNT
	    ;;
    esac

Generally, it's unsound to use methods that waste time to find
things out that you can discover more easily.  A ping to an
inaccessible host is still going to take about 10 seconds ...

Greg

[1] I used "millions" in with the meaning "more than 1000000",
    but that could be 65 if you choose the right notation.

[2] The case pun was an accident.

-- 
Greg Black <gjb at gbch.net> <http://www.gbch.net/gjb.html>
GPG signed mail preferred; further information in headers.

--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.  See http://www.humbug.org.au/