Por que escrever um arquivo em um compartilhamento NFS envia uma operação COMMIT para o servidor NFS?

Question

Eu tenho um squeeze no Debian (2.6.32-5-amd64) que é ao mesmo tempo um servidor e cliente NFS4 (ele se monta através do NFS4). O diretório local que leva diretamente ao disco é /nfs4exports/mydir , enquanto /nfs4mounts/mydir é a mesma coisa montada através do NFS, usando o endereço IP externo da máquina. Aqui está a linha de fstab :

192.168.1.75:/mydir   /nfs4mounts/mydir      nfs4    soft  0 0

Eu tenho um aplicativo que grava muitos arquivos pequenos. Se eu escrevo diretamente para /nfs4exports/mydir , ele grava milhares de arquivos por segundo; mas se eu escrever em /nfs4mounts/mydir , ele grava 4 arquivos por segundo ou mais. Eu posso aumentar muito a velocidade se eu adicionar async a /etc/exports . (Escrever um único arquivo grande no diretório montado pelo NFS ultrapassa 100 MB / s).

Eu examino as estatísticas do servidor e vejo que sempre que um arquivo é gravado, ele é "confirmado" (isso também acontece com o NFSv3):

root@debianvboxtest:~# mount -t nfs4 192.168.1.75:/mydir /mnt
root@debianvboxtest:~# nfsstat|grep -A 2 'nfs v4 operations'
Server nfs v4 operations:
op0-unused   op1-unused   op2-future   access       close        commit       
0         0% 0         0% 0         0% 10        4% 1         0% 1         0% 
root@debianvboxtest:~# echo 'hello' >/mnt/test1056
root@debianvboxtest:~# nfsstat|grep -A 2 'nfs v4 operations'
Server nfs v4 operations:
op0-unused   op1-unused   op2-future   access       close        commit       
0         0% 0         0% 0         0% 11        4% 2         0% 2         0% 

Agora, na RFC , eu li isto:

The COMMIT operation is similar in operation and semantics to the POSIX fsync(2) system call that synchronizes a file's state with the disk (file data and metadata is flushed to disk or stable storage). COMMIT performs the same operation for a client, flushing any unsynchronized data and metadata on the server to the server's disk or stable storage for the specified file.

Eu não entendo porque o cliente se compromete. Eu não acho que o comando embutido do shell "echo" rode fsync ; Se echo escreveu em um arquivo local e, em seguida, a máquina foi encerrada, o arquivo pode ser perdido. Por outro lado, o cliente NFS parece estar enviando um COMMIT após a conclusão do echo . Por quê?

Estou relutante em usar a async opção do servidor NFS , porque aparentemente ignorar COMMIT. Eu sinto como se eu tivesse um sistema de arquivos local e eu tivesse que escolher entre sincronizar todos os arquivos ao fechar e ignorar fsync ao mesmo tempo. O que eu entendi errado?

    

Answer 1

porque é assim que o NFS funciona, e é exatamente como deve funcionar, já que é um protocolo síncrono. O que você precisa ter certeza é que o sistema de arquivos que é exportado é apoiado por LUNs que possuem proteção NVRAM / BBWC e manipulam corretamente o fsync () - isto é, ignore isso e mascare os sinalizadores SCSI FUA e SCSI_CACHE_SYNCHRONIZE. Além disso, certifique-se de que o sistema de arquivos não tenha barreiras ativadas se ele for apoiado por BBWC / NVRAM.

Desta forma, o NFS mantém sua semântica síncrona e é equivalente a executar o fsync () após cada gravação, mas você obtém o desempenho da execução de forma assíncrona.