Solaris 10 : Migration from NFSv3 to NFSv4
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.
Migration From NFSv3 to NFSv4
Migrating a system from NFSv3 to NFSv4 is a five step process:
1. Listing the data to export
The first step is to list all data to be exported by NFSv3. Usually, there are several directories to be exported. In the example that follows, the following directories are used.
# showmount -e
Export list for jch-lnx:
2. Choosing the NFSv4 virtual root
To define the NFSv4 virtual root:
a) Create a NFSv4 root directory. Example: /exports/ .
b) Choose an existing directory which will be used as virtual root for. Example: /home/ .
In the following examples, /exports is used as the virtual root.
3. Data migration to the virtual root
Once we have a virtual root, we need to move data exported from the NFSv3 virtual root, as defined previously. There are two main possibilities:
A.Copy or move data from its path to the virtual root (recommended):
# mv /myshare /exports/myshare_v4
# mv /distros /exports/distros_v4
B.Move the data path sub tree to the virtual root (recommended):
# mkdir /exports/myshare_v4
# mount –-bind /myshare /exports/myshare_v4/
# mkdir /exports/distros_v4/
# mount –-bind /distros /exports/distros_v4/
4. Modifying export options
The goal is to convert the NFSv3 export options into NFSv4 ones. Most of the NFSv3 and NFSv4 options are the same (though NFSv4 requires an additional option to exportfs to provide the virtual root).
1)Virtual root export
#exportfs -ofsid=0,insecure,no_subtree_check *:/exports
2) Exporting subdirectories of the virtual root
# exportfs -orw,nohide,insecure,no_subtree_check *:/exports/myshare_v4
# exportfs -orw,nohide,insecure,no_subtree_check *:/exports/distros_v4
With the previous configuration and examples, the following commands would be used:
# mkdir /mnt/nfs_v4_root
# mount -t nfs4 10.182.121.238:/ /mnt/nfs_v4_root
# echo $?