Encontrada vulnerabilidade na deduplicação do Btrfs e do ZFS

 Deduplicação é uma técnica muito interessante para evitar redundância e duplicação de dados e assim melhor aproveitar os dados e metadados do sistema de arquivos. Este recurso é utilizado em sistemas de arquivos como o ZFS, o Btrfs e o Hammer do DragonflyBSD. Porém, esta semana foi descoberta uma vulnerabilidade muito grave neste recurso.

 

 Membros da universidade de Vrije  (Vrije Universiteit Amsterdam) encontraram uma falha de segurança no recurso de deduplicação dos sistemas de arquivos ZFS e Btrfs. O erro foi encontrado pelo grupo de pesquisadores Andrei Bacs, Saidgani Musaev, Kaveh Razavi, Cristiano Giuffrida, Herbert Bos que pretende apresentar na conferência FAST'22 (20th USENIX Conference on File and Storage Technologies) e tornar seu conhecimento publico  no dia 23 de Fevereiro deste ano.

 Essa vulnerabilidade ocorre especificamente no inline deduplication que permite o invasor utilizar uma classe de ataque chamada DUPEFS e obter arquivos sensíveis do sistema (e até arquivos secretos dos usuários) mesmo remotamente (tanto em LAN quanto em servidores na internet). Em seu paper, os pesquisadores apresentam como cada sistema de arquivos trabalha com inline deduplication para assim melhor entender como explorar a vulnerabilidade.

Como cada sistema de arquivos trabalha com inline deduplication.

 Este paper possui 15 páginas muito bem detalhado apresentando todo o cenário do ataque e todos os seus resultados tanto no Linux (utilizando ambos os sistemas de arquivos) quanto no FreeBSD. Eu incentivo a todos acompanhar sua apresentação no evento já que se trata de uma vulnerabilidade grave e que os desenvolvedores irão precisar concentrar esforços na solução do problema.

 Isso significa que estamos em risco? Em partes pode ser que sim como pode ser que não. Primeiro que, apesar da vulnerabilidade ser grave, não são todos que conseguem explorá-la; segundo que no paper os pesquisadores apresentam algumas formas de defesa (em Deduplication Defenses) como medidas paliativas como forçar a criptografia e ofuscação imposta por um gateway intermediário na rede até que soluções sejam apresentadas.

 E terceiro é que há um ponto a se considerar aqui tratando-se de Btrfs (já estou ouvindo o chilique de que sou fanboy de Btrfs). Em minha série ZFS VS Btrfs mencionei que ambos os sistemas de arquivos oferecem recursos iguais PORÉM, implementados de formas diferentes e com técnicas diferentes; deduplicação não é uma exceção a essa regra. No vídeo primeiro video da série que você pode conferir abaixo, eu explico a diferença na implementação de recursos entre os dois sistemas de arquivos. Confiram a diferença entre a deduplicação de ZFS e do Btrfs:

 Ou seja, essa vulnerabilidade não afeta o Btrfs como mencionado no paper apresentado pelos pesquisadores, pois inline deduplication já não é utilizado no Btrfs há um bom tempo. Inline deduplication para o Btrfs foi desenvolvido pela Fujitsu como pode ser lido clicando aqui e já não é mais mantido (ele foi simplesmente abandonado pois a Fujitsu não tem mais planos para ele), os patches eram incompletos e este recurso é muito complexo para ser implementado no kernel Linux.

 Qu Wenruo que foi um dos autores do inline deduplication para o Btrfs informou aos pesquisadores o:

 "Como um dos autores originais, eu e o meu empregador não temos mais interesse em continuar dedupe. Além do mais, a implementação original possui um limite, um extent tem que ser escrito no disco antes que possa ser utilizado pelo write-time dedupe."

 Para deduplicação o Btrfs utiliza a técnica out of band deduplication (como mencionei no meu vídeo), o módulo ioctl e ferramentas em userspace como BEES.

 Moral da história

 O que os pesquisadores utilizaram na verdade foi uma versão muito antiga do btrfs (talvez de 4 anos atrás) e deveriam ter testando ao menos uma versão que possui out of band deduplication (de preferencia versões mais recentes do kernel Linux).

 Vou reforçar que já estou ouvindo me chamarem de fanboy de Btrfs (SARCASMO ON: Não são eles que são fanboys de ZFS ou do Ext4, sou eu que sou fanboy de Btrfs... Eu não apresentei nenhum argumento técnico, foi só coisa de fanboy mesmo... Sempre assim...)

 E por ultimo vamos ver se os sites (como o que postou o artigo Examinando o Btrfs, o sistema de arquivos do Linux perpetuamente semi-acabado) chegarão a publicar sobre essa falha no ZFS (honestamente eu duvido) pois esse já não é a primeira que eu posto. Alias, vamos ver quanto tempo vai levar para isso ser corrigido no ZFS. Basta lembrar do caso do alto consumo de CPU no ZFS por exemplo que levou anos para ser corrigido. Este caso pode ser lindo clicando aqui.

Minha série "ZFS VS Btrfs"

Link para o paper DUPEFS: Leaking Data Over the Network With Filesystem Deduplication Side Channels

Link para o inline deduplication no btrfs desenvolvido pela Fujitsu

AGORA, QUER APRENDER BTRFS DE VERDADE? ENTÃO CONFIRA O MEU CURSO DE LINUX CLICANDO AQUI :) 

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Seja Membro Premuim do Regata OS e ganhe prêmios e suporte

Novos recursos do Btrfs

Novos recursos do Btrfs

    Btrfs é o sistema de arquivos que ao longo de muito tempo eu venho promovendo tanto no meu canal e no meu blog pois traz recursos muito assemelhante ao ZFS e ao ReiserFS porém, implementados de forma diferente. O Btrfs é fortemente utilizado por empresas como Facebook, Suse, Oracle e até mesmo exigido pela LPI.

Mais sobre o Btrfs pode ser conferido clicando aqui.

    Nos últimos meses, novos recursos foram implementados e aqui eu vou debater sobre eles.

 SOLUCIONANDO PROBLEMA ENTRE  VFS/BTRFS/NFS

    

NeilBrown da Suse enviou no dia 12 de Agosto o patch corrige problemas que ocorrem entre o Nfsd e o Btrfs. A questão é que o Btrfs não fornece números de inode único através de outros sistemas de arquivos, mas sim através de subvolumes e utiliza números de dispositivo sintético para subvolumes diferentes para garantir singularidade entre dispositivo e inode.

    O problema é que o Nfsd não consegue trabalhar com números de dispositivo variante podendo causar problema no subvolume. Este patch permite que Btrfs ou qualquer outro sistema de arquivos forneça um número de 64 bits tornando o resultado mais único entre subvolumes e sistemas de arquivos (talvez a partir disso poderemos ter a solução para problema do VFS :)

IDMAPPED MOUNTS

    Em maio eu havia postando que Christian Brauner da Canonical estava portando o idmapped mounts para o Btrfs (essa informação pode ser lida clicando aqui). Já no dia 31 de julho Christian retornou com o novo patch que traz o total de 71 novidades no idmapped mounts que estão divididos dentro de BTRFS_IOC_{SNAP,SUBVOL}_CREATE_V2, BTRFS_IOC_SNAP_DESTROY_V2, BTRFS_IOC_SUBVOL_SETFLAGS e BTRFS_IOC_INO_LOOKUP_USER.

NOVA AJUDA NA OPÇÃO DEFRAG

    Qu Wenruo da Suse que enviou o patch introduz a opção desfragmentar um intervalo (defrag_one_range()) que reverifica status de extents e paginas para garantir melhor consistência. Ainda não houve resposta para esse patch, mas vamos aguardar. 

    Ainda falando de desfragmentação (que é uma super vantagem sobre o ZFS), há ainda um recurso para a opção defrag e autodefrag que Josef Basick anunciou em Julho de 2020 que aguardo bastante. Josef até informou que o autodefrag é muito util com arquivos pequenos como é o caso dos 9.000 arquivos sqllite que o Firefox utiliza, mas não tão util para arquivos gigantescos como é o caso de imagens de máquinas virtuais pois leva-se muito tempo para desfragmentar.

    Uma solução que é indicada há muito tempo é copiar a imagem da máquina virtual para uma nova utilizando recurso de de-duplicação (quer saber como solucionar esse problema. Confira o meu minicurso de atributos no Linux clicando aqui).

    Já a solução sugerida por Josef seria poder passar um parâmetro no defrag/autodefrag onde os usuários poderiam definir por arquivo ou diretório permitindo manter o controle de onde exatamente ocorrerá a atividade extra de escrita.

Esse  é o submit do Josef mencionando que pretende adicionar o recurso ao autodefrag para trabalhar corretamente.

    Há recursos que existem no ZFS que eu ainda espero ver no Btrfs (um deles seria o mesmo que existe no Bcachefs e que já até tratei em uma live. Esse recurso permite utilizar o ssd como cache em conjunto com o HD para acelerar o processo (acho um erro cometido pelo autor do Bcachefs desenvolver todo um sistema de arquivos somente para implementar um único recurso). Outro seria a capacidade de armazenamento do ZFS (256 quatrilhões de zebibytes enquanto que o Btrfs é de 16 EiB). Agora é tudo questão de aguardar para ver o que o futuro nos espera e aguardar mais novos recursos no Btrfs.

 Agradeço ao Anderson Rincon pela revisão

Mais sobre o Btrfs pode ser conferido clicando aqui.

 QUER APRENDER A UTILIZAR o BTRFS DE VERDADE, ENTÃO VENHA APRENDER COMIGO ;)

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Seja Membro Premuim do Regata OS e ganhe prêmios e suporte

Btrfs pode em breve receber criptografia transparente

Btrfs pode em breve receber criptografia transparente

 Omar Sandoval (que até aonde identifiquei, trabalha para o Facebook devido seu e-mail ser de domínio fb.com) está trabalhando para que o sistema de arquivos Btrfs possua suporte a criptografia transparente através do fscrypt. Como descrito por Omar, o fscrypt é uma biblioteca e interface dentro do kernel Linux que pode ser utilizada pelos sistemas de arquivos para fornecer criptografia transparente e atualmente é utilizado pelo ext4, o F2FS e o UBIFS. O fscrypt também está sendo utilizado pelo systemd homed.

"Criptografia transparente para o Btrfs é um recurso frequentemente solicitado. Ao invés de criar uma uma nova interface de criptografia especialmente para o Btrfs, gostaríamos de utilizar o fscrypt para p Btrfs também. No entanto, os recursos avançados presentes no Btrfs apresentam alguns desafios em termos do suporte ao fscrypt."

 Sim, No site oficial do Btrfs consta que suporte a nível de criptografia para arquivos e diretórios através do fscrypt já é algo planejado para o futuro.

Recursos atualmente em desenvolvimento ou planejados para futura implementação.

"Eu ando debatendo e trabalhando em um protótipo para que esses recursos do Btrfs possam ter suporte ao fscrypt, então eu imagino que era hora de eu escrever e fazer um loop nos desenvolvedores do fscrypt também."

 Omar elaborou um documento e disponibilizou para a equipe do Btrfs que já estão o informando em como ele deve trabalhar nos recursos.

Mais sobre o btrfs aqui no blog, basta clicar aqui.

Página oficial do Btrfs.

documentação do fscrypt no kernel

Github oficial do fscrypt

VENHA APRENDER SOBRE O BTRFS COMIGO :)

E não esqueçam de conferir também o meu mini curso de atributos no Linux e aprendam mais recursos nos sistemas de arquivos 

Seja Membro Premuim do Regata OS e ganhe prêmios e suporte

Como Facebook utiliza Linux e o Btrfs: Uma entrevista com Chris Mason

Aprenda o estado de desenvolvimento do Btrfs nessa entrevista com o principal autor, Chris Mason.

Creative Commons Attribution

Swapnil Bhartiya

Chris Mason é o principal autor do Btrfs, o file system open source que é visto como o file system padrão do SUSE Enterprise Linux. Mason começou a trabalhar no Btrfs na Oracle e depois se mudou para o Facebook onde continua a trabalhar no file system como membro da equipe de Linux da empresa. Quando Facebook possui novos kernels que precisam ser lançados, Mason ajuda a certificar que tudo foi devidamente testado e encontra as necessidades de performance.

Sentamos com Mason para aprender mais sobre o status do Btrfs e como Facebook está utilizando Linux e o Btrfs. Aqui está uma versão editada dessa entrevista.


Linux.com: Btrfs anda sob desenvolvimento por muito tempo. Ele está pronto para uso em produção? Sei que as distribuições Linux estão utilizando-o como file system padrão, onde outras não.

Chris Mason: É de fato o padrão no SUSE Linux Enterprise Server. SUSE gasta um considerável montante de energia e de pessoa dando suporte ao Btrfs, que eu realmente aprecio. Red Hat não adotou do mesmo jeito. É uma dessas coisas onde pessoas pegam recursos que elas mais se importam e outras que elas querem construir em cima daquilo.


Linux.com: Quais são as áreas onde o Btrfs faz mais sentido? Se eu não estiver errado, Facebook também utiliza Btrfs?

Mason: Dentro do Facebook, novamente nós pegamos lugares alvos onde achamos que os recursos do Btrfs são realmente benefícios para a carga de trabalho em mãos. As grandes áreas que estamos tentando focar são tarefas de gerenciamento de sistemas, os tipos de coisas para se fazer snapshot.


Linux.com: Todos nós sabemos que Facebook é um usuário pesado de Linux. Dentro da massiva infraestrutura do Facebook, onde Linux está sendo utilizado?

Mason: O jeito mais fácil de descrever a infraestrutura no Facebook é que é bem tudo Linux. Os lugares que estamos murando para o Btrfs são realmente gerenciamento de tarefas em torno de distribuir o sistema operacional, distribuir atualizações rapidamente utilizando os recursos de snapshotting do Btrfs, utilizando os recursos checksumming do Btrfs e assim por diante. Também temos um número de máquinas rodando Gluster, utilizando ambos o XFS e o Btrfs. O alvo primário lá é armazenamento de dados. Uma das razões do porque eles gostam do Btrfs para o uso de Gluster use é por causa que o data CRCs (cyclic redundancy checks) e o metadata CRCs nos oferecem a habilidade de detectar problemas no hardware tal como corrupção silenciosa de dados  no hardware. Encontramos na verdade poucos grande bugs de hardware com o Btrfs então ele tem sido beneficente para o Btrfs.


Linux.com: Enquanto estamos falando sobre Linux no Facebook, estou curioso o quão perto ou longe você está da mainline já que ninguém está utilizando o stock kernel; todos criam um fork menor como tweaks e tuning para uso próprio.

Mason: De um ponto de vista do Linux, nosso objetivo primário com o kernel Linux é rastrear a main line o máximo que podemos. Nosso objetivo é atualizar o kernel ao menos uma vez por ano. Estamos tentando mudar para um ciclo atualização com mais frequente do que essa. Temos uma primeira politica de upstream onde temos as alterações na mainline antes de utilizá-las. Se quisermos ter um recurso no kernel, ela tem que ir a mainline primeiro.


Linux.com: Por que vocês precisam de seu próprio fork?

Mason: É possível percorrer a mainline kernel. Você tem que ter algum tipo de fork, você refina as coisas, você ajusta as coisas, e você aplica alguns patches para seu próprio uso. Nosso objetivo e manter esse fork tão pequeno humanamente possível. Quando estamos mudando do kernel 4.0 para o 4.6, que estamos ainda em processo de mudança, eu estava realmente feliz quando fomos capazes de obter um desempenho de carga de trabalho em produção em par com apenas um patch. Esse foi realmente um grande negócio. Sendo capaz de pegar basicamente um kernel vanilla 4.6 e ter os mesmos desempenhos que tinhamos no nosso kernel 4.0 com nossos patches. E esse é realmente o nosso objetivo a longo prazo: Para nos aproximar cada vez mais a apenas ser capaz de rodar mailine, assim podemos fazer a transição de um kernel para outro muito rapidamente.


Linux.com: Todos nós temos visto máquinas rodando versões realmente antigas do kernel Linux, onde você está visando rodar a ultima versão se você puder. Qual a vantagem?

Mason: O maior benefício, como uma organização de engenharia, é que queremos contratar pessoas que estão fazendo upstream de coisas. Desenvolvedores querem trabalhar em tecnologias novas e inovadores, eles querem fazer seus trabalhos upstream, eles querem vir a essas conferências, e eles querem ser uma parte desta comunidade. Queremos ser capazes de ter nossos trabalhos no kernel em upstream e então trazê-lo de volta para o Facebook. É mais fácil encontrar e contratar desenvolvedores upstream, e é o melhor jeito de manter o fluxo de manutenção baixo.


Linux.com: No server space, nós com frequência escutamos de sysadmins que "uma vez que ele estiver instalado e rodando, não toque nele” que é contrário ao que vemos em infraestrutura de IT moderna onde o mantra aparenta mudar mais rápido para ficar mais seguro.

Mason:  Acho que a escala do Facebook torna isso mais fácil para testarmos as coisas. Não é que o o trabalho de teste em si é mais fácil, mas podemos espalhar esse trabalho em um grande número de máquinas. Temos a habilidade levar o trabalho de teste para o que chamamos "Shadow Tiers." Nesses Shadow Tiers, podemos reproduzir o tráfego de produção em um ambiente de não produção real, assim podemos estar em um lugar muito seguro para verificar o desempenho e assegurar a estabilidade. Podemos construir uma rampa que trafega, assim posso iniciar e dizer, "Beleza, vou lhe dar 5 porcento de um replay do tráfego de produção e sobe tudo para 100 e observo o desempenho atual como eu me saio.” Pode obter uma comparação A/B muito forte entre os dois kernels ao longo do caminho. Temos as ferramentas para validar os kernels e ajudar a testar os kernels upstream. É mais fácil corrigir os novos e interessante bugs em upstream do que é constantemente apenas encontrar velhos bugs que o upstream já corrigiu.


Linux.com: Quais são as coisas que lhe deixam preocupado?

Mason: Em termos de rodar o Kernel Linux ou file systems, testamos tão bem e tanto suporte da comunidade em torno do Linux que eu realmente não me preocupo quanto a rodá-lo.


Linux.com: Você está envolvido com o Linux por muito tempo e Linux acabou de celebrar seu vigésimo quinto aniversário, o que você acha que Linux alcançou noesses 25 anos?

Mason: A parte que eu dou mais créditos ao Linus, a parte dos contribuidores técnicos que são óbvios, é sua habilidade de criar a comunidade do kernel de desenvolvedores onde as pessoas eram tão ativamente interessadas em levá-la adiante de verão para versão. Linux não fragmentou do jeito que muitos projetos já. Não é tudo o Linus, mas eu dou a Linus tanto crédito por que com o processo que ele definiu, foi muito mais fácil levar adiante com o kernel do que foi criar um fork dele e fazer algo mais diferente.

Acho que que é uma contribuição importante que um monte de pessoas negligencia em termos de como a comunidade do kernel se uniu e trouxe novas empresas ao invés de afastá-las.

Inicie o desenvolvimento do Linux. Confira a "Apresentação livre ao curso de desenvolvimento Open Source do Linux e o do GIT"  da The Linux Foundation.

Docker consumindo muito armazenamento no Btrfs

Docker consumindo muito armazenamento no Btrfs

 Containers são combinações de recursos do Linux como o namespace e cgroups. Recursos esse que eu já apresentei aqui no meu artigo Linux: Mais do que um Unix e trata-se dos mesmos recursos que são utilizados pelo systemd e por várias outras aplicações. Ferramentas como Docker e Kubernetes servem na verdade para facilitar o uso de tais recursos já que raramente as pessoas criam containers manualmente. Devido o Docker trabalhar com o recurso Copy-on-Write, o sistema de arquivos indicado na criação de seus containers é o Btrfs.

 No dia 02 de Novembro, Chris Murphy reportou a equipe do Btrfs um bug que ocorre no Docker que consome muito espaço de armazenamento. Esse é um bug que já havia sido reportado em Outubro de 2016 por um usuário chamado no GitHub de Ghost e ainda permanece em aberto.

Informação pode ser lida aqui

 Ghost explica como reproduzir tal bug e acaba sendo de forma muito simples:

1. Instale o docker em um sistema com btrfs
2. Utilize o docker intensivamente por um tempo e certifique-se de remover & recriar os containers, rebuild com a opção no cache e reiniciar o sistema, ...
3. Após isso, confira o espaço em disco

 Chris chega a mencionar que não sabe de quem é o bug; se do Docker, ou do driver btrfs "graph" que o Docker utiliza, ou se é um bug do kernel (btrfs) e que pode haver mais de um bug.

Docker consumindo muito armazenamento no Btrfs

 Nikolay Borisov da Suse que isso pode estar relacionado ao comportamento das pessoas não sabendo como utilizar Docker. Nikolay reforça que apenas excluir um container não significa que obterá o espaço livre sendo necessário executar prune -a.

"Eu realizei um monte de testes hoje inciando um container, parando, excluindo-o, podando (pruning) images e tudo funcionou como esperado." Mencionou Nikolay

 Chris diz que agora se questiona se esse é um comportamento único do btrfs graphdriver e que talvez precisam realizar o mesmo conjunto de testes com o btrfs graphdriver, reset, depois repetir a operação  com o overlay2 graphdriver e verificar se há uma diferença significativa.

 No decorrer das semanas veremos se realmente há um problema que irão trabalhar para solucionar ou se trata-se de um falso positivo.

Fonte da informação

Informação obtida do Github

Btrfs Driver no site Docker

VENHA APRENDER LINUX COMIGO :)

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Seja Membro Premuim do Regata OS e ganhe prêmios e suporte

lançado btrfs-progs 4.20.2

Foi lançado ontem a versão 4.20.2 do btrfs-progs. btrfs-progs são as ferramentas que utilizamos no userspace para gerenciar o sistema de arquivos btrfs. É através do btrfs-progs que possuímos as ferramentas que podemos conferir descritas na manpage do btrfs (man 8 btrfs).

Os comandos mencionados em SEE ALSO fazem parte do pacote btrfs-progs

Essa versão trás rápidas correções de um problema com o send/receive path checks que quebram algumas configurações. Como não á correção apropriada ainda, foi feito um regresso. Já há pessoal baixando, testando, conferindo e contribuindo para melhorar esta nova versão.

 Alguns dos comandos do btrfs-progs podem ser conferidos no vídeo abaixo:

Para baixar o tarball, basta clicar aqui

Ou confiram o Git

Github

versão Edge no pub do kernel

Changelog

man page do btrfs em sua wiki

CURSO DE SHELL SCRIPT DO MATEUS MÜLLER
Curso COMPLETO para a certificação CompTIA Linux+ e LPIC-1 do Mateus Müller do canal 4Fasters

Cursos na Udemy

Novidades no Btrfs 5.17

 Essa semana foi lançado o kernel Linux versão 51.6 e muitos sites como o OMG! Ubuntu e o XDE Developers descrevem que os gamers vão amar esta versão devido o recurso de futex2. Particularmente não encontrei essas notas no anuncio do Linus Torvalds. Eu encontrei até mesmo sobre o Batman (batman-adv e b.a.t.m.a.n. Abreviação de better approach to mobile ad-hoc networking) mas não sobre o que são demonstrados nos sites. Esse release está mais relacionado a correções e reversões do que novidades em si.

"Portanto, isso contém principalmente algumas correções de driver (principalmente rede e rdma), uma correção de uso de credencial do cgroup, algumas correções de rede principais, um algumas reversões de última hora e algum outro ruído aleatório. O shortlog anexado é tão pequeno que você também pode rolar isto."

 Bom, mas novidades também estão vindo aí no Btrfs (e provavelmente no kernel 5.17 já anunciado o seu desenvolvimento). David Sterba da equipe do Suse anunciou no dia 11/01/2022 a atualizações do Btrfs 5.17.

NOVOS RECURSOS

 Agora é possível que o send trabalhe com a realocação de grupo de blocos evitando que falhas ocorram; nova operação de exclusão 'balance paused' que, como o próprio nome já diz, permite adicionar um novo dispositivo ao sistema de arquivos com balance em pausa. o Btrfs também está com novo arquivo sysfs para armazenamento do fsid (em per-device directory) que ajuda a distinguir dispositivos quando seeding estiver habilitado.

MELHORIAS NO DESEMPENHO

 A exclusão de diretórios ficou entre 20% a 40% mais rápidos devido; o zoned mode ficou em torno de 50% durante a montagem; indexação e busca por tamanho com a latência de -30% e menos contenção de tree node locking que permite ganho de até 20%. A parte de desempenho já é uma característica muito boa do Btrfs e de longa data. Eu já até mesmo apresentei essa características em vídeos como benchmarks e comparações com ZFS.

CORREÇÕES DE BUGS

 Houveram correções de bugs (lógico) como falha no ENOSPC quando há escrita direta no range NOCOW; na quota de deablock (e outras operações de quotas); no free space tree e no zoned.

OUTRAS

 Houveram também outras melhorias e limpesas como na parte de HDD e SSD, como o file system lida com erros. Essas novidades ocorreram desde o kernel 5.16-rc8 e estarão disponíveis no link abaixo (um total de 115 mudanças).

As novidades do Btrfs poderão ser conferidas aqui.

Mais sobre o sistema de arquivos Btrfs

Mais sobre sistemas de arquivos em geral.

QUER APRENDER BTRFS DE VERDADE? ENTÃO VENHA APRENDER COMIGO ;)

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Seja Membro Premuim do Regata OS e ganhe prêmios e suporte