lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1238547065.28445.178.camel@heimdal.trondhjem.org>
Date:	Tue, 31 Mar 2009 20:51:05 -0400
From:	Trond Myklebust <Trond.Myklebust@...app.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, viro@...iv.linux.org.uk,
	hch@...radead.org
Subject: Re: [PATCH 1/4] VFS: Add a VFS helper function
 vfs_remote_path_lookup()

On Tue, 2009-03-31 at 17:16 -0700, Linus Torvalds wrote:
> 
> On Tue, 31 Mar 2009, Trond Myklebust wrote:
> > 
> > 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?
> 
> No, that' not the caching I was thinking about.
> 
> I meant literally just the "namespace" thing. Keeping that around as long 
> as you have a export active. How many of those do you have on your average 
> nfs server? Why not just create those nfsd namespaces once for each 
> export at startup, and destroy them at exit.

Wait, I'm confused now.

None of this is running on the server. The private namespace is being
created on the NFSv4 client, which only needs to resolve a mount path as
part of a sys_mount() call.

Unlike NFSv2/v3, there is no MOUNT protocol to translate an NFSv4 mount
path into a filehandle. Instead the client has an operation to fetch the
'root filehandle' (i.e. the filehandle representing 'mount -t nfs4
foo:/') and then does a series of LOOKUP rpc calls to resolve the rest
of the path.

Cheers
  Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@...app.com
www.netapp.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ