+.IR ro " option.
+.TP
+.IR async
+This option allows the NFS server to violate the NFS protocol and
+reply to requests before any changes made by that request have been
+committed to stable storage (e.g. disc drive).
+
+Using this option usually improves performance, but at the cost that
+an unclean server restart (i.e. a crash) can cause data to be lost or
+corrupted.
+
+.TP
+.IR sync
+Reply to requests only after the changes have been committed to stable
+storage (see
+.IR async
+above).
+
+In releases of nfs-utils upto and including 1.0.0, this option was the
+default. In this and future releases,
+.I sync
+is the default, and
+.I async
+must be explicit requested if needed.
+To help make system adminstrators aware of this change, 'exportfs'
+will issue a warning if neither
+.I sync
+nor
+.I async
+is specified.
+.TP
+.IR no_wdelay
+This option has no effect if
+.I async
+is also set. The NFS server will normally delay committing a write request
+to disc slightly if it suspects that another related write request may be in
+progress or may arrive soon. This allows multiple write requests to
+be committed to disc with the one operation which can improve
+performance. If an NFS server received mainly small unrelated
+requests, this behaviour could actually reduce performance, so
+.IR no_wdelay
+is available to turn it off.
+The default can be explicitly requested with the
+.IR wdelay " option.
+.TP
+.IR nohide
+This option is based on the option of the same name provided in IRIX
+NFS. Normally, if a server exports two filesystems one of which is
+mounted on the other, then the client will have to mount both
+filesystems explicitly to get access to them. If it just mounts the
+parent, it will see an empty directory at the place where the other
+filesystem is mounted. That filesystem is "hidden".
+
+Setting the
+.I nohide
+option on a filesystem causes it not to be hidden, and an
+appropriately authorised client will be able to move from the parent to
+that filesystem without noticing the change.
+
+However, some NFS clients do not cope well with this situation as, for
+instance, it is then possible for two files in the one apparent
+filesystem to have the same inode number.
+
+The
+.I nohide
+option is currently only effective on
+.I "single host
+exports. It does not work reliably with netgroup, subnet, or wildcard
+exports.
+
+This option can be very useful in some situations, but it should be
+used with due care, and only after confirming that the client system
+copes with the situation effectively.
+
+The option can be explicitly disabled with
+.IR hide .
+.TP
+.IR crossmnt
+This option is similar to
+.I nohide
+but it makes it possible for clients to move from the filesystem marked
+with crossmnt to exported filesystems mounted on it. Thus when a child
+filesystem "B" is mounted on a parent "A", setting crossmnt on "A" has
+the same effect as setting "nohide" on B.
+.TP
+.IR no_subtree_check
+This option disables subtree checking, which has mild security
+implications, but can improve reliability in some circumstances.
+
+If a subdirectory of a filesystem is exported, but the whole
+filesystem isn't then whenever a NFS request arrives, the server must
+check not only that the accessed file is in the appropriate filesystem
+(which is easy) but also that it is in the exported tree (which is
+harder). This check is called the
+.IR subtree_check .
+
+In order to perform this check, the server must include some
+information about the location of the file in the "filehandle" that is
+given to the client. This can cause problems with accessing files that
+are renamed while a client has them open (though in many simple cases
+it will still work).
+
+subtree checking is also used to make sure that files inside
+directories to which only root has access can only be accessed if the
+filesystem is exported with
+.I no_root_squash
+(see below), even if the file itself allows more general access.
+
+As a general guide, a home directory filesystem, which is normally
+exported at the root and may see lots of file renames, should be
+exported with subtree checking disabled. A filesystem which is mostly
+readonly, and at least doesn't see many file renames (e.g. /usr or
+/var) and for which subdirectories may be exported, should probably be
+exported with subtree checks enabled.
+
+The default of having subtree checks enabled, can be explicitly
+requested with
+.IR subtree_check .
+