5. Details of some handlers

This section give a bit of detail about interesting things that are done by some of the specific NFS request handlers in vfs.c.

5.1 Read and read ahead

The VFS layer in the kernel montiors whether a file is being used for sequential access or random access, and as a pattern of sequential access is noticed, it does more and more read-ahead to improve performance. For NFS accessed to benefit from this read-ahead, the VFS layer must be able to detect sequential reads.

However, because NFS has no "open" request, and effectively performs open/read/close for each read request, VFS needs a bit of help to notice continuity of accesses.

The VFS layer stores the access pattern information in the file structure. knfsd helps by recording the (5) various numbers after a read request, and restoring them before the next read request on the same file (dev/ino pair). To do this is keeps a cache of read ahead values for recently accessed files. Currently this cache is implemented as a simple linked list which recently accessed entries moved to the top. This size of the list is limited to twice the number of knfsd threads. It would be interesting to be able to measure the normal number of files which are concurrently being read on a given fileserver. This would allow the cache size to be turned.

5.2 lookup and mountpoints

Unpatched

When nfsd_lookup calls lookup_dentry to perform a filesystem lookup, it is possible that the lookup will cross a mountpoint and the returned dentry will be on a different filesystem.

The current implementation of nfsd_lookup checks for this case and steps back to the underlying (covered) dentry, so that lookups always stay on the same filesystem. Note that unless CONFIG_NFSD_SUN was used in compiling the code, the file handle so obtained will be rejected on all future accesses with a permission error.

Patched

When nfsd_lookup calls lookup_dentry to perform a filesystem lookup, it is possible that the lookup will cross a mountpoint and the returned dentry will be on a different filesystem.

If this happens, then knfsd will check to see if that filesystem has been exported to the client and, in particular, whether it has been exported with the NFSEXP_CROSSMNT option. If it has been exported with this option, then a file handle for the mounted directory is returned. If it is not exported, or does not have the option, then knfsd returns a file handle for the underlying (coverred) directory. Note that unless CONFIG_NFSD_SUN was used in compiling the code, the file handle for the underlying directory will be rejected on all future accesses with a permission error.

This crossing of mount points with LOOKUP is not well supported by all clients, for (at least) two reasons:

• The files in the underlying file system may present fileids (also known as inode numbers) which are the same as fileids in the parent filesystem. If the client depends on the uniqueness of these fileids (without also taking the fsid into account) then it could get confused.
• STATFS will return different values for different filehandles in, what appears to the client to by, the one filesystem. If this does not confuse the client, it may well confuse the users on the client system.

Despite these problems, some clients do cope well with mount point crossing, and some system administrators find it useful, so the functionality is provided for those who want it.