My main concern is that such damage NEVER happened to disks partitioned to NTFS, whatsoever.
Talvez nunca tenha acontecido com você , mas aconteceu. Os únicos sistemas de arquivos que podem afirmar que coisas como essa nunca acontecem são aquelas que nunca foram expostas a tais condições. Até mesmo o BTRFS e o ZFS, que são projetados para serem resilientes a coisas como essa, podem ter esses problemas.
Para suas perguntas reais:
Is ext4 safe in general? I mean is it me or are there other people who experienced loss of disks/information on disks formatted to etx4?
Depende do que você quer dizer com "seguro". Eu pessoalmente perdi dados em discos formatados com ext4
, mas toda vez que isso aconteceu comigo foi devido a hardware ruim e, o mais importante, teria acontecido eventualmente com praticamente qualquer outro sistema de arquivos. Apesar disso, eu continuo a usá-lo para inúmeras coisas em uma base regular, porque, salvo erro de usuário ou problemas de hardware (que inclui perda de energia inesperada), ele simplesmente funciona. Então, eu considero 'seguro' pelas definições da maioria das pessoas, mas você pode ou não.
In Linux world, what could be a safer alternative to ext4 that can outlive unexpected electricity switch off or unexpected unmounting?
Não, a menos que você queira lidar com outras limitações ou problemas. Em particular:
- O XFS é um pouco mais resistente contra perda inesperada de energia e não precisa de verificações longas durante a reinicialização, como acontece com o ext4, mas possui várias limitações práticas que o tornam questionável para uso em pequena escala (não é possível reduzir sistemas de não é tão bom quanto o ext4 em um novo volume, não pode fazer o registro no diário de dados).
- O NILFS2 é quase impossível de ser eliminado com uma falha de energia, mas você pode perder 30 segundos ou mais de alterações, requer um componente de espaço do usuário ao montar e falta um punhado de recursos geralmente considerados padrão pela maioria dos sistemas de arquivos Linux .
- O BTRFS poupará você do hardware com falha e razoavelmente de forma confiável, além de oferecer um ótimo suporte para a substituição on-line de discos com falha, mas novamente você pode perder algumas das alterações mais recentes em uma perda de energia inesperada e precisa fazer muito mais para manter o volume saudável do que para a maioria dos outros sistemas de arquivos.
- O ZFS tem todos os benefícios que o BTRFS faz com nenhum dos seus problemas (exceto os de gerenciamento), mas requer que você crie um módulo de kernel de terceiros e não obterá nenhum suporte upstream para quaisquer problemas que você tenha você não está executando em hardware de nível empresarial.
Você pode, no entanto, fazer várias coisas para tornar o ext4 mais seguro:
- Altere o comportamento quando erros são encontrados. Por padrão, se um erro for encontrado nos metadados do sistema de arquivos, o ext4 marcará o volume apenas como precisando ser verificado e, em seguida, agirá como se nada tivesse acontecido. É o sistema de arquivos somente no Linux que faz isso, todo o resto irá remontar o volume somente leitura, evitando assim que qualquer gravação no sistema de arquivos piore as coisas. Você pode obter esse comportamento no ext4 adicionando
errors=remount-ro
às opções de montagem ou executandotune2fs -e remount-ro
no dispositivo de bloco que contém o sistema de arquivos. - Verifique se você está não usando o modo de write-back para o diário. Você pode garantir isso verificando novamente as opções de montagem do volume e certificando-se de que
journal=writeback
não esteja na lista. O modo de write-back do Journal pode melhorar significativamente o desempenho de certas cargas de trabalho em sistemas de arquivos ext4, mas torna muito mais provável que você perca dados se perder inesperadamente energia. - Se você quer ser realmente paranóico com relação à segurança de dados, é possível ativar o modo de dados registrados. Normalmente, o diário em um sistema de arquivos ext4 rastreia apenas alterações em metadados (renomeação, exclusão ou criação de arquivos, atualizações de registro de data e hora, etc.). No modo de dados registrados, todas as alterações passam pelo diário. Isso diminui significativamente as coisas, mas fornece uma garantia funcional de 100% de que o sistema de arquivos permanecerá consistente internamente. Você pode habilitar isso passando
journal=data
nas opções de montagem. - Você pode adicionar a opção
auto_da_alloc
mount. Essencialmente, isso detecta aplicativos que não chamamfsync()
quando deveriam e manipulam adequadamente as coisas. Não é o padrão porque diminui um pouco as coisas, e a maioria dos aplicativos não precisa disso. - Nos kernels mais recentes, você pode ativar a soma de verificação de diário. Isso não salvará seus dados, mas ajudará a garantir que você não receba dados falsos quando houver um erro. Isso pode ser ativado adicionando
journal_checksum
às opções de montagem. - Se você tiver um kernel e uma versão novos o suficiente do e2fsprogs, poderá ativar a soma de verificação de metadados. Semelhante à soma de verificação do diário, isso não salvará seus dados, mas ajudará a impedir que você veja dados falsos se houver um erro. Isso deve ser ativado no momento da criação do sistema de arquivos, passando
-O metadata_checksum,metadata_checksum_seed
paramkfs.ext4
. Se você fizer isso, você (provavelmente) não precisará ativar a soma de verificação de diário, pois o diário é parte do que é coberto pela soma de verificação de metadados.