/ etc / exports & mount option

Question

No meu servidor Linux, tenho as seguintes opções em / etc / exports

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

E eu montei de um Mac usando

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

Como você pode ver, o servidor está especificando o sync , mas a minha opção de montagem está usando async , então qual deles será usado?

    

Answer 1

sync e async têm significados diferentes para as duas situações diferentes.

sync no contexto do cliente faz com que todas as gravações no arquivo sejam confirmadas no servidor. async faz com que todas as gravações no arquivo sejam não transmitidas ao servidor imediatamente, geralmente apenas quando o arquivo é fechado. Então, outro host abrindo o mesmo arquivo não verá as alterações feitas pelo primeiro host.

Observe que o NFS oferece consistência "quase aberta", o que significa que outros clientes não podem assumir que os dados em um arquivo aberto por outros são consistentes (ou, francamente, consistentes se você não use nfslock para adicionar alguma forma de sincronização entre clientes).

sync no contexto do servidor (o padrão) faz com que o servidor responda apenas para dizer que os dados foram gravados quando o back-end de armazenamento realmente os informa que os dados foram gravados. async no contexto do servidor faz com que o servidor simplesmente responda como se o arquivo tivesse sido escrito no servidor, independentemente de ter sido escrito ou não. Isso é muito mais rápido, mas também muito perigoso, pois os dados podem ter um problema sendo cometido!

Na maioria dos casos, async no lado do cliente e sync no lado do servidor. Isso oferece um comportamento bastante consistente em relação a como o NFS deve funcionar.

    

Answer 2

Basicamente o que o MIfe disse; essas opções são sensíveis ao contexto. A parte importante está nas 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).

e no cliente (Mac):

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.

Observação: em um Mac, mount_nfs(8) afirma que a opção async só será honrada se a opção nfs.client.allow_async em nfs.conf(5) também estiver ativada (também pode ser definida via sysctl(8) )

Assim, você pode solicitar async no cliente e as solicitações de gravação apenas assumirão que chegaram ao servidor. Como você especificou sync no servidor, ele atenderá aos pedidos do cliente quando os dados tiverem sido gravados no disco. (Naturalmente, seus sistemas de arquivos locais no servidor também podem ser montados com "sync", embora "async" pareça ser o padrão)

Uma palavra sobre suas opções de montagem no cliente: * rsize & wsize são definidos como 32768 por padrão para montagens TCP. * proto = tcp é o padrão, fará fallback para udp se não for suportado pelo servidor * vers = 3 é o padrão, vai para 2 se não for suportado pelo servidor