All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH][RFC] NFS: Propagate 'fsc' mount option through automounts
@ 2009-07-09 17:27 David Howells
  2009-07-09 17:50 ` Trond Myklebust
  2009-07-14 17:47 ` David Howells
  0 siblings, 2 replies; 5+ messages in thread
From: David Howells @ 2009-07-09 17:27 UTC (permalink / raw)
  To: Trond Myklebust, steved; +Cc: dhowells, nfsv4, linux-kernel


Propagate the NFS 'fsc' mount option through NFS automounts of various types.

This is now required as commit:

	commit c02d7adf8c5429727a98bad1d039bccad4c61c50
	Author: Trond Myklebust <Trond.Myklebust@netapp.com>
	Date:   Mon Jun 22 15:09:14 2009 -0400

	NFSv4: Replace nfs4_path_walk() with VFS path lookup in a private namespace

now uses VFS-driven automounting to reach all submounts barring the root, thus
preventing fscaching from being enabled on any submount other than the root.

This patch gets around that by propagating the NFS_OPTION_FSCACHE flag across
automounts.

Note, however, that it doesn't propagate the uniquifier in the case of
'fsc=<xxx>' being passed to mount.  This is probably wrong, and needs looking
at.

Signed-off-by: David Howells <dhowells@redhat.com>
---

 fs/nfs/client.c |    1 +
 fs/nfs/super.c  |    6 ++++++
 2 files changed, 7 insertions(+), 0 deletions(-)


diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index c2d0616..0949b46 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -964,6 +964,7 @@ static void nfs_server_copy_userdata(struct nfs_server *target, struct nfs_serve
 	target->acdirmin = source->acdirmin;
 	target->acdirmax = source->acdirmax;
 	target->caps = source->caps;
+	target->options = source->options;
 }
 
 /*
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 0b4cbdc..bfab16f 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -2214,6 +2214,7 @@ static int nfs_xdev_get_sb(struct file_system_type *fs_type, int flags,
 	struct nfs_server *server;
 	struct dentry *mntroot;
 	int (*compare_super)(struct super_block *, void *) = nfs_compare_super;
+	struct nfs_parsed_mount_data parsed_data = { .fscache_uniq = NULL, };
 	struct nfs_sb_mountdata sb_mntdata = {
 		.mntflags = flags,
 	};
@@ -2251,6 +2252,7 @@ static int nfs_xdev_get_sb(struct file_system_type *fs_type, int flags,
 	if (!s->s_root) {
 		/* initial superblock/root creation */
 		nfs_clone_super(s, data->sb);
+		nfs_fscache_get_super_cookie(s, &parsed_data);
 	}
 
 	mntroot = nfs_get_root(s, data->fh);
@@ -2687,6 +2689,7 @@ static int nfs4_xdev_get_sb(struct file_system_type *fs_type, int flags,
 	struct nfs_server *server;
 	struct dentry *mntroot;
 	int (*compare_super)(struct super_block *, void *) = nfs_compare_super;
+	struct nfs_parsed_mount_data parsed_data = { .fscache_uniq = NULL, };
 	struct nfs_sb_mountdata sb_mntdata = {
 		.mntflags = flags,
 	};
@@ -2724,6 +2727,7 @@ static int nfs4_xdev_get_sb(struct file_system_type *fs_type, int flags,
 	if (!s->s_root) {
 		/* initial superblock/root creation */
 		nfs4_clone_super(s, data->sb);
+		nfs_fscache_get_super_cookie(s, &parsed_data);
 	}
 
 	mntroot = nfs4_get_root(s, data->fh);
@@ -2768,6 +2772,7 @@ static int nfs4_remote_referral_get_sb(struct file_system_type *fs_type,
 	struct dentry *mntroot;
 	struct nfs_fh mntfh;
 	int (*compare_super)(struct super_block *, void *) = nfs_compare_super;
+	struct nfs_parsed_mount_data parsed_data = { .fscache_uniq = NULL, };
 	struct nfs_sb_mountdata sb_mntdata = {
 		.mntflags = flags,
 	};
@@ -2805,6 +2810,7 @@ static int nfs4_remote_referral_get_sb(struct file_system_type *fs_type,
 	if (!s->s_root) {
 		/* initial superblock/root creation */
 		nfs4_fill_super(s);
+		nfs_fscache_get_super_cookie(s, &parsed_data);
 	}
 
 	mntroot = nfs4_get_root(s, &mntfh);

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH][RFC] NFS: Propagate 'fsc' mount option through automounts
  2009-07-09 17:27 [PATCH][RFC] NFS: Propagate 'fsc' mount option through automounts David Howells
@ 2009-07-09 17:50 ` Trond Myklebust
  2009-07-14 17:47 ` David Howells
  1 sibling, 0 replies; 5+ messages in thread
From: Trond Myklebust @ 2009-07-09 17:50 UTC (permalink / raw)
  To: David Howells; +Cc: steved, nfsv4, linux-kernel

On Thu, 2009-07-09 at 18:27 +0100, David Howells wrote:
> Propagate the NFS 'fsc' mount option through NFS automounts of various types.
> 
> This is now required as commit:
> 
> 	commit c02d7adf8c5429727a98bad1d039bccad4c61c50
> 	Author: Trond Myklebust <Trond.Myklebust@netapp.com>
> 	Date:   Mon Jun 22 15:09:14 2009 -0400
> 
> 	NFSv4: Replace nfs4_path_walk() with VFS path lookup in a private namespace
> 
> now uses VFS-driven automounting to reach all submounts barring the root, thus
> preventing fscaching from being enabled on any submount other than the root.
> 
> This patch gets around that by propagating the NFS_OPTION_FSCACHE flag across
> automounts.
> 
> Note, however, that it doesn't propagate the uniquifier in the case of
> 'fsc=<xxx>' being passed to mount.  This is probably wrong, and needs looking
> at.

Why not just use the mount path as the default uniquifier?

> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
> 
>  fs/nfs/client.c |    1 +
>  fs/nfs/super.c  |    6 ++++++
>  2 files changed, 7 insertions(+), 0 deletions(-)
> 
> 
> diff --git a/fs/nfs/client.c b/fs/nfs/client.c
> index c2d0616..0949b46 100644
> --- a/fs/nfs/client.c
> +++ b/fs/nfs/client.c
> @@ -964,6 +964,7 @@ static void nfs_server_copy_userdata(struct nfs_server *target, struct nfs_serve
>  	target->acdirmin = source->acdirmin;
>  	target->acdirmax = source->acdirmax;
>  	target->caps = source->caps;
> +	target->options = source->options;

BTW: Why does fscache require a private flag field?

>  }
>  
>  /*
> diff --git a/fs/nfs/super.c b/fs/nfs/super.c
> index 0b4cbdc..bfab16f 100644
> --- a/fs/nfs/super.c
> +++ b/fs/nfs/super.c
> @@ -2214,6 +2214,7 @@ static int nfs_xdev_get_sb(struct file_system_type *fs_type, int flags,
>  	struct nfs_server *server;
>  	struct dentry *mntroot;
>  	int (*compare_super)(struct super_block *, void *) = nfs_compare_super;
> +	struct nfs_parsed_mount_data parsed_data = { .fscache_uniq = NULL, };

Rather than wasting all this space on the stack, how about just changing
the second argument of nfs_fscache_get_super_cookie()? You only use the
pointer to data->fscache_uniq.

>  	struct nfs_sb_mountdata sb_mntdata = {
>  		.mntflags = flags,
>  	};

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH][RFC] NFS: Propagate 'fsc' mount option through automounts
  2009-07-09 17:27 [PATCH][RFC] NFS: Propagate 'fsc' mount option through automounts David Howells
  2009-07-09 17:50 ` Trond Myklebust
@ 2009-07-14 17:47 ` David Howells
  2009-07-14 19:03   ` Trond Myklebust
  2009-07-15 10:50   ` David Howells
  1 sibling, 2 replies; 5+ messages in thread
From: David Howells @ 2009-07-14 17:47 UTC (permalink / raw)
  To: Trond Myklebust; +Cc: dhowells, steved, nfsv4, linux-kernel

Trond Myklebust <Trond.Myklebust@netapp.com> wrote:

> Why not just use the mount path as the default uniquifier?

Because:

 (1) Which mount path?  You're now constructing the mount tree in its own
     private namespace.

 (2) Due to the new VFS-pathwalk-based mount, the uniquifier is applied to the
     root mount only, and if modified to inherit, would be applied to every
     automount subordinate to that, rather than just the actual subject of the
     mount.

 (3) Due to the new VFS-pathwalk-based mount and the private namespace, the
     default uniquifier for all instances of any particular mount is always
     the same.

 (4) If we work around some how the mounts now getting their mount path from
     the private namespace, there are still real namespaces, chroots and
     root-pivots to contend with.

> > +	target->options = source->options;
> 
> BTW: Why does fscache require a private flag field?

I thought it best to avoid touching nfs_server::flags as that is at least
partially visible to userspace.

> > +	struct nfs_parsed_mount_data parsed_data = { .fscache_uniq = NULL, };
> 
> Rather than wasting all this space on the stack, how about just changing
> the second argument of nfs_fscache_get_super_cookie()? You only use the
> pointer to data->fscache_uniq.

Yeah, that's probably wise.

Actually, I don't really want to get this data via mount at all (as there are
automounts to locally configure for caching).

David

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH][RFC] NFS: Propagate 'fsc' mount option through automounts
  2009-07-14 17:47 ` David Howells
@ 2009-07-14 19:03   ` Trond Myklebust
  2009-07-15 10:50   ` David Howells
  1 sibling, 0 replies; 5+ messages in thread
From: Trond Myklebust @ 2009-07-14 19:03 UTC (permalink / raw)
  To: David Howells; +Cc: steved, nfsv4, linux-kernel

On Tue, 2009-07-14 at 18:47 +0100, David Howells wrote:
> Trond Myklebust <Trond.Myklebust@netapp.com> wrote:
> 
> > Why not just use the mount path as the default uniquifier?
> 
> Because:
> 
>  (1) Which mount path?  You're now constructing the mount tree in its own
>      private namespace.

The natural thing would be to use the mount path that is required to
locate the super block's root dentry on the server (i.e. the mount path
for sb->s_root).
In the private namespace (since that reflects the namespace of the
server, and hence mnt->mnt_root == sb->s_root) this mount path will
always be the same as the contents of mnt->mnt_devname. 

(In the local namespace, however, sb->s_root != mnt->mnt_root, and so
mnt->mnt_devname is fixed up to reflect that difference. See
nfs_fix_devname()...)

>  (2) Due to the new VFS-pathwalk-based mount, the uniquifier is applied to the
>      root mount only, and if modified to inherit, would be applied to every
>      automount subordinate to that, rather than just the actual subject of the
>      mount.
>
>  (3) Due to the new VFS-pathwalk-based mount and the private namespace, the
>      default uniquifier for all instances of any particular mount is always
>      the same.

...and is that sufficient? If it is, then fine, let's leave it...

>  (4) If we work around some how the mounts now getting their mount path from
>      the private namespace, there are still real namespaces, chroots and
>      root-pivots to contend with.

Real namespaces, chroots and root-pivots are all changes to the client
only. They do not change the server's namespace, and hence the mount
path is invariant.

     Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH][RFC] NFS: Propagate 'fsc' mount option through automounts
  2009-07-14 17:47 ` David Howells
  2009-07-14 19:03   ` Trond Myklebust
@ 2009-07-15 10:50   ` David Howells
  1 sibling, 0 replies; 5+ messages in thread
From: David Howells @ 2009-07-15 10:50 UTC (permalink / raw)
  To: Trond Myklebust; +Cc: dhowells, steved, nfsv4, linux-kernel

Trond Myklebust <Trond.Myklebust@netapp.com> wrote:

> > > Why not just use the mount path as the default uniquifier?

In fact, why change it from being blank?  If I do this:

	The natural thing would be to use the mount path that is required to
	locate the super block's root dentry on the server (i.e. the mount
	path for sb->s_root).

then it may as well be blank, since the FSID is a sufficient uniquifier, and
that's also included in the key.


Where a uniquifier is needed is when someone sets up two mounts of the same
thing, but with different network parameters as these aren't recorded in the
key.  Under such a circumstance, manual intervention is required in the form
of a supplied uniquifier on one of the mounts.

That uniquifier should also only apply to the superblock actually being
mounted, I think; but it's probably okay to apply it to all the intervening
transient superblocks from root that nfs_follow_remote_path() causes to exist,
and just accept that you might get a little bit of rubbish in the cache once
we start caching directories.

Also, the uniquifier would be applied to all superblocks that get created by
automounts under a superblock that has a uniquifier.

David

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2009-07-15 10:51 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-07-09 17:27 [PATCH][RFC] NFS: Propagate 'fsc' mount option through automounts David Howells
2009-07-09 17:50 ` Trond Myklebust
2009-07-14 17:47 ` David Howells
2009-07-14 19:03   ` Trond Myklebust
2009-07-15 10:50   ` David Howells

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.