Alvin writes:
- cross mounting is the worst...
A hard mounts B:/foo
B hard mounts A:/bar
if either machine dies... both is dead ...
-- never, if possible cross mount each other
I'm fairly agnostic on this. Here at Compaq, employees' directories are
on various servers (now clusters). Typically the employee logs into that
system along with other members of his group. However, these home
directories are frequently accessed from any other server, including
the WWW server and the mail server. Cross mounts galore!
Cross mounts at boot time after power failures are bad unless you use the
background mount option or are willing to wait for important servers to
come up first. (But the latter aren't crossmounts!)
- "hard mounted" is bad .... leaves to hung and un-killable apps and will
freeze your machine sooner or later as more an more ls and df hang
waiting for the remote hard mounted machine to come back online
I tell people that if they really like their data they should use hard
mounts. I point out to customer support that our customers really like
their data, otherwise they would've have found a cheaper solution than that
16 CPU Alpha system.
I know devos who refused to deal with anyone who has an ETIMEOUT error.
Unix systems stay up a lot longer than they did when NFS was first
introduced, soft mounts are a lot less useful than they were back then.
Of the participants at www.connectathon.org, I doubt you'll find anyone
who will call hard mounts "bad", and not too many who will call them "good."
- hard mounted remote fs is good if an only if... you NEED that
remote fs in order to continue working
If you don't NEED that remote fs, why bother mounting it in the first place?
- soft mounted is good ... you can kill hung process or kill it before
waiting for timeouts
Until some extreme load or temporary network partition times out the update
to your mail file.... It's also why Tru64 defaults to "-o hard,intr".
However, we do have a problem that you can't interrupt nfsiod threads
that are trying to get a write done, so interruptible mounts aren't
always.
I was in one Saturday after a power failure and noticed the mail server
had a lot of hung sendmails. I found that one user had set up his
workstation as his home directory and that the mail server was stuck
trying to access his .forward file. And that the luser was on an active
maillist. And that he hadn't set up his system to autoboot. So I booted
his system and sent him a nasty note, cc'ing the admin alias. Actually,
I appreciated seeing in slow motion what we had run into with crashes
and reinstalls of alpha/beta test OSes on production systems.
One can argue that we're crazy to do mail over NFS, but there are a lot of
things we do just in case customers do the same. The biggest problem with
the above was that the NFS client was using one UDP port per sendmail and ran
out of privileged ports. At that point, automount was shafted as it couldn't
mount other FSes (and no one could get to it anyway). That's been fixed as
part of Tru64 scalability work by changing NFS to use just one UDP port and
multiplexing NFS requests & replies over it. Writing our own autofs helps
too. It's been months since the admin folks have dragged me over to help
with mail problems!
have fun linuxing
alvin
http://www.Linux-1U.net ... 800Gb 1U Raid5[tm] ... 6x 200Gb IDE disks
Have fun supercomputing. (Well, I can't as we can't afford our big systems!)
Ric Werme
http://www.psc.edu/publicinfo/news/2001/terascale-10-01-01.html ...
3,000 Alpha EV68 CPUs (4 TFLOPS on linpack), 3 TB RAM, 50 TB? disks, 664 Kw
