Subject: RE: [NFS] Re: NFS version 4 at the University of Michigan

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 11 Feb 2002 09:52:44 -0800

I'm not sure what you mean.  Why do you think NFSv4 is a lot
more complex to deploy and manage than NFSv3?  Clearly, V4
is more complex to implement and so right now it is very
difficult or impossible to deploy it since the implementations,
either haven't been released or are in flux and the protocol
is still subject to some change.

However, if we look forward a bit, I expect implementations
to mature and be released.  Why do you believe that it will
be a lot more complex to deploy and manage?  What should 
implementors do to reduce the problems that you see?  Is there
something specific in the protocol that contributes to 
this difficulty?

If this is just a question of objecting to additional complexity
that provides you no benefit, then v4 is not going to be something 
you want to run.  V3 is going to available for a long long time.  
But if there is something specific that can be done to provide
V4 features in a manner that doesn't add to the burden of those
actually using it, then I'd like to hear about it.  

-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]]
Sent: Monday, February 11, 2002 10:25 AM
To: [email-masked]
Cc: Pavel Machek
Subject: Re: [NFS] Re: NFS version 4 at the University of Michigan

On Sat, Pavel Machek wrote:
% Could you sumarise advantages of NFSv4 over v3?

Other folks forgot my personal favourite:
	NFSv4 is lot more complex to deploy and manage than NFSv3.

Ran

---

From: Erez Zadok <[email-masked]>
Date: Tue, 12 Feb 2002 00:56:28 -0500 (EST)

In message <[email-masked]>, "Noveck, Dave" writes:
[...]
> something specific in the protocol that contributes to 

And, unless I missed something, for v4-only we won't need to setup,
configure, or worry about rpc.{statd,lockd,rquotad,mountd,biod,pcnfsd,...}
(Can someone confirm this?)

Having watched newbee's NFS-related mailing lists, a lot of sysadmin/user
problems can be simply traced to a mis-communication or mis-configuration of
one of the numerous rpc services that exist for v2/v3.

I also think that firewall/NAT configurations would be significantly simpler
w/ v4.  (Although I'm not sure all NAT-related issues have been resolved.)

If we want v4 to be widely used and deployed, and be preferred over v2/v3,
it would be very important that it'll be easy to use and configure.
Ideally, each time this wg is faced a problem, we should resist the urge to
produce yet another rpc.whatever service to solve the problem.

OTOH, a complex v4 installation and configuration would guarantee some of us
followup NFS books... :-)

Erez.

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 12 Feb 2002 00:48:33 -0600

> (Can someone confirm this?)

That is correct.  One protocol, generally one daemon.  With the use of
Kerberos or LIPKEY, pcnfsd isn't needed but there will, admittedly, be
security configuration issues.  In my mind that is a separate
configuration/management issue.

> w/ v4.  (Although I'm not sure all NAT-related issues have been resolved.)

We have met the original design goals.  There is still an open issue
related to callback mechanisms that could use bi-directional RPC.

> produce yet another rpc.whatever service to solve the problem.

Management is one aspect.  The other is reasonably performing and
reliable implementations.  We need to manage this through cooperative
testing (which we have been actively pursuing) and expanded test
suites (something we need to build upon current efforts like Peter's).

-- 
Spencer