From: Guillaume Rousse <Guillaume.Rousse@inria.fr>
Cc: autofs@linux.kernel.org
Subject: Re: kernel panic when accessing local filesystems on NFS server
Date: Sun, 16 Apr 2006 19:29:46 +0200 [thread overview]
Message-ID: <44427F0A.5060306@inria.fr> (raw)
In-Reply-To: <Pine.LNX.4.63.0604131540270.6043@simba.math.ucla.edu>
Jim Carter wrote:
> On Thu, 13 Apr 2006, Guillaume Rousse wrote:
>> However, it seems automount is still taking priority on direct access if
>> a mount point is activated.
>>
>> If my /etc/fstab says:
>> /dev/hda1 /home
>>
>> and /etc/init.d/autofs status says:
>> /usr/sbin/automount /home/graves ldap
>> ou=auto.home.graves,ou=autofs,dc=village,dc=inria,dc=fr
>>
>> Any attempt to access /home/graves on graves host will mount it through
>> autofs, and access it through NFS, masking local filesystem and probably
>> wasting resources.
>
> I'm not 100% sure of your configuration; however, my experience is that if
> I use autofs to access a filesystem on the same host, it will do a bind
> mount rather than a NFS mount, and the bind mount has (I think) totally
> zero cost once made.
Right, it was a bind mount, not a NFS mount.
> As an example, here's what we do:
>
> On host1, the homedir of userA is /h3/userA (not really capitalized).
> On host2, the homedir of userB is /h4/userB.
>
> On both hosts we do: automount /net file /etc/auto.net
> /etc/auto.net says:
> * -other,options,fstype=autofs,-DSERVER=& file:/etc/auto.net.generic
> /etc/auto.net.generic says:
> * ${SERVER}:/&
>
> In other words, if you refer to /net/$anyhost/$anything, the leader process
> will spawn a submount process specific to $anyhost which will attempt to
> mount /$anything off of $anyhost. ($anyhost only delivers directories
> (filesystems) in /etc/exports, and off-site traffic is blocked at the
> firewall, but the mount will be attempted even so.)
>
> The password map says that the homedir of userA is /net/host1/h3/userA,
> and ~userB is /net/host2/h4/userB.
>
> Executing on host1, you use /net/host2/h4/userB and the automount process
> does "mount -t nfs host2:/h4 /net/host2/h4". On the other hand, if you
> refer to /net/host1/h3/userA it is smart enough to do "mount --bind /h3
> /net/host1/h3", and /proc/mounts says:
> /dev/sdb4 /h3 ext3 rw 0 0
> /dev/sdb4 /net/sunset/h3 ext3 rw 0 0
>
> We have the actual filesystems (here, /h3) separated from the automounted
> path names (here, /net/host1/h3). If we tried to have both "real"
> directories and automount points in the same containing directory, I doubt
> it would work; at best it would be a can of worms.
Yes, that's my point :)
prev parent reply other threads:[~2006-04-16 17:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-12 12:48 kernel panic when accessing local filesystems on NFS server Guillaume Rousse
2006-04-12 18:20 ` Jeff Moyer
2006-04-13 12:18 ` Guillaume Rousse
2006-04-13 23:12 ` Jim Carter
2006-04-16 17:29 ` Guillaume Rousse [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44427F0A.5060306@inria.fr \
--to=guillaume.rousse@inria.fr \
--cc=autofs@linux.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.