kernel panic when accessing local filesystems on NFS server

kernel panic when accessing local filesystems on NFS server

[Guillaume Rousse]

Hello.

Since last reboot, I encounter heavy troubles when trying to access
local filesystems also advertised by LDAP as available for auto-mounting.

/etc/fstab:
...
/dev/hdb1 /home/graves/ftp ext3 defaults 1 2

/etc/exports:
...
/home/graves/ftp/pub    *.inria.fr(ro,async,all_squash,insecure)

/etc/init.d/autofs status:
...
/usr/sbin/automount --timeout=60 /home/graves ldap
ou=auto.home.graves,ou=autofs,dc=village,dc=inria,dc=fr

LDAP client map:
# auto.home.graves, autofs, village.inria.fr
dn: ou=auto.home.graves,ou=autofs,dc=village,dc=inria,dc=fr
objectClass: top
objectClass: automountMap
ou: auto.home.graves

# /, auto.home.graves, autofs, village.inria.fr
dn: cn=/,ou=auto.home.graves,ou=autofs,dc=village,dc=inria,dc=fr
objectClass: top
objectClass: automount
cn: /
automountInformation: -fstype=nfs,hard,intr graves:/home/graves/&

When autofs is not activated, ls /home/graves/ftp works OK. As soon as
autofs is activated, ls /home/graves/ftp triggers immediate kernel
panics (can't handle kernel paging request). This is happening on a
mandriva 10.2, running kernel 2.6.11-13mdk, with autofs 4.1.4. It is
also a recent problem, which didn't occured earlier.

It seems I have to hide client maps to servers exporting them. Which is
quite difficult as I use LDAP precisely to propagate a centralised
configuration. But even if my configuration is wrong, autofs ought to be
a little more robust here.

Re: kernel panic when accessing local filesystems on NFS server

[Jeff Moyer]

==> Regarding [autofs] kernel panic when accessing local filesystems on NFS server; Guillaume Rousse <Guillaume.Rousse@inria.fr> adds:

Guillaume.Rousse> When autofs is not activated, ls /home/graves/ftp works
Guillaume.Rousse> OK. As soon as autofs is activated, ls /home/graves/ftp
Guillaume.Rousse> triggers immediate kernel panics (can't handle kernel
Guillaume.Rousse> paging request). This is happening on a mandriva 10.2,
Guillaume.Rousse> running kernel 2.6.11-13mdk, with autofs 4.1.4. It is
Guillaume.Rousse> also a recent problem, which didn't occured earlier.

Guillaume.Rousse> It seems I have to hide client maps to servers exporting
Guillaume.Rousse> them. Which is quite difficult as I use LDAP precisely to
Guillaume.Rousse> propagate a centralised configuration. But even if my
Guillaume.Rousse> configuration is wrong, autofs ought to be a little more
Guillaume.Rousse> robust here.

Autofs is probably attempting a recursive bind mount.  This problem was
fixed, upgrade your kernel.

	http://lkml.org/lkml/2005/6/4/11

-Jeff

Re: kernel panic when accessing local filesystems on NFS server

[Guillaume Rousse]

Jeff Moyer wrote:
> Autofs is probably attempting a recursive bind mount.  This problem was
> fixed, upgrade your kernel.
> 
> 	http://lkml.org/lkml/2005/6/4/11
Thanks, this fixed the crash issue.

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.

If however /etc/fstab has exactly the same mount point defined, it seems
the init script correctly filter it (it is configured, but not
activated), preventing the issue.

Is this expected behaviour ?

Re: kernel panic when accessing local filesystems on NFS server

[Jim Carter]

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.  

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.

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA  90095-1555
Email: jimc@math.ucla.edu    http://www.math.ucla.edu/~jimc (q.v. for PGP key)

Re: kernel panic when accessing local filesystems on NFS server

[Guillaume Rousse]

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 :)