mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk,
	hch@infradead.org
Subject: Re: [PATCH 1/4] VFS: Add a VFS helper function vfs_remote_path_lookup()
Date: Tue, 31 Mar 2009 19:38:42 -0400	[thread overview]
Message-ID: <1238542722.28445.154.camel@heimdal.trondhjem.org> (raw)
In-Reply-To: <alpine.LFD.2.00.0903311540120.6474@localhost.localdomain>

On Tue, 2009-03-31 at 15:43 -0700, Linus Torvalds wrote:
> 
> On Tue, 31 Mar 2009, Trond Myklebust wrote:
> > 
> > No. The main purpose is to able to look up and walk down an NFSv4 mount
> > path, which is a path on the _server_'s file/directory namespace.
> 
> Sure, but that's not the "swizzle" part.
> 
> If it was just abotu the namespace part, then you'd just do one namespace 
> per server, and be done with it.
> 
> So if you split that function up into a sepate
>  - allocate namespace for nfsd
>  - free nfsd namespace
>  - do the lookup
> 
> then really _all_ the extraneous code comes just from that "playing games 
> with it" swizzling part.

Fair enough.

My main technical problem with the namespace per server is knowing when
it is safe to release it. AFAICS, you want to cache the per-server
namespace if there are mount points on "public" namespaces that
reference that server, but release it if the only remaining mount points
are the ones on the per-server namespace itself.

> > > And I think it's positively _wrong_ to have a function that creates and 
> > > destroys the whole "struct fs_struct" and a namespace for just one call. 
> > > Even if you don't think it's at all performance-critical, the interface is 
> > > too damn ugly. Have separate "create/destroy context" functions, so that 
> > > you _can_ do it just once, and have multiple calls in between.
> > 
> > That can probably be done, but the main reason for having the namespace
> > was to be able, once the sys_mount() is complete, to garbage collect and
> > get rid of those autogenerated mount points that are not user visible.
> 
> So there is never any reason to do that nfsd-specific pathwalk at 
> run-time? There are no "server pwd" requests that clients can do?

NFSv4 does theoretically support the idea of volatile filehandles. If
so, and the server were to declare that your mount point's filehandle
has expired, then your only way of recovering would be to look up that
mount path again. (We might perhaps implement client support for that
some day if somebody discovers a good enough reason).

However, if your mount point filehandle has expired, then chances are
that you'll probably have to look up all the filehandles in the mount
path again too, so why should you cache all that information?

Cheers
  Trond

-- 
Trond Myklebust
Linux NFS client maintainer

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

  reply	other threads:[~2009-03-31 23:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-31 18:52 [PATCH 0/4] Allow NFS to use ordinary path lookup when mounting NFSv4 Trond Myklebust
2009-03-11 19:50 ` [PATCH 1/4] VFS: Add a VFS helper function vfs_remote_path_lookup() Trond Myklebust
2009-03-31 21:40   ` Linus Torvalds
2009-03-31 22:37     ` Trond Myklebust
2009-03-31 22:43       ` Linus Torvalds
2009-03-31 23:38         ` Trond Myklebust [this message]
2009-04-01  0:16           ` Linus Torvalds
2009-04-01  0:51             ` Trond Myklebust
2009-04-01  1:04               ` Linus Torvalds
2009-03-31 22:49       ` Trond Myklebust
2009-04-01  2:15   ` Al Viro
2009-04-01 13:06     ` Trond Myklebust
2009-03-11 19:50 ` [PATCH 2/4] NFSv4: Use vfs_path_lookup() instead of nfs4_path_walk() Trond Myklebust
2009-03-11 19:50 ` [PATCH 3/4] NFS: Fix nfs_path() to always return a '/' at the beginning of the path Trond Myklebust
2009-03-11 19:50 ` [PATCH 4/4] NFS: Correct the NFS mount path when following a referral Trond Myklebust

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=1238542722.28445.154.camel@heimdal.trondhjem.org \
    --to=trond.myklebust@netapp.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®