Hi all,
I'm one of the NFSv4 developers at the University of Michigan. I'm
currently trying to settle on the best way to implement the NFSv4
"pseudo filesystem" in Linux 2.5, and I'm hoping to solicit feedback
from some other developers.
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=...)
Proposal 2: Require the pseudofs to be built up somewhere on disk,
presumably in a well-known location such as /etc/pseudofs. The
exportfs utility would create real on-disk subdirectories, then
mount --bind the exports onto the leaves of the tree, before starting
nfsd. (Some mechanism would have to be introduced whereby the
top-level pathname /etc/pseudofs could be communicated to the kernel.)
Proposal 3: Build up the pseudofs inside the 2.5 'nfsd' filesystem,
say in a directory nfsd/pseudofs which is created when the nfsd
filesystem is mounted. The exportfs utility would be responsible
for creating the necesary subdirectories, then hanging the exports
off the leaves with mount --bind, before starting nfsd.
As I see it, the disadvantage of proposal 3 is that it is a little
tricky to construct persistent filehandles ("persistent" in the sense
that an old filehandle is still recognize after the server is rebooted).
One solution would be to use an MD5 or SHA hash of the pathname as the
filehandle. The hash could be computed in userspace and passed into
the kernel somehow.
This disadvantage doesn't seem to exist under the other two proposals,
since in both cases each pseudo directory is "backed" by an on-disk
directory, and we can use this directory's filehandle.
Of course, it's possible that no one is interested in having a pseudofs
namespace which is independent of the namespace in the server's
filesystem. If the consensus is that this is not a useful feature, it's
probably easiest to adopt proposal 1.
Feedback/comments welcome!
Cheers,
Kendrick
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [email protected]
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Fri, May 10, 2002 at 02:12:12PM -0400, Kendrick M. Smith wrote:
> 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.)
Create the NFSv4 daemons using clone(.., CLONE_NAMESPACE, ..) and build
your own per-process namespace to fit the exports.
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [email protected]
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Friday May 10, [email protected] wrote:
>
> Proposal 3: Build up the pseudofs inside the 2.5 'nfsd' filesystem,
> say in a directory nfsd/pseudofs which is created when the nfsd
> filesystem is mounted. The exportfs utility would be responsible
> for creating the necesary subdirectories, then hanging the exports
> off the leaves with mount --bind, before starting nfsd.
>
> As I see it, the disadvantage of proposal 3 is that it is a little
> tricky to construct persistent filehandles ("persistent" in the sense
> that an old filehandle is still recognize after the server is rebooted).
> One solution would be to use an MD5 or SHA hash of the pathname as the
> filehandle. The hash could be computed in userspace and passed into
> the kernel somehow.
I would go for 3, and don't care about persistent file handles. Just
use volatile filehandles for this bit of the namespace.
NeilBrown
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [email protected]
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Neil Brown wrote:
>On Friday May 10, [email protected] wrote:
>
>> Proposal 3: Build up the pseudofs inside the 2.5 'nfsd' filesystem,
>> say in a directory nfsd/pseudofs which is created when the nfsd
>> filesystem is mounted. The exportfs utility would be responsible
>> for creating the necesary subdirectories, then hanging the exports
>> off the leaves with mount --bind, before starting nfsd.
>>
>>As I see it, the disadvantage of proposal 3 is that it is a little
>>tricky to construct persistent filehandles ("persistent" in the sense
>>that an old filehandle is still recognize after the server is rebooted).
>>One solution would be to use an MD5 or SHA hash of the pathname as the
>>filehandle. The hash could be computed in userspace and passed into
>>the kernel somehow.
>>
>
>I would go for 3, and don't care about persistent file handles. Just
>use volatile filehandles for this bit of the namespace.
>
>NeilBrown
>-
>To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
I am a bit confused about compatibility of NFSv3, doesn't the nohide
option allow to trigger an exported fs's (dir) subdirectory mount points
to be automatically mounted by clients? If 2.5 is proposing the arbitary
(fs=somepersistentnumber), how nohide is going to know whether the next
fs's number? It is clear in 2.4 now we use the device major and minor
numbers such that only block device fs are exportable. I think there
were a long discussion about the fs= months ago to allow exporting non
block device fs. I have worked hard on making my fs a fake block device
fs in 2.4 which uses an arbitary block device number, but I don't think
it is a good idea to drop the fs= implementation because many times we
want to export non block device fs with a persisten t file handle. I
don't think using arbitary devices for just because want to cope with
NFS is a good idea. I think many of the system rely on the stateless and
persistent design of NFS, since NFS is a de facto standard for Unixes, I
am not happy to see NFSv4 break this.
regards,
David
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [email protected]
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs