Possível implementar o registro no diário com um único fsync por cometer?

Question

Vamos dizer que você está construindo um diário/write-ahead logging do sistema de armazenamento.Você pode simplesmente implementar isso (para cada operação) acrescentando os dados (com escrita(2)), acrescentando um commit marcador e, em seguida, fsync-ing?

O cenário a considerar é se você fizer um grande conjunto de gravações para este registo, em seguida, fsync, e há uma falha durante o fsync.São inode direta/indireta do bloco de ponteiros liberados somente depois que todos os blocos de dados são liberados, ou que não há garantias de que os blocos estão sendo liberados em ordem?Se o último, em seguida, durante a recuperação, se você ver um commit marcador no final do arquivo, você não pode confiar que os dados entre ele e a submissão prévia do marcador é significativo.Assim, você tem que confiar em um outro mecanismo (envolvendo, pelo menos, mais fsync) para determinar qual a extensão do arquivo de log é consistente (por exemplo, escrever/fsyncing os dados e, em seguida, escrever/fsyncing a confirmação do marcador).

Se ele faz a diferença, principalmente se perguntando sobre o ext3/ext4, conforme o contexto.

Answer 1

Note que o linux e o mac os da fsync e fdatasync estão incorretos por padrão.O Windows é correto por padrão, mas pode emular linux para efeitos de benchmarking.

Também, fdatasync problemas de várias gravações de disco se você acrescentar ao final de um arquivo, desde que ele precisa para atualizar o arquivo inode com o novo comprimento.Se você quer ter uma gravação por confirmar, a sua melhor aposta é pré-alocar espaço de registo, armazenamento de um CRC de entradas de log do commit marcador, e emitir um único fdatasync() durante a consolidação.Dessa forma, não importa o quanto o SO / hardware reordenar por trás de suas costas, você pode encontrar um prefixo de log que, na verdade, hit do disco.

Se você deseja usar o log para duráveis compromete-se ou escrever à frente, as coisas ficam mais difíceis, já que você precisará certifique-se de que fsync realmente funciona.No Linux, você vai querer desabilitar o cache de gravação de disco com o hdparm, ou montar a partição com barreira definida como true.[Editar:Eu estou corrigido, barreira não parece dar a semântica correta.SATA e SCSI introduzir um número de primitivas, como a gravação de barreiras e de comando nativo de enfileiramento de mensagens, o que torna possível para sistemas operacionais de exportação de primitivas que permitem write-ahead log.O que posso dizer a partir de páginas do manual e online, o Linux só expõe essas sistema de arquivos para programadores, não para o userspace.]

Paradoxalmente, desativar o cache de gravação em disco, por vezes, leva a um melhor desempenho, uma vez que você obter maior controle sobre escrever o agendamento no espaço do usuário;se o disco filas de um monte de solicitações de gravação síncrona, você acaba expondo estranho picos de latência para a aplicação.Desabilitando o cache de gravação evita que isto aconteça.

Finalmente, os sistemas reais de uso confirmação de grupo, e fazer < 1 de sincronização de escrever por comprometer com cargas de trabalho simultâneas.

Answer 2

Não há garantia na ordem em que os blocos são liberados no disco. Hoje em dia, até a unidade em si pode reordenar blocos a caminho dos pratos.

Se você deseja aplicar pedidos, você precisa pelo menos fdatasync() Entre as gravações que você deseja encomendar. Tudo uma sincronia promete é que Quando ele retorna, tudo escrito antes da sincronização atingir o armazenamento.