This preview shows page 1. Sign up to view the full content.
Unformatted text preview: ip-illustrated/nfs_netw.htm (16 of 23) [12/09/2001 14.47.56] Chapter 29. NFS: Network File System 5
0.2100) sun.7ad4 > bsdi.nfs: 104 getattr
( bsdi.nfs > sun.7ad4: reply ok 96
sun.7ad5 > bsdi.nfs: 112 lookup
bsdi.nfs > sun.7ad5: reply ok 28
sun.7ad6 > bsdi.nfs: 144 mkdir "Mail"
bsdi.nfs > aun.7ad6: reply ok 128 Figure 29.8 NFS operations for cd to NFS directory, then mkdir.
Changing our directory causes the client to call the GETATTR procedure twice (lines 14). When we create the new directory, the client calls the GETATTR procedure (lines 5
and 6), followed by a LOOKUP (lines 7 and 8, to verify that the directory doesn't already
exist), followed by a MKDIR to create the directory (lines 9 and 10). The reply of OK in
line 8 doesn't mean that the directory exists. It just means the procedure returned,
tcpdump doesn't interpret the return values from the NFS procedures. It normally prints
OK and the number of bytes of data in the reply.
One of the features of NFS (critics of NFS would call this a wart, not a feature) is that the
NFS server is stateless. "The server does not keep track of which clients are accessing
which files. Notice in the list of NFS procedures shown earlier that there is not an open
procedure or a close procedure. The LOOKUP procedure is similar to an open, but the
server never knows if the client is really going to reference the file after the client does a
The reason for a stateless design is to simplify the crash recovery of the server after it
crashes and reboots.
Example: Server Crash
In the following example we are reading a file from an NFS server when the server
crashes and reboots. This shows how the stateless server approach lets the client "not
know" that the server crashes. Other than a time pause while the server crashes and
View Full Document
- Spring '12