All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: linux-fsdevel@vger.kernel.org
Subject: Re: NFSv4 pseudo filesystem
Date: 10 May 2002 16:14:49 -0700	[thread overview]
Message-ID: <abhk99$jh5$1@cesium.transmeta.com> (raw)
In-Reply-To: Pine.SOL.4.44.0205101340370.27306-100000@mspacman.gpcc.itd.umich.edu

Followup to:  <Pine.SOL.4.44.0205101340370.27306-100000@mspacman.gpcc.itd.umich.edu>
By author:    "Kendrick M. Smith" <kmsmith@umich.edu>
In newsgroup: linux.dev.fs.devel
> 
> Background: In NFSv2/v3, the server's exports are more or less independent
> of each other, and must be mounted seperately by the client.  NFSv4
> introduced the requirement that the server must export a 'root filehandle'
> (which must be a directory), and that all the exports be obtainable by
> browsing the subtree rooted at the root filehandle.  In other words, the
> server must present the client with ficticious directories, which live
> above the exports and serve to tie them all together into one tree.  (The
> term "pseudo filesystem" is used to refer to this collection of ficticious
> directories.)
> 
>   Proposal 1: Have the server export a pseudofs which "mirrors" the actual
>   namespace on the server, or at least enough of it to cover all the
>   exports.  In other words, if the server's exports are named
>   /home/kmsmith and /usr/local/src, then the server will present the
>   client with the following pseudo filesystem:
> 
>                              /
>        /home                                 /usr
>        /home/kmsmith                         /usr/local
>           ...                                /usr/local/src
>                                                   ...
> 
> 
> This is the approach suggested by RFC3010 for Unix servers, but it
> seems like a nice feature to relax the requirement that pathnames in
> the pseduofs be the same as pathnames in the server's filesystem.
> The next 2 proposals allow the possibility of setting up an
> arbitarily-named tree of ficticious directories, for the server
> to export as the pseudofs.  (This would require changing the
> /etc/exports file format, presumably in a backward-compatible way,
> such as adding an export option pseudo_pathname=...)
> 

I would really like to suggest making it possible to map these
arbitrarily, although the default should presumably be the "real"
path.

This, in fact, applies to NFSv2/v3 as well: the path that you want to
mount a client with shouldn't need to be so closely tied to the path
on the physical filesystem.

For example, I should be able to specify something like:

/exports/clients/dorkface/ready \
	somehost.bigcorp.com(ro,path=/clients/bigcorp) \
	*.mycorp.com(rw)

... and have somehost.bigcorp.com mount this filesystem as
myhost.mycorp.com:/clients/bigcorp whereas my own local hosts would
see it as /export/clients/dorkface/ready.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

  parent reply	other threads:[~2002-05-10 23:15 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <message from Anton Altaparmakov on Saturday May 11>
     [not found] ` <message from Kendrick M. Smith on Friday May 10>
2002-05-10 18:12   ` NFSv4 pseudo filesystem Kendrick M. Smith
2002-05-10 18:18     ` Christoph Hellwig
2002-05-10 18:18     ` Christoph Hellwig
2002-05-10 23:14     ` H. Peter Anvin [this message]
2002-05-11  6:31     ` Neil Brown
2002-05-11 17:39       ` David Chow
2002-05-11 17:39       ` David Chow
2002-05-11 20:19       ` NFS export operations question and BUG report Anton Altaparmakov
2002-05-11 20:21         ` Anton Altaparmakov
2002-05-11 21:08           ` Anton Altaparmakov
2002-05-11 21:43             ` Neil Brown
2002-05-11 23:09               ` Anton Altaparmakov
2002-05-11 21:18         ` Neil Brown
2002-05-11 22:38           ` Anton Altaparmakov
2002-05-12  7:39             ` Alexander Viro
     [not found]             ` <Pine.GSO.4.21.0205120330410.23398-100000@weyl.math.psu.edu >
2002-05-12 12:00               ` Anton Altaparmakov
2002-05-12 16:20                 ` Jan Harkes
2002-05-13  6:54                 ` Neil Brown
2002-05-11  6:31     ` NFSv4 pseudo filesystem Neil Brown
2002-05-10 18:12 Kendrick M. Smith
  -- strict thread matches above, loose matches on Subject: below --
2002-05-11  0:13 Bryan Henderson

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='abhk99$jh5$1@cesium.transmeta.com' \
    --to=hpa@zytor.com \
    --cc=linux-fsdevel@vger.kernel.org \
    /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.