From: Robert Thurlow (Robert.Thurlow@eng.sun.com)
Date: 09/30/98-11:52:06 AM Z
Date: Wed, 30 Sep 1998 09:52:06 -0700 (PDT) From: Robert Thurlow <Robert.Thurlow@eng.sun.com> Subject: Re: management capabilites for NFSv4 and requirements draft... Message-ID: <Roam.SIMC.2.0.6.907174326.24615.thurlow@jurassic.eng> > Sounds like you have never worked with PC-NFS 5.1, 2000 nodes > across a large state. I don't thing you realize just how hard it is > to do this. My sympathies, but this is a PRODUCT, and not reflective of the capabilities of the PROTOCOL. If you'd had a more modern client, I think you might have been happier, despite the fact that you might have been using the identical PROTOCOL. > You are saying that vendors should write a work around for the client. I'm saying each client implementation should meet the needs of the user community. To do this, implementors need a good NFS protocol, access to name services and a lot of good code. You seem to think that NFS must adopt functionality from all other protocols so it can be the only thing on the client, and I believe this is seriously misguided. NFS V4 should subsume its "crutch" protocols (mounting and locking), but should not go shopping for more functionality to duplicate gratuitously. > Upset ON > > I assume by "wire protocol " you mean that once the file is sent or > recieved we do not care any more. No, I mean the RPCs exchanged between client and server as specified by RFC 1813, the NFS V3 specification. Our job in this working group is updating and adding to that spec. > We are talking about a single function which passes the Platform and > the User ID, and returns a filename. The server would just lookup > a table and run a programme which would give the anwser. I assume this data is available in a name service, and not in files on the server. With that true, funneling all requests to the server just introduces a bottleneck, so it is better that the client refer to the name services directly. The name services can be several things: NIS, NIS+, DHCP, LDAP, etc. Service Location Protocol and DNS cover some of this territory, as well. The LAST thing we need is to try to add name service calls to NFS to give administrators yet another thing to configure and manage. > This protocol must have the functions to support the administrator. > Such as finding a home directory, redirects, setting up the NFS > enviroment, being able to remove locks. I agree with you only on redirection. The client should certainly be told clearly that it should look up the resource again in the name services, and it might be worth an RPC to find the new location, as Mike Eisler suggests. Rob T
This archive was generated by hypermail 2.1.2 : 03/04/05-01:46:28 AM Z CST