[KLUG Members] An NFS design/use question...

[Robert G. Brown]

On Sun, 11 Jan 2004 20:02:51 -0500, Adam Williams wrote:

>> [X] [3] Bob, you show signs of promise in the NFS world. Nice idea!

>I'll give you a 3!  What you propose is certainly doable, and should
>work fine.  The only gotcha may be that /home/joe/mail is mounted on an
>NFS mount from a different server (/home).
Quite deliberate.


>So if nfs-one dies you'll probably loose the functionality of both mounts
>just because of the way most tools work in regard to opening files (walkin
>the path for permissions, etc...).
Makes good sense. Knowing the risks is a good thing, and this is a good point.

>For a SOHO LAN I think it is perfectly acceptable.
Yes, I tend to think so. Given the reliability of boxes round here (given
that the admin doesn't horse around with NFS! :) it oughtta be workable.

>For a larger LAN I think you need to just loose the dependency on the
>filesystem for mail (/home/{user}/mail) and move to an IMAP oriented
>solution like Cyrus.  Large systems with mail-in-filesystem are bad
>enough; add NFS and it all goes down the crapper.

Yes, that's true, but in this case, it's off topic. You've been drawn to
make this point by my naming the directory "mail". I could have named it 
"myxlpck-too" for all it meant to my example, or claimed that "mail" stood
for something else. :)

>Only other suggestion might be to not mount /home but to use an
>automounter to connect to subordinate directories as required.
I'll 'speriment with that. In this question, I am aiming for
understaning of what works without a lot of those [other] tools.

On Sun, 11 Jan 2004 20:18:48 -0500, Bruce Smith wrote:

>> But you didn't even give a ranking, you gave "N/A" :)
>I guess "insufficient info" or "huh?" would have been more accurate. :-)

Huh? oh! That's right! :)

>> >Here, rank this command for me:  ls
>> 11 ! :)
>Cool!  How about:  pwd    :-)
7 :)
OK, no more free ratings...
Look for the new book from O'Reilly: "Rating UNIX Commands in a Nutshell" :)

>> If we assume that /Users/joe/mail on nfs-one is empty, then does the 
>> second mount work? 
>
>"empty"?  You mean the directory exists but is empty
Yes

>or the directory doesn't exist at all?
No

>If the directory doesn't exist, the mount will fail.
Sure. Ya hafta have a mount point.

>I admit to never trying mounting a second directory in the middle of an
>already mounted NFS directory, so I don't even know if it'll work.  
Yeah, I decided that trying it wasn't enough, since it might work and
then become unstable. This is why I wanted to get ideas from people who 
have adminned it for a while.

>Speaking generally (single mount, not your multiple mount example), you
>can mount a empty NFS directory, and it appears as empty.  New files go
>on the remote server.  Any existing files on the local server in that
>directory disappear and are not accessible when the NFS dir is mounted.
OK, that's good to know.

>Something else to keep in mind when planning these things, what happens
>when your NFS directory goes "stale" (server goes down)?  It can really
>lock up a NFS client when a stale directory is accessed, and the boot
>may hang when mounting NFS filessystems.  So, if you have a server that
>doesn't run 24/7 (dual boot to Win or something), you might want to make
>the NFS "noauto" in fstab and only mount when needed.  FWIW ...

Yes, it's worth a fair amount, too. Again, there's a need to understand
if the thing will work before getting into these things... another reason 
to look into an automounter, and see what sort of response hit apps take when
the automounter is used. This leads to what data is best kept local, too.

On Sun, 11 Jan 2004 20:09:28 -0500, Adam Williams wrote:

>>What I'm doing may be equally complex in some ways, perhaps even intractable.
>>Going back to the original question...
>>mount nfs-one:/Users /home
>>mount nfs-two:/shared/mail/joe /home/joe/mail
>>If we assume that /Users/joe/mail on nfs-one is empty, then does the 
>>second mount work? 

>It should, regardless of /Users/joe/mail being empty.  Mounts are not
>transparent.  Whatever was in /Users/joe/mail is simply inaccessable by
>the client unless they unmount /Users/joe/mail->/home/joe/mail and then
>access /home/joe/mail.
OK....

>>If this actualy does work reliably and is stable, 
>It should be stable.  Accessing a mbox type mailbox from multiple hosts
>IS NOT!  But the filesystem is stable.
OK, (see above for off-topicness). I don't use mbox-style mailboxes, BTW,
I use nmh, and the GUI for it, EXMH.

>>then there are a couple 
>>of diffferent ways to organizre stuff, and this can be very flexible without
>>creating confusing messes, wof which the above is a VERY SIMPLE example. If
>>it does not work or is unstable and buggy,

>Well, it isn't buggy on what can be considered recent kernels running
>NFSv3 and a good lock implementation. 2.2.x's version of NFSv2 and
>associated locking......well, I wouldn't want to fly over enemy
>territory in that thing.
Hey, I wouldn't have wanted to fly over FRIENDLY territory with some of the 
disasters I've seen with rpc.lockd on some commercial systems before about
1997, and I was conernedabout the same stunt given some of the stuff I've 
discussed doing in this thread.


Thanks to both Adam and Bruce for their responses. There's hope for me, having 
received a "3"! :)

							Regards,
							---> RGB <---