sincronizar (Unix) - sync (Unix)
sync é uma chamada de sistema padrão no sistema operacional Unix , que compromete todos os dados no sistema de arquivos do kernel para buffers de armazenamento não voláteis , ou seja, dados que foram programados para gravação por meio de chamadas de sistema de E / S de baixo nível . Camadas de E / S de nível superior, como stdio, podem manter seus próprios buffers separados.
Como uma função em C , a sync() chamada é geralmente declarada como void sync(void) em <unistd.h> . A chamada do sistema também está disponível por meio de um utilitário de linha de comando também chamado sync e funções com nomes semelhantes em outras linguagens, como Perl e Node.js (no módulo fs).
A chamada de sistema relacionada fsync() confirma apenas os dados armazenados em buffer relativos a um descritor de arquivo especificado . fdatasync() também está disponível para gravar apenas as alterações feitas nos dados do arquivo, e não necessariamente os metadados relacionados ao arquivo.
Alguns sistemas Unix executam um tipo de daemon de descarga ou atualização , que chama a função de sincronização regularmente. Em alguns sistemas, o cron daemon faz isso, e no Linux ele foi tratado pelo daemon pdflush, que foi substituído por uma nova implementação e finalmente removido do kernel do Linux em 2012. Buffers também são liberados quando os sistemas de arquivos são desmontados ou remontados somente para leitura , por exemplo, antes do desligamento do sistema.
Uso de banco de dados
Para fornecer durabilidade adequada , os bancos de dados precisam usar alguma forma de sincronização para garantir que as informações gravadas tenham chegado a um armazenamento não volátil, em vez de apenas sendo armazenadas em um cache de gravação baseado em memória que seria perdido se faltasse energia . O PostgreSQL, por exemplo, pode usar uma variedade de chamadas de sincronização diferentes, incluindo fsync() e fdatasync() , para que os commits sejam duráveis. Infelizmente, para qualquer cliente que grava uma série de registros, um disco rígido rotativo só pode ser confirmado uma vez por rotação, o que representa, no máximo, algumas centenas de confirmações por segundo. Desativar o requisito fsync pode, portanto, melhorar muito o desempenho de commit, mas às custas de potencialmente introduzir corrupção de banco de dados após um travamento.
Os bancos de dados também empregam arquivos de log de transações (normalmente muito menores do que os arquivos de dados principais) que contêm informações sobre alterações recentes, de modo que as alterações podem ser refeitas de forma confiável em caso de falha; então, os arquivos de dados principais podem ser sincronizados com menos frequência.
Relatório e verificação de erros
Para evitar qualquer perda de dados, os valores de retorno de fsync() devem ser verificados porque ao executar operações de E / S que são armazenadas em buffer pela biblioteca ou kernel, os erros podem não ser relatados no momento de usar a write() chamada do sistema ou a fflush() chamada, uma vez que os dados não podem ser gravado no armazenamento não volátil, mas somente no cache de página da memória . Em vez disso, erros de gravações são frequentemente relatados durante chamadas de sistema para fsync() , msync() ou close() . Antes de 2018, o fsync() comportamento do Linux em certas circunstâncias não relatava o status de erro. A mudança de comportamento foi proposta em 23 de abril de 2018.
Controvérsias de desempenho
Os discos rígidos podem usar como padrão seu próprio cache de gravação volátil para gravar gravações em buffer, o que melhora muito o desempenho enquanto apresenta um potencial para gravações perdidas. Ferramentas como hdparm -F instruirão o controlador de HDD a liberar o buffer do cache de gravação na unidade. O impacto no desempenho de desligar o cache é tão grande que mesmo a comunidade normalmente conservadora do FreeBSD rejeitou desabilitar o cache de gravação por padrão no FreeBSD 4.3.
Em SCSI e em SATA com Native Command Queuing (mas não em ATA simples, mesmo com TCQ), o host pode especificar se deseja ser notificado da conclusão quando os dados chegarem aos pratos do disco ou quando chegarem ao buffer do disco (integrado cache). Presumindo uma implementação de hardware correta, esse recurso permite que o cache on-board do disco seja usado, garantindo a semântica correta para chamadas de sistema como fsync . Esse recurso de hardware é chamado de Force Unit Access (FUA) e permite consistência com menos sobrecarga do que limpar o cache inteiro como feito para discos ATA (ou SATA não NCQ). Embora o Linux habilitasse o NCQ por volta de 2007, ele não habilitou o SATA / NCQ FUA até 2012, citando a falta de suporte nas primeiras unidades.
O Firefox 3.0, lançado em 2008, introduziu fsync chamadas de sistema que degradaram seu desempenho; a chamada foi introduzida para garantir a integridade do banco de dados SQLite embutido .
O diretor técnico da Linux Foundation , Theodore Ts'o, afirma que não há necessidade de "temer o fsync" e que a verdadeira causa da lentidão do Firefox 3 é o uso excessivo de fsync . Ele também admite, no entanto (citando Mike Shaver ) que "Em algumas configurações bastante comuns do Linux, especialmente usando o sistema de arquivos ext3 no modo“ data = ordenado ”, chamar fsync não apenas esvazia os dados do arquivo em que é chamado, mas em vez de todos os dados armazenados em buffer para esse sistema de arquivos. "
