Managing NFS and NIS, 2nd Edition - Mike Eisler [82]
Client A
Client B
cd /mnt/test
cd /mnt
rm -rf test
stat(.)-->Stale file handle
If one client removes a file and then creates a new file that re-uses the freed inode, other filehandles (on other clients) that point to the re-used inode must be marked stale. Inode generation numbers were added to the basic Unix filesystem to add a time history to an inode. In addition to the inode number, the filehandle must match the current generation number of the inode, or it is marked stale. When the inode is re-used for a new file, its generation number is incremented. Stale filehandles become a problem when one user's work tramples on an area in use by another, or when a filesystem on a server is rebuilt from a backup tape. When restoring from a dump tape onto a fresh filesystem, all of the inode generation numbers in the filesystem are set to random numbers. This causes every filehandle in use for that filesystem to become stale — every inode pointed to by a pre-restore filehandle now probably points to a completely different file on the disk.
Therefore, a quick way to cripple an NFS network is to restore a fileserver from a dump tape without rebooting the NFS clients. When you rebuild the server's filesystems, all of the inode generation numbers are reset; when you load the tape, files end up with different inode numbers and different inode generation numbers than they had on the original filesystem. All NFS client filehandles are now invalid because of the new generation numbers and the (random) renumbering of each file's inode. Any attempt to use an open filehandle results in stale filehandle errors. If you are going to restore an NFS-exported filesystem from tape, unmount it from its clients or reboot the clients.
NFS Version 3
There are four versions of the NFS protocol: Versions 2, 3, and 4. Version 1 did exist, but it was only a prototype, and neither an implementation nor specification was ever released. Version 4 has been specified, but at the time this book was written, there were no commercial implementatons. Version 3 has three major differences from Version 2:
Large file support
Version 2 supported files up to four gigabytes in length, though most implementations are limited to up to two-gigabyte files. Version 3 supports files up to and including 264 - 1 bytes in length. Large file support was the primary driver for a protocol revision.
Writes to unstable storage
Version 2 of the NFS protocol specified that NFS servers could not reply successfully to a write request until the data had been committed to stable storage, usually magnetic disk, but non-volatile RAM was permissible as well. This limited the write throughput of NFS clients, and so Version 3 of the protocol permits the client to indicate that the write need not be committed to stable storage. This allows NFS servers to respond quickly to write requests. Of course, clients are still interested in committing their data to stable storage, and so Version 3 has a new procedure called commit, which tells the NFS server to write the uncommitted data to stable storage before returning success.
The theory behind this, supported by experimental measurement, is that faster throughput is gained by the NFS server committing data to stable storage in parallel with the client doing something else (such as generating more NFS requests), before the client issues the commit. Typically, the NFS Version 3 client will issue a commit when it is about to close a file, or when buffer space is tight.
Large transfer sizes
NFS Version