Nem sempre o prazo define, veja, levo + de 2000 anos para inventar a lâmpada, e agora estamos usando computador, o desenvolvimento tecnológico é exponencial, a cada 2 anos muda muita coisa, e no futuro esses 2 anos vão ser mais curto ainda, isso acontece porque quanto mais a tecnologia aumenta o ser humano fica mais produtivo, isso significa que tempo não é determinante para o salto tecnológico.
Imagine que alguém compra um computador com um objetivo de instalar um sistema baseado em Linux. Munido de um pen drive com o Linux Mint, uma máquina com um AMD Ryzen e uma Radeon RX, alguns bons gigas de RAM e uma boa quantidade de storage, o indivíduo monta sua máquina e instala o sistema utilizando o pendrive bootável que ele já tinha.
Tudo que esse usuário faz é usar o computador como um ser comum: além da navegação na web, talvez uma criação de conteúdo aqui e ali, e gestão de arquivos pessoais e jogos. Nada de mais.
Mas não, esse nosso amigo está correndo um risco gravíssimo. Por que ele está usando EXT4 como seu filesystem principal, e não soluções como BTRFS ou XFS. Cada vez que ele liga o computador, o sistema inicia normalmente, não trava nem tem lerdezas, está tudo no lugar. Mas não: por que ele não usa um que inicia 3x10^-9 segundos mais rápido, claramente ele está se colocando num risco muito grande de perder seu computador, sua casa pegar fogo por que houve um curto por que o EXT4 deu uma leve demorada e a RAM esquentou…
Sinceramente. Há vantagens em outros filesystems? Há. É extramemente vital? Não. Alguém vai morrer se usar outra coisa? Não. Vai perder dados? Também não.
O computador só é ligado, usado durante umas horas, e desligado, sem maiores problemas.
Qual a necessidade de tanta proteção?
É errado usar outros filesystems? Não, mas não é questão de vida ou morte.
(Já deu o que tinha que dar rs)
Ou dois caras numa moto…
Uai, vamos começar novamente então, o usuário pode usar um celular de tijolo, pode ele não vai morrer.
O usuário pode usar um carro de boi na cidade, pode ele não vai morrer.
O usuário pode usar linguagem de maquina, pode ele não vai morrer.
Continua…
Na minha cidade, onde não são necessários carros de corrida, alguém pode muito bem usar um carro de boi, ou puxado por cavalos.
Quem sabe um gestor de uma empresa grande se beneficie de uma taxa de transferência melhor para seu serviço de streaming? 
Acho difícil, o pleno funcionamento e interruptibilidade é essencial.
A menos que seu sistema(da empresa) seja apenas leitura, quando o filesystem está montado como somente leitura a chance dele dar problema é extremamente mínima, os problemas costumam a ocorrer em modificações de nós durante escrita ou escrita que acontecem durante a queda de energia.
Nesse caso é viável.
@here Feliz natal <3
Continuando a discussão de EXT4 e NTFS são tão ruins assim?:
O que mudou de 2006 para 2009 em questão de Sistema de Arquivos?
Quando o Btrfs surgiu, fazia três meses que o EXT4 tinha sido considerado estável (mais exatamente em Dezembro de 2008) e as distros estavam começando a colocar o EXT4 como padrão, sendo o Fedora 11 uma das primeiras. E o Btrfs, foi incluído no Kernel em Março de 2009.
E ainda dizem as más línguas, que o desenvolvimento do Btrfs se iniciou em 2007. Ou seja, quase ao mesmo tempo que o EXT4.
Novamente: O EXT4 é tão moderno quanto o Btrfs, mas os dois são apenas FS diferentes para finalidades diferentes e com características diferentes.
O que é mais viável para uma tarefa simples, como ler quadrinhos que estão em arquivos .cbr: Um iPad extremamente caro e potente ou um Tablet Genérico da Multilaser?
As vezes o Tablet Genérico da Multilaser é o que basta. Você não precisa sempre ter o “mais poderoso de todos” para fazer uma tarefa. Às vezes, aquele que é mais básico já basta, e o que é mais poderoso seria muito “overkill”.
Assim como, provavelmente, para 99% dos casos o EXT4 já basta. Até porque não é todo mundo e nem toda situação que vai precisar dos recursos que o Btrfs oferece.
No inicio, quando o EXT4 foi lançado eles estavam correndo atrás do atraso, o EXT4 só existiu porque desistiram de fazer as implementações dele no EXT3 era para o EXT4 ser o EXT3.
veja, o que o usuário “leandro go” escreveu “diferente do ext4 que é um tapa buracos de ext3”
https://www.vivaolinux.com.br/topico/Kernel-Linux/Ubuntu-Btrfs-vem-novidade-ai
Então quando o EXT4 foi lançado ele já estava capengando.
Quando eles estavam la escrevendo o código do EXT3 o código estava muito difícil de trabalhar, e como precisava de implementar rápido o Journaling porque só tinha o capengado EXT2 eles pegaram o EXT2 e só enfiaram um Journaling nele rapidão e lançaram, e ai o tempo foi passando e o EXT4 só que na mesma época já existia o RiserFS e Riser4 dai o porque que eles correram atrás do atraso para lançar o EXT4, ai quando eles lançaram o EXT4 o ZFS já tinha atropelado tudo de novo ai mais uma onda negra, ai começo o desenvolvimento do BTRFS para correr atrás do atraso e hoje estamos partindo para o BcacheFS.
O Linux quase morreu em servidores por causa dessas coisas, mas hoje estamos ai firmes e fortes.
O EXT4 foi lançado porque o Reiser4 parou de ser desenvolvido porque o seu desenvolvedor foi preso porque cometeu um crime(supostamente matou a sua esposa). outro motivo de o porque o EXT iria morrer no EXT3. E não se enganem, não vai sair muito provavelmente um EXT5 podem esquecer a implementação de recursos modernos em um FS tão antigo não compensa.
Teriam que reescrever uma boa parte do código, não a motivo para isso.
Por alguma razão a comunidade de la para cá pego amor pelo EXT4 enquanto o pessoal daquela época estavam preocupados com o Linux. Vai entender, cada um sabe da sua vida.
É gente, tentei dormir mas a insônia hoje me pego, difícil.
https://docs.kernel.org/admin-guide/ext4.html
https://wiki.archlinux.org/title/Ext4
Nenhuma destas paginas, nem mesmo a documentação oficial do EXT4(penúltimo link) diz que ele tem a capacidade de se reparar automaticamente sem intervenção manual.
Isso não é possível porque ele não é COW.
O EXT4 precisa que manualmente o usuário entre na linha de comando e rode o FSCK com a opção de reparo habilitada. Se não fizer isso ele apenas verifica se está marcado como limpo e se não ele joga o usuário para a tela de manutenção.
@Leonam_Cruz então com tudo isso se chega a conclusão de que o EXT4 e NTFS e seus antecessores são obsoletos sim, e as decisões de usa-los é apenas decisão não técnicas.
É isso.
Outra vantagem sobre o EXT4 do BTRFS é que o BTRFS é B-tree ou seja a sua busca é mais eficiente. Essa é a vantagem do BTRFS em relação ao ZFS, o ZFS não é B-tree. O destaque do BTRFS é ser B-tree.
Uma observação: eu posso estar enganado em questão de não ser possivel implementar auto correção em filesystem Journaling, isso porque eu me lembrei que o filesystem "ReFS da Microsoft é capas de se auto reparar essa tecnologia no Journaling é chamada de “Resiliência incorporada” mas é o unico que teve essa capacidade dos Journaling de lá para cá vai ser tudo COW uma vez que fazer copia antes da gravação é mais eficiente que o Journaling.
Embora haja alternativas mais recentes, ambos os sistemas continuam em uso e com suporte. O conceito de obsolescência (em tecnologia) pode representar tanto que algo não é mais a tecnologia mais nova, quanto também aquela tecnologia que não seja útil.
Então a discussão aqui se girou muito sobre essas diferentes interpretações, mas ambas podem ser aplicadas. Para evitar a confusão, o ideal seria usar o conceito de segurança para definir se o sistema deve ser usado ou não. Para tal, vamos definir o que seria uma perda de arquivo ou corrompimento quanto à origem dela:
- Perda por hardware: Aquela que acontece no meio físico, e corromperia qualquer sistema.
- Perda por desligamento inesperado: Aquela onde o sistema de arquivos se torna corrompido ou perde-se arquivos por conta de um desligamento abrupto, como falha de energia ou travamento total do sistema operacional.
- Perda por falha na programação: Aquela onde uma falha na programação do sistema de arquivos o leva a um estado corrompido ou perda de arquivos.
Dessas falhas, há algumas mais graves que outras:
- Perda de nova informação: Aquela que acontece quando um arquivo é adicionado ou modificado, porém essa nova parte não fica registrada.
- Perda de informação existente: Acontece quando nova informação sobrescreve informação ainda necessária.
- Corrompimento do sistema de arquivos: Quando a falha acontece a nível de metadados, é possível que partes extensas se percam. É o pior panorama possível.
Com essas definições em mente, podemos então analisar os sistemas de arquivos quanto a sua segurança:
- Sistemas de arquivos sem suporte são inseguros, independente de terem journaling/COW. Um exemplo é o ReiserFS. Esses não devem ser usados, a não ser em testes, experimentos, ou estudos históricos.
- Sistemas que são propensos a perda de arquivos são inseguros, mesmo que tenham suporte. São exemplos o ext2 ou o FAT32. Mesmo assim é comum que sejam usados em sistemas de arquivos em que são realizadas poucas escritas (como o /boot ou partição ‘esp’ UEFI) e/ou necessita-se de um sistema simples para escrita/leitura em dispositivos embarcados.
- Sistemas seguros quanto a perda de arquivos e estáveis, que possuem suporte atualizado e possuem estratégias de mitigação de perda de dados. Aqui incluem-se tanto o ext4, ntfs quanto os mais novos (com recursos mais recentes) como ZFS ou BTRFS. Esses seriam a melhor escolha para o usuário comum e a escolha entre algo mais antigo/recente dependederia apenas da decisão técnica de querer usar recursos avançados dos sistemas mais novos. Nesses sistemas é mais provável uma falha de hardware (tipo ssd morrer totalmetne) causando a perda de dados do que uma falha no sistema de arquivos, mesmo que em um cenário de desligamento repentino.
- Sistemas seguros quanto à perda de arquivos, mas ainda em desenvolvimento, que possuem suporte atualizado mas podem conter falhas de programação ainda desconhecidas (bugs). Eu daria como exemplo o bcachefs ou mesmo btrfs com alguns recursos ainda em desenvolvimento, como raid5/6. Esses não devem ser usados em ambientes de produção, mas sim em ambiente de testes por desenvolvedores capazes de submeter relatórios de falhas quando elas acontecerem.
Acredito que o enfoque em segurança venha a sanar as dúvidas levantadas no tópico sobre ser um sistema de arquivo ser bom, ruim ou obsoleto. Além da análise com foco em segurança, também deve-se analisar os recursos disponíveis em cada um deles e se são necessários no ambiente escolhido.
Isso é verdade, o BTRFS ainda esta em desenvolvimento, e por ainda ser adicionado códigos em seu código fonte pode aparecer problemas inesperados.
No entanto o BTRFS é usado em produção e seu desenvolvimento está bem lento, acredito que é devido a ele ser considerado estável e estar sendo usado em produção isso faz com que a responsabilidade de novos patch em seu código tenha que ser mais rigoroso e passar por um período de teste mais prolongado para que os servidores de produção não de uma pane. Outra coisa é que o BTRFS é considerado estavel apenas em partes especificas de sua implementação assim como diz o @Deleterium. Isso está correto.
Aqui tem uma matéria bem explicativa sobre o file system do linux como para windows.
Muito pobre esse link, esse tópico está mais rico de informação que essa pagina. Está tão crú que ele escreve sobre o ZFS “oferece proteção contra corrupção de dados e recursos avançados como de duplicação de dados para otimizar o uso do espaço.” sendo que o BTRFS tem essas mesmas tecnologia e nem menciona, está bem pobre.
Mas tmb está escrito tudo em poucas linhas, não da para mencionar muita coisa, já aqui está cheio de link e varias linhas.
Não é criticando o link não, ele fez o que pode em poucas linhas.