From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: NFSv4 pseudo filesystem Date: 10 May 2002 16:14:49 -0700 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Return-path: Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id QAA22275 for ; Fri, 10 May 2002 16:15:10 -0700 Received: from palladium.transmeta.com (palladium.transmeta.com [10.1.1.46]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id g4ANEpj15430 for ; Fri, 10 May 2002 16:14:52 -0700 (PDT) Received: (from mail@localhost) by palladium.transmeta.com (8.9.3/8.9.3) id QAA31379 for linux-fsdevel@vger.kernel.org; Fri, 10 May 2002 16:14:51 -0700 To: linux-fsdevel@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Followup to: By author: "Kendrick M. Smith" 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 -- at work, in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt