[Followup-To: comp.unix.shell]

In article <poBhP.1243903$bYV2.919023@fx17.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>Rainer Weikusat <rweikusat@talktalk.net> writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>> [snip]
>>> There are cases where it _does_ cause performance degradation, if one or
>>> more of the PATH elements refer to NFS filesystems, for example.
>>
>>The internet RTT from Reading/ UK to Dallas/ Texas is about
>>0.12s. That's fast enough that there's no noticeable latency in
>>interactive shell sessions. I doubt that many real-world NFS
>>installations span ⅕ of the planet and hence, the latencies certainly
>>ought to be a lot lower.
>>
>
>You seem to have have forgotten that the NFS server needs to
>do a directory lookup on the file server, which adds to the R/T
>latency, sometimes significantly on a busy filesystem. Add
>two or three NFS-based directories in the PATH variable and it
>starts to become noticable. Even on a 100Gb/sec ethernet
>LAN.
>
>>
>>I'm growing a bit allergic to NFS as universal example of deviant
>>behaviour --- that's a problem of NFS and not of code innocently and
>>unknowingly making use of it.
>
>It is something that people run into every day in the real world.

Remember wuarchive? They used to used to provide access to the
collection via (read-only) NFS. When I was young, someone at
our site had added that to the automounter maps.

There was a local sysadmin who was, er, not exactly highly
regarded. At one point another sysadmin logged into a machine
and saw that the load was really, really high; this would have
been a Sun 4/380 class computer and load was like 3 or 4, all
uninterruptable kernel reads. Anyway, it turns out the first
guy had added some directory in the automounted wuarchive tree
to his $PATH. And that's the sort of thing one does to become
"poorly regarded by colleagues."

- Dan C.