Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 153670 - autofs does not do bind mounts with nfsv4
Summary: autofs does not do bind mounts with nfsv4
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: autofs
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ian Kent
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-04-04 20:53 UTC by Orion Poplawski
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-04-17 22:24:48 UTC


Attachments (Terms of Use)
Have sun_mount call mount_nfs for fstype=nfs4 and variants thereof. (deleted)
2005-04-05 16:20 UTC, Jeff Moyer
no flags Details | Diff

Description Orion Poplawski 2005-04-04 20:53:32 UTC
Description of problem:

I'm trying out NFSv4.  We have a /data directory tree of nfs mounts that I've
made a NFSv4 version of like so:

$ cat /etc/auto.master
/data           auto.data       intr
/data4          auto.data4      fstype=nfs4,intr,rsize=32768,wsize=32768

auto.data and auto.data4 are essentially the same, but without the /export
prefix in auto.data4 (since that is the fsid=0 root for NFSv4).

Machines /etc/exports look like:

/export         *.cora.nwra.com(rw,sync,fsid=0)
/export/waves2          *.cora.nwra.com(rw,sync,nohide)
/export/radar3          *.cora.nwra.com(rw,sync,nohide)

and all exported file systems are mounted under /export.

Now, when automount mounts a directory in /data that is hosted on the local
machine, I get a bind mount.  But when it mounts a directory in /data4, I get an
NFSv4 mount.

sample mount output:

/export/waves2 on /data/waves2 type none (rw,bind)
alexandria:/waves2 on /data4/waves2 type nfs4
(rw,intr,rsize=32768,wsize=32768,addr=192.168.0.13)

Can this be fixed somehow?  Also, I see in the automount entries a "maxproto=4"
statement.  I assume this would refer to the NFS version, but this doesn't not
appear to have any effect and you need to specify -fstype=nfs4 in the mount
options.  Or is that the autofs protocol version?

automount(pid3694) on /data type autofs (rw,fd=5,pgrp=3694,minproto=2,maxproto=4)


Version-Release number of selected component (if applicable):
autofs-4.1.3-28

How reproducible:
everytime

Comment 1 Jeff Moyer 2005-04-05 16:10:15 UTC
I'm guessing this configuration triggers the generic mount routine, instead of
the nfs mount routine:

	if (!strcmp(fstype, "nfs")) {
		rv = mount_nfs->mount_mount(root, mountpoint, strlen(mountpoint),
					    what, fstype, options, mount_nfs->context);
	} else {
		/* Generic mount routine */
		rv = do_mount(root, mountpoint, strlen(mountpoint), what, fstype,
			      options);
	}

This should be fairly simple to fix, if my guess is right.  I'll attach a patch.

Comment 2 Jeff Moyer 2005-04-05 16:20:08 UTC
Created attachment 112719 [details]
Have sun_mount call mount_nfs for fstype=nfs4 and variants thereof.

This should address your problem.  The patch was made against the latest CVS,
so it may or may not apply to 4.1.3-28.  Let me know if you need help with
getting this applied/built.

Thanks!

Comment 3 Orion Poplawski 2005-04-05 17:00:14 UTC
This doesn't work.  First of all, it appears to be trying to mount via nfs3 now
rather than nfs4.  Not seeing any errors from an attempt to --bind mount, but I
imagine that would fail too because it would be trying to mount from /data1
rather than /export/data1

Apr  5 10:55:15 alexandria rpc.mountd: refused mount request from
alexandria.cora.nwra.com for /data1 (/): not exported
Apr  5 10:55:15 alexandria automount[6123]: >> mount: alexandria:/data1 failed,
reason given by server: Permission denied
Apr  5 10:55:15 alexandria automount[6123]: mount(nfs): nfs: mount failure
alexandria:/data1 on /data/sw1
Apr  5 10:55:15 alexandria automount[6123]: failed to mount /data/sw1


Comment 4 Jeff Moyer 2005-04-05 17:06:18 UTC
Okay, thanks for the info.  I'll look into this further.  One thing we could do
is to make mount_generic do bind mounts.  I want to investigate a bit more to
make sure this is the best way to do this, though.

Thanks.

Comment 5 Orion Poplawski 2005-04-05 17:37:58 UTC
I installed the rawhide version of autofs and it looks like it just no longer
does bind mounts at all for local nfs filesystems:

alexandria:/export/waves2 on /data/waves2 type nfs
(rw,intr,rsize=8192,wsize=8192,addr=192.168.0.13)

Something appears to have changed between the FC3 version and autofs-4.1.3-107

Comment 6 Jeff Moyer 2005-04-05 18:01:14 UTC
Please include the full contents of all maps involved and I'll take a closer
look.  I cannot reproduce the problem you have with 4.1.3-107.

Thanks.

Comment 7 Chris Feist 2005-04-05 18:17:51 UTC
I think 4.1.3-107 had a problem with local mounts not using --bind.  It should
be fixed in 4.1.3-114.

http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/3/i386/autofs-4.1.3-114.i386.rpm

Comment 8 Orion Poplawski 2005-04-05 20:14:01 UTC
Okay, rebuilt with devel version from CVS (123) plus the above patch.  Now I
think we are just missing the /export path:

Apr  5 14:11:10 alexandria automount[6013]: >> mount: special device /data1 does
not exist
Apr  5 14:11:10 alexandria automount[6013]: failed to mount /data4/sw1
Apr  5 14:11:10 alexandria automount[6015]: >> mount: special device /data1 does
not exist
Apr  5 14:11:10 alexandria automount[6015]: failed to mount /data4/sw1

Not sure how autofs would be able to determine that the nfsv4 paths are relative
to export without parsing /etc/exports:

/export                 *.cora.nwra.com(rw,sync,fsid=0)
/export/amanda          *.cora.nwra.com(rw,sync,nohide,no_root_squash)
/export/data1           *.cora.nwra.com(rw,sync,nohide,no_root_squash)
/export/clouds2         *.cora.nwra.com(rw,sync,nohide)
/export/radar3          *.cora.nwra.com(rw,sync,nohide)
/export/soldyn2         *.cora.nwra.com(rw,sync,nohide)
/export/bigmeadow       *.cora.nwra.com(rw,sync,nohide)
/export/waves2          *.cora.nwra.com(rw,sync,nohide)


Comment 9 Orion Poplawski 2005-05-09 21:53:45 UTC
I'm seeing local NFSv3 mounts not using --bind again with 4.1.4-8:

hawk:/export/web on /data/web type nfs (rw,intr,addr=65.125.157.182)
[root@hawk ftp]#

Comment 10 Jeff Moyer 2006-04-17 20:50:01 UTC
I think this should (again) be resolved in rawhide/fc5.

The issue with NFSv4 mounts stands.  I think that we *should* use the nfs4
protocol to mount those local directories.  The automounter really shouldn't
know about nfs4 internals just so that it can do a bind mount.

So, we still need to fix this.

Thanks for your continued analysis.

Comment 11 Orion Poplawski 2006-04-17 21:34:50 UTC
I'm sorry, I didn't follow that.

I'm running FC4 and FC5 here now.  I get local bind mounts for NFSv3.

If you think the local directories *should* be mounted via nfs4 rather than
bind, than this bug is resolved, NOTABUG.  I'm fine with that, assuming a
minimal performance hit.


Comment 12 Jeff Moyer 2006-04-17 21:52:34 UTC
In the event that you have "fstype=nfs4" in your options, the automounter should
not attempt a bind mount when the server is localhost.  The reason for this is
that the automounter would need nfsv4 specific information to determine where
the mount actually comes from.  As you noted, it's not straight-forward as it is
in v2 and v3.

So, for your nfsv2 and nfsv3 mounts, the automounter should continue to use bind
mounts.  If you specify -fstype=nfs4, then you should get a mount via nfs4.

Clear as mud?

Comment 13 Orion Poplawski 2006-04-17 22:14:48 UTC
Yes, and that's what I'm seeing right now on FC4 and FC5.  So I don't understand
the "So, we still need to fix this." in comment #10.





Comment 14 Jeff Moyer 2006-04-17 22:24:48 UTC
OK, that's a misunderstanding on my part, then.  I'll close this.  Thanks!


Note You need to log in before you can comment on or make changes to this bug.