Managing NFS and NIS, 2nd Edition - Mike Eisler [233]
Excerpt from: snoop -i /tmp/capture -p 9,10 -v
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 10 arrived at 20:45:9.74
...
NFS: ----- Sun NFS -----
NFS:
NFS: Proc = 16 (Read from directory)
NFS: Status = 0 (OK)
NFS: File id Cookie Name
NFS: 137 50171 .
NFS: 95 50496 ..
NFS: 199 51032 data1
NFS: 201 51706 data2
NFS: 4 entries
NFS: EOF = 1
NFS:
The directory contents are cached by tarsus, so that they may be reused in a future directory listing. The NFS Lookup and NFS Getattr requests, along with their corresponding replies in packets 11 thru 18, result from the long listing of the directory requested by ls -l. An NFS Lookup obtains the filehandle of a directory component. The NFS Getattr requests the file attributes of the file identified by the previously obtained filehandle.
NFS Version 2 filehandles are 32 bytes long. Instead of displaying a long and cryptic 32-byte number, snoop generates a shorthand version of the filehandle and displays it when invoked in summary mode. This helps you associate filehandles with file objects more easily. You can obtain the exact filehandle by displaying the network packet in verbose mode by using the -v option. The packet 7 filehandle FH=FA14 is really:
Excerpt from: snoop -i /tmp/capture -p 7 -v
NFS: ----- Sun NFS -----
NFS:
NFS: Proc = 1 (Get file attributes)
NFS: File handle = [FA14]
NFS: 0204564F4C32000000000000000000000000A10000001C4DFF20A00000000000
Next, protium, a different NFS client comes into the picture, and removes one file from the directory previously cached by tarsus:
[1] protium $ rm /net/inchun/export/folder/data2
22 0.00000 protium -> inchun NFS C GETATTR2 FH=FA14
23 0.00000 inchun -> protium NFS R GETATTR2 OK
24 0.00000 protium -> inchun NFS C REMOVE2 FH=FA14 data2
25 0.00182 inchun -> protium NFS R REMOVE2 OK
Packets 22 and 23 update the cached attributes of the /net/inchun/export/folder directory on protium. Packet 24 contains the actual NFS Remove request sent to inchun, which in turn acknowledges the successful removal of the file in packet 25.
tarsus then lists the directory in question, but fails to detect that the contents of the directory have changed:
[2] tarsus $ ls /net/inchun/export/folder
data1 data2
39 0.00000 tarsus -> inchun NFS C GETATTR2 FH=FA14
40 0.00101 inchun -> tarsus NFS R GETATTR2 OK
This is where the problem begins. Notice that two NFS Getattr network packets are generated as a result of the directory listing but no Readdir request. In this case, the client issues the NFS Getattr operation to request the directory's modification time:
Excerpt from: snoop -i /tmp/capture -p 39,40 -v
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 40 arrived at 20:45:10.88
...
NFS: ----- Sun NFS -----
NFS:
NFS: Proc = 1 (Get file attributes)
NFS: Status = 0 (OK)
NFS: File type = 2 (Directory)
NFS: Mode = 040777
NFS: Type = Directory
NFS: Setuid = 0, Setgid = 0, Sticky = 0
NFS: Owner's permissions = rwx
NFS: Group's permissions = rwx
NFS: Other's permissions = rwx
NFS: Link count = 2, UID = 0, GID = -2, Rdev = 0x0
NFS: File size = 512, Block size = 512, No. of blocks = 1
NFS: File system id = 7111, File id = 161
NFS: Access time = 11-Apr-00 12:50:18.000000 GMT
NFS: Modification time = 11-Apr-00 12:50:18.000000 GMT
NFS: Inode change time = 31-Jul-96 09:40:56.000000 GMT
The modification time of the directory is the same as the modification time before the removal of the file! tarsus compares the cached modification time of the directory with the modification time just obtained from the server, and determines that the cached directory contents are still valid since the modification times are the same. The directory listing is therefore satisfied from the cache instead of forcing the NFS client to read the updated directory contents from the server. This explains why the removed file continues to show up in the directory listing:
[3] tarsus $ ls -l /net/inchun/export/folder