From: David Howells <dhowells@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: dhowells@redhat.com, raven@themaw.net, viro@ZenIV.linux.org.uk,
jlayton@redhat.com, gregkh@suse.de,
torvalds@linux-foundation.org, linux-nfs@vger.kernel.org,
leonardo.lists@gmail.com
Subject: Re: [PATCH] NFS4: Revert commit to make the automount code ignore LOOKUP_FOLLOW
Date: Thu, 22 Sep 2011 14:41:30 +0100 [thread overview]
Message-ID: <24566.1316698890@redhat.com> (raw)
In-Reply-To: <878vpgwx76.fsf@tucsk.pomaz.szeredi.hu>
Miklos Szeredi <miklos@szeredi.hu> wrote:
> > When it goes wrong, what happens is that nfs_follow_remote_path() walks from
> > the rootfh to the remote directory (/scratch) using vfs_path_lookup(). It
> > passes LOOKUP_FOLLOW to vfs_path_lookup() to tell it to transit terminal
> > symlinks and terminal automounts. Unfortunately, with the aforementioned
> > commit, LOOKUP_FOLLOW now expressly does not follow terminal
> > automounts.
>
> What is exactly happening here? By not following automounts how do we
> end up with two mounts instead of one? I would have guessed the other
> way round.
Linux's NFS4 client performs a VFS path walk to resolve the path in the mount
devname to the root fh of the new mount. This differs from NFS2/3 where the
client asks the server's mountd to do it.
With the situation I described, where you're attempting to directly mount a
directory that's the root of a mount on the server (but not the root of the
whole filesystem tree), you have a situation where the FSID changes as you
walk through the tree.
So, for example, assume "/" is on fsid 0 and "/scratch" is on fsid 1.
Now, when NFS sees a change of fsid, it interpolates an automount point on the
directory in which it saw the fsid change:
/ (FSID0)
|
|
|
scratch (S_AUTOMOUNT set)
(FSID0)
and, when triggered, d_automount
will then create a new superblock for the new fsid and that will get mounted
on the automount point:
/ (FSID0)
|
|
|
scratch ::::::::::::/(FSID1)
(FSID0) |
|-----|-----|-----|
| | | |
a b c d
However, during the NFS4 root lookup pathwalk, because the root of fsid 1 is
terminal in the path, with your patch it will not trigger automounting because
none of LOOKUP_PARENT, _DIRECTORY, _OPEN or _CREATE are set. LOOKUP_FOLLOW
was set and *that* used to be sufficient to force the automount.
So what happens is that scratch from fsid 0 gets mounted rather than / from
fsid 1 and this is an automount point. It will cause / from fsid 1 to be
mounted eventually when someone goes into it, but then you have to do two
unmounts to get rid of it instead of one.
David
next prev parent reply other threads:[~2011-09-22 13:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-22 12:46 [PATCH] NFS4: Revert commit to make the automount code ignore LOOKUP_FOLLOW David Howells
2011-09-22 12:50 ` David Howells
2011-09-22 12:58 ` Miklos Szeredi
2011-09-22 13:41 ` David Howells [this message]
2011-09-22 14:23 ` Miklos Szeredi
2011-09-22 14:33 ` Linus Torvalds
2011-09-22 15:22 ` David Howells
2011-09-22 15:32 ` Miklos Szeredi
2011-09-22 15:33 ` Jeff Layton
2011-09-22 15:54 ` Ian Kent
2011-09-22 15:26 ` Jeff Layton
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=24566.1316698890@redhat.com \
--to=dhowells@redhat.com \
--cc=gregkh@suse.de \
--cc=jlayton@redhat.com \
--cc=leonardo.lists@gmail.com \
--cc=linux-nfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=raven@themaw.net \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
/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.