From: Alexander Pass (ampass@ftp.com)
Date: 07/21/98-10:52:33 AM Z
Message-ID: <35B4B941.3C0B@ftp.com> Date: Tue, 21 Jul 1998 11:52:33 -0400 From: Alexander Pass <ampass@ftp.com> Subject: NFSv4 - Export enumeration Hi! I'm repeating that message because I've got from Brent: > Until then, the following people may be able to help you: > > NFS Version 4: spencer.shepler@eng.sun.com > > >How do the commands, 'showmount -e' and 'showmount -a', work? > >How can users know what the pathname to lookup? Does nfs-v4 > >get rid of export file? For my understanding, public path is > >set up for one file system only, and export file can set up > >for multiple file systems. What will nfs-v4 change this > >relationship? > > A server that shares or exports filesystems can do it the same way with v4. > Rather than have the user be forced to view separate namespaces or "shares", > a v4 server could implement a pseudo-filesystem navigable by the client that > shows a sparse view of the server's namespace, i.e. only the directories that > are shared. This pseudo-filesystem navigation can be done entirely within > the NFS protocol. > > My guess is that most v4 servers would also support v2 and v3 and share the > same mechanisms for sharing or exporting. So if you're a big showmount > afficionado, there's probably a high correlation that what you see for the > v2/v3 shares is also what's available through v4. I'd prefer it if v4 would > signal a move away from funny little commands like "showmount" that few > end-users know or care about and encourage the use of more conventional > filesystem navigation commands to browse the namespace on a v4 server. > > Brent This is an important thing for PC clients which are used to brouse servers throuhg export points. I'd prefer not keep use MOUNTD for that goal and have everything we need whithin single protocol. About pseudo-filesystem: While I understand that it is rather implementation issue than protocol one, such a thing should be strongly suggested by the protocol. Otherwise I'm afraid it would be lost in many implementations. Actually, that would be very useful for PC cliens to have one-component name for every export point, because now we have to invent them to represent as "shares". So, I'd suggest to have pseudo-filesystem tree like this: Public handle - - export name 1 - ... - export name n Alexander (Sasha) Pass
This archive was generated by hypermail 2.1.2 : 03/04/05-01:46:00 AM Z CST