From: Boris Z. (boris@conley.com)
Date: 10/07/98-02:12:48 PM Z
Message-ID: <01BDF1EB.CD362C10.boris@conley.com> From: "Boris Z." <boris@conley.com> Subject: RE: locking errors Date: Wed, 7 Oct 1998 12:12:48 -0700 On Tuesday, October 06, 1998 2:57 PM, Mike Eisler [SMTP:mre@Eng.Sun.COM] wrote: > > > I believe the protocol should not limit servers to answer these questions as > > they want. Some of them may want to answer "yes, yes, yes, no" and declare > > themselves ready for 'mission critical applications'. The protocol just > > Perhaps I should re-cast my 4 questions as the following requirements: > > - NFS V4 MUST work through firewalls that block UDP and block > TCP connection requests (SYNs) that originate outside > the firewall. > > - NFS V4 servers MUST NOT be required to maintain state through > server reboots. > > - The NFS V4 protocol specification > MUST NOT specify a minimum or maximum lease time on the > server. > > - Clients MUST NOT expect to retain locks across network partitions > that exceed a lease time. > > - The server, and not the client ,ultimately dictates the lease time. > > I think all of the above are requirements. If one thinks one or more of the > above are not requirements, and/or thinks that the opposite of one or more > of the above is a requirement, then that dictates a different kind of > locking paradigm. If I interpret what you are saying, you would agree that > the latter 4 are requirements, and the 1st one (operation through firewalls) > is not a requirement. > I agree almost with all you 'MUST' points, it's a right words for the requirement document. However, the case of "Clients MUST NOT expect to retain locks across network partitions that exceed a lease time" should not mean that client MUST re-establish ALL locks, if by some reason it could not renew the lease. We should allow a simple mechanism to check, if any of the client locks are actually broken or not. About the firewalls: we should not introduce anything in this place of the protocol that cannot work through the firewalls. But this does not mean that I am ready to drop UDP support!
This archive was generated by hypermail 2.1.2 : 03/04/05-01:46:30 AM Z CST