Após reclamações generalizadas, o ext4 ganhou uma garantia de segurança contra falhas chamada, auto_da_allocque é habilitada por padrão. E quanto a outros sistemas de arquivos? Dos sistemas de arquivos mais conhecidos, quais oferecem essa mesma garantia (e quais 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."
Esse problema diz respeito principalmente ao Linux, conforme o histórico abaixo. Seria interessante saber como o ZFS se comporta também, mas tendo a supor que ele não implementaria isso.
O que é auto_da_alloc?
fsync() está bem documentado como a maneira correta de escrever dados de arquivos, por exemplo, quando você clica em "salvar" em um editor de texto. E é amplamente entendido que, por exemplo, os editores de texto devem substituir os arquivos existentes atomicamente usando rename(). Isso serve para proteger contra perda de energia, certificando-se de que você sempre mantenha o arquivo antigo ou obtenha o novo arquivo (que foi fsync() antes da renomeação). Você não quer ficar com apenas uma versão semi-escrita do novo arquivo.
Mas havia um problema que chamar fsync() no ext3, que era o sistema de arquivos Linux mais popular, poderia deixar todo o sistema suspenso por dezenas de segundos. Como os aplicativos não podem fazer nada sobre isso, era muito comum usar rename() com otimismo sem fsync(). Esse padrão parecia funcionar muito bem nesse sistema de arquivos, mesmo que o sistema perdesse energia.
Portanto, existem aplicativos que não usam fsync() corretamente.
A próxima versão do sistema de arquivos, ext4, geralmente evitava o travamento do fsync(). Ao mesmo tempo, passou a depender muito mais do uso correto de fsync().
Isso tudo é muito ruim. Compreender essa história provavelmente não é ajudado por frases desdenhosas usadas por muitos dos desenvolvedores de kernel conflitantes.
Isso foi resolvido em ext4, parasuporta o padrão rename() sem exigir fsync() para segurança contra falhasfornecer comportamento em uma falha como o antigo sistema de arquivos ext3 fez. Este comportamento pode ser desabilitado novamente se você montar com a opção noauto_da_alloc.
Há um erro nesta pergunta. A pergunta implicava que esse cenário é totalmente seguro contra falhas pelo
auto_da_alloc. Isso não é verdade para ext4. Presumo que também não era verdade no antigo ext3. No entanto, é verdade para btrfs e para bcachefs.https://homes.cs.washington.edu/~lijl/papers/ferrite-asplos16.pdf
Em
btrfs, a documentação diz que substituir um arquivo usando rename() fornecerá atomicidade completa e não precisa de um fsync() explícito para proteger os dados contra falhas. Eu acho que isso foi adicionado na mesma época que ext4auto_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. No entanto, noto em kernels recentes, pelo menos se você usou fsync(), o seguinte rename() fará fsync() no diretório pai e aguardará que toda a "árvore de log" seja gravada .bcachefsatualmente parece fornecer o nível completo de proteção, embora eu não tenha encontrado nenhuma documentação. Verifique o código. Eu vejo uma chamada para a função "filemap_write_and_wait_range"XFSrejeitou a adição de soluções alternativas de segurança para rename(). Aparentemente, ele 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 de segurança contra travamento para rename(). Poderia ser aceito, mas exigiria muito trabalho. http://www.linux-mtd.infradead.org/doc/ubifs.html#L_sync_exceptions