This post will make some comparisons between NFSv4 and NFSv3, and introduce how to migrate from NFSv3 to NFSv4.
As we all aware, NFSv4 is not just a simple protocol evolution of NFSv3. It has been fully redesigned to overcome the limitations of its predecessors.
Comparison Between NFSv3 and NFSv4
1. Transport protocols
For NFSv3, the MOUNT service is normally supported over the TCP and UDP protocols.
For NFSv4, only the TCP protocol is supported.
NFS v4 is designed for internet use. One unique network port is used on NFSv4. This predetermined port is fixed. The default is port 2049. Using NFS v4 through firewalls is easier than with earlier NFS versions.
2. Locking operation
NFS v3 protocol is stateless, so an additional Network Lock Manager (NLM) protocol, an auxiliary protocol for file locking, is required to support locking of NFS-mounted files READ/WRITE. Also NLM is stateful in that the server LOCKED keeps track of locks.
NFSv4 is stateful. Locking operations(open/read/write/lock/locku/close) are part of the protocol proper. NLM is not used by NFSv4.
3. Required Services
NFSv3 relies on Remote Procedure Calls (RPC) to encode and decode requests between clients and servers. NFSv3 depends on portmapper, rpc.mountd, rpc.lockd, rpc.statd.
NFSv4 has no interaction with portmapper, rpc.mountd, rpc.lockd, and rpc.statd, since protocol support has been incorporated into the v4 protocol. NFSv4 listens on “well-known” TCP port (2049) which eliminates the need for the portmapper interaction. The mounting and locking protocols have been incorpated into the V4 protocol which eliminates the need for interaction with rpc.mountd and rpc.lockd.
NFS v3 supports export/mount. Thus the host makes the mount request, not a user of the file system.
With NFSv4, the mandatory security mechanisms are oriented towards authenticating individual users, e.g. by configuring the Kerberos version 5 GSS-API or other security mechanism. Full Story