Eu tenho feito alguns testes elaborados para determinar se o nosso servidor NetApp NFS (protocolo v3) no modo async respeita adequadamente a solicitação fsync do cliente. Eu encontrei uma barreira quando descobri que o Linux (RHEL 6, kernel 2.6.32-431.5.1) nunca emite um COMMIT op !!! Esse fato foi descoberto pelo uso da ferramenta nfsstat e da ferramenta nfstrace . Não é um único COMMIT.
Isso parece violar a semântica do NFS :
Version 3 clients use COMMIT operations when flushing safe asynchronous writes to the server during a close(2) or fsync(2) system call, or when encountering memory pressure.
O que está acontecendo?
Notas:
O ponto de montagem é montado com a operação assíncrona (que é o padrão).
Para gerar solicitações fsync, usei a ferramenta test_fsync do Postgresql. Ele usa uma variedade de maneiras de emitir sincronizações e relatórios sobre os benchmarks para que você possa determinar qual é o melhor para você em seu sistema.
Diferenças de tempo com test_fsync indicam que a função fsync demora mais para executar em async montagens do que sync montagens, presumivelmente porque com sync montagens, os dados estão sendo liberados o tempo todo e é somente quando fsync é chamado de que os dados são liberados. No entanto, as diferenças de tempo são bastante erráticas e eu poderia estar encontrando transitoriedade de desempenho.
Montar o servidor com a opção sync não alterou nada.
UPDATE: O enredo engrossa.
No Ubuntu / Mint 17, kernel Linux 3.13.0, (nfs versão: 1.2.8), eu configurei um ponto de montagem de loopback, com opções de sincronização e assíncrono e executei novamente os testes. As diferenças de velocidade definitivamente mostram uma diferença entre sync e async. nfsstat mostra que, após cada execução de pg_fsync_test , exatamente 1 COMMIT ocorreu.
W.T.F.