Home / server / Questions / 499174
In Process
Ryan
Asked: 2013-04-15 00:06:50 +0800 CST

/etc/exports & mount option

  • 772

In my Linux server I have the following options in /etc/exports 

/home *(rw,sync,no_subtree_check,no_root_squash)

And I mount from a Mac using

mount -t nfs -o resvport,rw,noatime,soft,intr,rsize=32768,wsize=32768,timeo=900,retrans=3,proto=tcp,vers=3,async 192.168.1.121:/home /Volumes/home

As you can see the server is specifying the sync but my mount option is using async, so which one will be used?

network-share

2 Answers

  1. sync and async have different meanings for the two different situations.

    sync in the client context makes all writes to the file be committed to the server. async causes all writes to the file to not be transmitted to the server immediately, usually only when the file is closed. So another host opening the same file is not going to see the changes made by the first host.

    Note that NFS offers "close to open" consistency meaning other clients cannot anyway assume that data in a file open by others is consistent (or frankly, that it is consistent at all if you do not use nfslock to add some form of synchronization between clients).

    sync in the server context (the default) causes the server to only reply to say the data was written when the storage backend actually informs it the data was written. async in the server context gets the server to merely respond as if the file was written on the server irrespective of if it actually has written it. This is a lot faster but also very dangerous as data may have a problem being committed!

    In most cases, async on the client side and sync on the server side. This offers a pretty consistent behaviour with regards to how NFS is supposed to work.

    • 20

  2. Basically what MIfe said; these options are context sensitive. The important part are in the manpages:

    exports(5)
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).

    and on the (Mac) client:

    mount_nfs(8)
async   Assume that unstable write requests have actually been committed to stable
        storage on the server, and thus will not require resending in the event
        that the server crashes.

    Note: on a Mac, mount_nfs(8) states that the async option will only be honored if the nfs.client.allow_async option in nfs.conf(5) is also enabled (can also be set via sysctl(8))

    So, you can request async on the client and write requests will just assume they've reached ther server. Since you specified sync on the server, it will fulfill requests from the client when the data has been actually written to disk. (Of course, your local filesystems on the server can also be mounted with "sync", though "async" seems to be the default)

    A word on your mount options on the client: * rsize & wsize are set to 32768 by default for TCP mounts. * proto=tcp is the default, will fallback to udp if not supported by the server * vers=3 is the default, will fallback to 2 if not supported by the server

    • 1