Introducing Network File System Version 4 on HP-UX 11i v3 Abstract ........................................................................................................................................ 2 New features of NFSv4 ................................................................................................................... 2 NFSv4 changes..............................................................................................................................
Abstract Beginning with HP-UX 11i v3, HP offers Network File System Version 4 (NFSv4). NFSv4 offers better interoperability with Microsoft® Windows®, improved security, and improved performance. This paper describes the NFSv4 features available in the initial and subsequent fusion releases of HP-UX 11i v3 and what an HP-UX system administrator needs to know to use NFSv4 clients and servers. New features of NFSv4 The new NFSv4 features offered in HP-UX 11i v3 are: • NFSv4 introduces state.
Figure 1. COMPOUND RPC request Figure 1 is an example of an Ethereal trace generated by mounting a file system over NFSv4. Lines 1 and 2 denote that this is an NFS trace and that the protocol version is 4. Line 3 shows which NFSv4 RPC the client is making. Because the only other NFSv4 RPC is the NULL RPC, in almost all cases, the NFSv4 RPC will be the COMPOUND procedure. Lines 4 to 8 provide header information that describes the RPC. For example, line 4 is a tag describing this as a mount request.
Figure 2. COMPOUND RPC reply Figure 2 displays the server’s reply to the COMPOUND RPC in Figure 1. Unless an error occurs, each opcode has its own return status and its own return values. For example, the result of the PUTROOTFH opcode (lines 9 and 10) is the return status “NFS4_OK”, indicating the operation succeeded without error. The results of the GETATTR opcode include the status (NFS4_OK on line 22) and the values of the different attributes requested by the GETATTR opcode.
No mount or locking protocols In Figure 1, there are no mount protocol messages; mounting is handled by the PUTROOTFH opcode, which is part of NFSv4. Similarly, there is no separate file locking protocol. Locking is handled by the NFSv4 opcodes LOCK, LOCKU, and LOCKT. These opcodes are discussed in the “File Locking as part of the NFSv4 protocol” section. NFSv4 as a stateful protocol Previous NFS protocols were stateless in the sense that the NFS server maintained no information or state about its clients.
Figure 4. SETCLIENTID opcode reply The client identifier assigned by the server to this client appears on line 11 in Figure 4. Because NFSv4 is a stateful protocol, some opcodes require the client to identify itself by passing its client identifier to the server. For example, because file locks are associated with a client (and therefore a client identifier), the locking opcodes, LOCK, LOCKU, and LOCKT, all require the client to send its client identifier as part of the operation.
Figure 5. nfsstat NFSv4 output The output displays not just the NFSv4 procedures, NULL and COMPOUND, but also all opcodes that can be sent as part of a COMPOUND procedure. The opcodes listed include GETFH (line 8), PUTROOTFH (line 18), and SETCLIENTID (line 24). These opcodes were used in the initial mount request seen in Figure 1 and in identifying the client as seen in Figure 3. See the RFC for details on SETCLIENTID_CONFIRM.
Figure 6. OPEN opcode request On line 12, the OPEN opcode appears. A parameter of the OPEN opcode is the client identifier (line 16). As previously mentioned, the client identifier is required to identify the client performing the open. Note how the client identifier on line 16 matches the identifier that was returned to the client as part of the SETCLIENTID opcode in Figure 4, line 11. Note the share_access and share_deny fields in the OPEN opcode on lines 14 and 15.
Figure 7. OPEN opcode reply The reply from the server is shown in Figure 7. The state identifier on line 13 represents this client’s file open. It is returned by the server as part of the reply to the OPEN opcode. This identifier is used to associate state with this instance of this file open. Delegation Normally, an NFS server is responsible for managing file locks and file data across a network.
NOTE: ONCplus version B.11.31.03 (or later) will be included in the HP-UX 11i v3 Update 3 fusion release planned for September 2008. For example, if a directory, /dir, is being exported by a server, then no local processes on the server should be accessing files in /dir. With the introduction of the delegation stackable module in ONCplus B.11.31.03, this restriction is no longer applicable.
Figure 9. LOCK opcode reply The reply from the server is shown in Figure 9. Notice how the server returns to the client a state identifier (lines 17 through 19) that identifies this particular lock. Also, the client identifier is returned to the client (line 22) as well because the server maintains state about the client. In this case, the server is keeping state about this client’s specific locks.
Enabling NFSv4 mounts on your HP-UX 11i v3 server By default, NFSv4 mounts are disabled on HP-UX 11i v3 servers. If the server does not enable NFSv4 mounts, then attempting to mount generates the following error message. Figure 10. mount command fails To enable NFSv4 mounts, the NFS configuration file, /etc/default/nfs, must be modified on the server. This file contains various configuration variables for NFS clients, NFS servers, and lock manager.
Figure 12. Restarting NFSv4 server services By default, NFS clients and servers negotiate which protocol version to use. The client and server use the highest numbered protocol version that both the client and server support. For example, if the client supports NFSv2, NFSv3, and NFSv4 and the server supports only NFSv2 and NFSv3, then the client and server agree to use NFSv3. In this way, NFSv4 clients and servers work seamlessly with other clients and servers that do not support NFSv4.
Figure 13. GETATTR opcode reply Figure 13 contains the results of a GETATTR opcode request. The GETATTR opcode was sent as part of the close() system call. The results to the GETATTR opcode begins on line 11. The value of the file’s owner and group appear on lines19 through 26. In this case, the UID and GID are “user1@cup.hp.com“ and “users@cup.hp.com,” respectively.
example, to enable your HP-UX 11i v3 client to use NFSv2, NFSv3, or NFSv4, set the configuration variables NFS_CLIENT_VERSMIN and NFS_CLIENT_VERSMAX to 2 and 4, respectively. After the client has been restarted, NFSv4 mounts can be performed with a simple mount command: mount server:/server_mount /client_mountpoint If both the client and the server are configured to support NFSv4, then the remote file system is mounted using NFSv4.
Additional Features in HP-UX 11i v3 ONCplus B.11.31.03 HP-UX 11i v3 ONCplus release 11.31.03 provides support for the following additional NFSv4 features: • Cross Mounts • Referrals • Delegation Stackable Module for Local Access Cross Mounts The NFSv4 protocol allows clients to seamlessly traverse the server’s shared directories and cross the physical file system boundaries on the server without having to explicitly mount each shared file system independently.
Figure 16.
Figure 17. NFSv4 Server hpnfs161 In Figure 18, the ls command on directories “/mnt/a/b” and “/mnt/a/b/c/d” shows the contents of the exported file systems (hpnfs161:/a/b and hpnfs161:/a/b/c/d) respectively, illustrating the client is able to cross the server’s file system mount points without having to mount each shared file system separately.
Referrals The Cross Mounts feature allows an NFSv4 client to traverse the server’s shared directories and seamlessly cross the physical file system boundaries on the server. The Referrals feature allows an NFSv4 client to traverse shared directories and seamlessly cross the physical file systems located on different servers. In other words, a referral defines a way for the NFSv4 server to direct an NFSv4 client to a file system which resides on a different server.
Server Support for Referrals Server support for referrals is provided by the “refer” option of the share(1M) command. For example the following share command exports the “/mnt” file system, which is referring to the “/tmp” directory residing on the NFSv4 server whose IP address is 16.92.87.140. # share –o refer=/tmp@16.92.87.140 /mnt Syntax of share command # share –o refer=@ Note: 1.
Example of Referral Figure 20 and Figure 21 illustrate the Referral functionality. The figures use the following setup: • NFSv4 Server1: hpnfs161 (Referring Server): # share –o refer=/mntp@16.92.86.188 /a/b • NFSv4 Server2: hpnfs188 <16.92.86.188> (Referred-to Server): # share /mntp • NFSv4 Referral Client: hpnfs163 # mount –o vers=4 hpnfs161:/ /mnt # cd /mnt/a/b Figure 20.
Figure 21. NFSv4 Referral Client: hpnfs163 Figure 22 to Figure 24 show the network traces of the example of Figure 21. Figure 22 shows the network trace of the LOOKUP response from the server when Client is executing the “cd /mnt/a/b” command. Line 7 shows Server1 returning the error status NFS4ERR_MOVED in the LOOKUP response. Lines 23 to 42 show the trace of FS_LOCATION request sent by the client upon receiving the NFS4ERR_MOVED error.
Figure 22.
Figure 23 shows the network trace of the FS_LOCATION response from Server1. Lines 21 to 38 show the values in the fs_locations attribute. Figure 23. FS_LOCATION Response Figure 24 is the network trace of the client sending the mount request to Server2 after processing the FS_LOCATION response received from Server1. Note the destination address at line 2 is the IP address of Server2.
Figure 24.
Delegation Stackable Module for Local Access NFSv4 clients support delegation on HP-UX 11i v3. However, until the release of HP-UX 11i v3 ONCplus version B.11.31.03, NFSv4 servers support delegation with the caveat that no local file access should occur on any delegated file. For example, if the server grants a delegation to the file “/a/b/foo” then any local users on the server need to avoid accessing file “foo” while the delegation is in effect.
Figure 22. Example Setting Up Physical File system with nfs4deleg Stackable Module Figure 22 shows an example using the steps provided to create a mount with the stackable module. For convenience, once the physical file system is set up, the stackfs= mount option can be used in the /etc/fstab to mount the file system at boot time with the nfs4deleg module.
3. If the operation supports recalls and there is no delegation to revoke, pass the operation on to the physical file system 4. If there is a delegation that needs to be recalled, call the server function to recall the delegation 5. A callback is issued to the client where the client writes its data to server, updates the server state, and a DELEGRETURN will be issued. Local access is blocked on a delegated file until the delegation is returned or the lease times out.
Figure 24. NFSv4 OPEN opcode reply showing delegation granted Figure 25 shows a network trace of a successful reply of the DELEGRETURN opcode from the NFS server (Step 5 in Figure 23).
Figure 25.
Conclusion The Network File System (NFS) has existed in one version or another since 1985. NFSv4 marks a big departure from previous NFS protocol versions because it introduces state into the NFS protocol and folds ancillary mechanisms such as ACLs, file locking, and mounting, into the core protocol. In addition, NFSv4 improves Microsoft Windows interoperability with an enhanced attributes mechanism, share locks, ACL support, and stronger security.
For more information • http://www.hp.com/go/hpux11i • http://www.hp.com/go/integrity • http://www.ietf.org/rfc/rfc3530.txt © 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty.
