Quais sistemas de arquivos requerem fsync () para segurança de travamento ao substituir um arquivo existente por rename ()?

Question

Após reclamações generalizadas, o ext4 ganhou uma garantia de segurança contra falhas chamada auto_da_alloc , que é ativada por padrão. E quanto a outros sistemas de arquivos? Dos sistemas de arquivos mais conhecidos, qual deles oferece essa mesma garantia (e quais deles não)?

Pessoalmente, estou interessado em ouvir informações sobre

• XFS - Sistema de arquivos padrão do Red Hat Enterprise Linux.
• btrfs - Sistema de arquivos padrão do SuSE Enterprise.
• bcachefs - sistema de arquivos Linux fora da árvore, derivado do bcache. "O sistema de arquivos COW para Linux que não vai comer seus dados."

Esta questão diz respeito principalmente ao Linux, conforme a história abaixo. Seria interessante saber como o ZFS se comporta também, mas tenho a tendência de assumir que isso não seria implementado.

O que é auto_da_alloc ?

fsync () é bem documentado como a maneira correta de gravar dados de arquivos, por exemplo. quando você apertar "salvar" em um editor de texto. E é amplamente entendido que, e. editores de texto devem substituir arquivos existentes atomicamente usando rename (). Isso serve para proteger contra a perda de energia, certificando-se de que você sempre mantenha o arquivo antigo ou obtenha o novo arquivo (que foi fsync () ed antes da renomeação). Você não quer ficar com apenas uma versão parcialmente escrita do novo arquivo.

Mas houve um problema que chamar o fsync () no ext3, que era o sistema de arquivos Linux mais popular, poderia efetivamente deixar o sistema inteiro pendurado por dezenas de segundos. Como os aplicativos não podem fazer nada sobre isso, era muito comum usar de maneira otimista renomear () sem fsync (). Esse padrão pareceu funcionar muito bem nesse sistema de arquivos, mesmo se o sistema perdesse energia.

Portanto, existem aplicativos que não usam fsync () corretamente.

A próxima versão do sistema de arquivos, ext4, geralmente evita o travamento do fsync (). Ao mesmo tempo, começou a confiar muito mais no uso correto do fsync ().

Isso tudo é muito ruim. Entender essa história não pode ser ajudado por frases de desprezo usadas por muitos dos desenvolvedores de kernel em conflito.

Isso foi resolvido no ext4, para suportar o padrão rename () sem exigir que o fsync () para segurança de travamento fornecesse o comportamento em um travamento como o antigo sistema de arquivos ext3. Esse comportamento pode ser desativado novamente se você montar com a opção noauto_da_alloc .

    

Answer 1

Há um erro nesta questão. A questão implicava que este cenário fosse totalmente <-em-safe sem falhas por auto_da_alloc . Isso não é verdade para o ext4. Eu presumo que não seja verdade no antigo ext3 também. No entanto, é verdadeiro para btrfs e para bcachefs.

Recent ext4 does have a special workaround to reduce the chance of replace-via- rename producing zero-length files by forcing out the new data blocks upon rename . However, rename does not wait for this flush to complete, and therefore provides no atomicity guarantee—it is possible to end up with only partial new content after a crash. Of the file systems we tested, btrfs is the only one that provides the replace-via-rename atomicity guarantee.

link

btrfs documentação diz renomear () no btrfs fornece total atomicidade, e não precisa de um fsync () explícito para proteger os dados contra falhas. Acho que foi adicionado quase ao mesmo tempo que ext4 auto_da_alloc . Também vemos uma afirmação de que a implementação do btrfs evita a degradação do desempenho, pois não faz com que a chamada rename () espere.

bcachefs atualmente parece fornecer o nível total de proteção, embora eu não tenha encontrado nenhuma documentação. Verifique o código no link

XFS rejeitou adicionando soluções alternativas de segurança contra falhas para renomear (). Ele aparentemente ganhou código que reduz (mas não remove) o risco de perda de dados em um caso diferente.

UBIFS (usado, por exemplo, em muitos dispositivos Openwrt) não inclui nenhuma solução alternativa de segurança contra falhas para renomear (). Poderia ser aceito, mas exigiria muito trabalho. link