Saltar para o conteúdo

Btrfs

Origem: Wikipédia, a enciclopédia livre.
Captura de tela das informações de uso de um sistema de arquivos Btrfs
Btrfs
Desenvolvedor Facebook, Fujitsu, Fusion-IO, Intel, Linux Foundation, Netgear, Oracle Corporation, Red Hat, STRATO AG, e SUSE[1]
Nome completo Btrfs
Lançamento Março de 2009 (Linux kernel 2.6.29)
Estruturas
Conteúdos de diretório Árvore B
Alocação de arquivos Extents
Limites
Tamanho Máximo de arquivo 16 EiB
Número máximo de arquivos 264
Tamanho máximo do nome de arquivo 255 caracteres ASCII
Tamanho máximo do volume 16 EiB
Caracteres permitidos em nomes Todos os caracteres, exceto '/' e NUL
Recursos
Resolução de datas Nanossegundo
Atributos POSIX
Permissões de sistema de arquivos POSIX, ACL
Compressão transparente Sim (zlib, LZO[2] e (desde a versão 4.14) ZSTD[3])
Criptografia transparente Planejado[4]
Sistemas operativos suportados Linux, ReactOS
Portal das Tecnologias de informação

Btrfs (B-tree file system) é um sistema de arquivos baseado no princípio cópia em gravação (do inglês copy-on-write (COW)), inicialmente desenvolvido pela Oracle Corporation para ser usado no Linux. O desenvolvimento do Btrfs começou em 2007, e em Agosto de 2014, o formato em disco do sistema de arquivos foi marcado como estável.

Btrfs é projetado para solucionar problemas como falta de agrupamento de discos ou volumes, snapshots (imagem instantânea do sistema de arquivos), checksums (Soma de verificação), e uso de múltiplos volumes simultaneamente nos sistemas de arquivos do Linux. Chris Mason, o principal autor do Btrfs, disse que o objetivo dele foi "fazer o Linux ser escalável para a tecnologia de armazenamento que estará disponível no futuro. Escalar não é só lidar com o armazenamento mas também significa ser capaz de administrá-lo e gerenciá-lo com uma interface limpa que deixa as pessoas verem o que está sendo usado e torná-lo mais confiável."[5]

A estrutura de dados básica do Btrfs —- a árvore-B copy-on-write —- foi originalmente proposta pelo pesquisador da IBM Ohad Rodeh em uma apresentação na USENIX 2007.[6] Chris Mason, um engenheiro que trabalhava no ReiserFS para a SUSE na época, juntou-se a Oracle mais tarde naquele ano e começou a trabalhar em um novo sistema de arquivos baseado na árvore-B.

Em 2008, o principal desenvolvedor dos sistemas de arquivos ext3 e ext4, Theodore Ts'o, disse que apesar do ext4 ter melhorado seus recursos, ele não é um grande avanço, pois usa tecnologia antiga e é considerado um paliativo. Ts'o disse que o Btrfs é a melhor direção porque "oferece melhorias na escalabilidade, confiabilidade e facilidade de gerenciamento".[7] O Btrfs também possui "uma série de ideias de design que reiser3/4 teve".

O Btrfs 1.0, com formato em disco finalizado, foi inicialmente programado para ser lançado no final de 2008, e foi finalmente aceito na linha principal do núcleo Linux em 2009.[8] Várias distribuições Linux começaram a oferecer o Btrfs como uma escolha experimental de sistema de arquivos raiz durante a instalação.[9][10]

Em julho de 2011, a desfragmentação automática e limpeza do Btrfs foram incorporados na versão 3.0 da linha principal do núcleo Linux. Além do Mason na Oracle, Miao Xie, da Fujitsu, contribuiu com melhorias no desempenho. Em junho de 2012, Chris Mason saiu da Oracle para trabalhar na Fusion-io, empresa que ele deixou um ano depois junto com Josef Bacik para se juntar ao Facebook; Enquanto estava em ambas as empresas, Mason continuou seu trabalho no Btrfs.

Em 2012, duas distribuições Linux moveram o Btrfs de status experimental para produção ou suportado: Oracle Linux em março, seguido pelo SUSE Linux Enterprise em agosto.

Em 2015, o Btrfs foi adotado como o sistema de arquivos padrão para o SUSE Linux Enterprise Server 12.[11]

Em agosto de 2017, as notas de lançamento do Red Hat Enterprise Linux (RHEL) 7.4 indicaram que o Btrfs está sendo depreciado; O RHEL 7.4 inclui atualizações para o Btrfs de upstream, mas não há mais atualizações planejadas para serem incluídas, e o Btrfs será removido do Red Hat Enterprise Linux em um lançamento principal futuro.[12] A Suse reafirmou seu compromisso com o Btrfs.[13] O Btrfs foi removido do RHEL 8 em maio de 2019.[14]

Em 2020, o Btrfs foi escolhido como o sistema de arquivos padrão para o Fedora 33.[15]

Implementados

[editar | editar código-fonte]

Na versão 5.0 do núcleo Linux, o Btrfs implementa os seguintes recursos:[16]

  • Na maioria das vezes se auto-recupera em algumas configurações por causa da natureza da cópia em gravação
  • Desfragmentação online e a opção de montagem autodefrag
  • Aumento e redução do volume online
  • Adição e remoção de dispositivo de bloco online
  • Balanceamento online (movimento de objetos entre dispositivos de bloco para balanceamento de carga)
  • Verificação do sistema de arquivos offline
  • Verificação de dados on-line para encontrar erros e corrigi-los automaticamente para arquivos com cópias redundantes
  • RAID 0, RAID 1,RAID 10
  • Subvolumes (um ou mais raízes de sistemas de arquivos montáveis separadamente dentro de cada partição de disco)
  • Compressão de forma transparente via zlib, LZO e (desde 4.14) ZSTD, configurável por arquivo ou volume
  • Instantâneos de subvolumes somente leitura ou gravável atomicamente (via cópia em gravação)[17]
  • Clonagem de arquivo (cópia em gravação em arquivos individuais) via cp --reflink <aqruivo de origem> <arquivo de destino>[18]
  • Somas de verificação em dados e metadados (CRC-32C)
  • Conversão no local de ext3/4 para Btrfs (com reversão). Esse recurso teve regressões na versão 4.0 da ferramenta btrfs-progs, sendo reescrito do zero na versão 4.6.[19]
  • Montagem de união de armazenamento somente leitura, conhecida como semeadura de sistema de arquivos (armazenamento somente leitura usado como suporte de cópia em gravação para um sistema Btrfs gravável)[20]
  • Descarte de blocos (recupera espaço em ambientes virtualizados e melhora o nivelamento da escrita em SSDs com TRIM)
  • Enviar (send)/receber (receive) (salvar diferenças entre instantâneos para um fluxo binário)[21]
  • Backup incremental
  • Desduplicação de dados fora de banda (requer ferramentas de espaço de usuário)[22]
  • Capacidade de lidar com arquivos de troca e partições de troca[23]

Implementado, mas não recomendado para uso em produção

[editar | editar código-fonte]
  • Cotas por subvolume hierarquizadas[24]
  • RAID 5, RAID 6[25]

Planejados, mas ainda não implementados[16]

[editar | editar código-fonte]

Em 2009, foi esperado que o Btrfs oferecesse um conjunto de recursos comparável ao ZFS, desenvolvido pela Sun Microsystems.[28] Após a aquisição da Sun pela Oracle em 2009, Mason e a Oracle decidiram continuar com o desenvolvimento do Btrfs.[29]

O Btrfs fornece uma operação clonar que atomicamente cria um instantâneo de cópia em gravação de um arquivo. Esses arquivos clonados às vezes são chamados de "reflinks", à luz das chamadas de sistema do kernel do Linux associadas.[30]

Através da clonagem, o sistema de arquivos não cria um novo link apontando para um inode existente; Em vez disso, ele cria um novo inode que inicialmente compartilha os mesmos blocos de disco com o arquivo original. Como resultado, a clonagem funciona apenas dentro dos limites do mesmo sistema de arquivos Btrfs, mas desde a versão 3.6 do kernel do Linux pode cruzar os limites de subvolumes em certas circunstâncias.[31][32] Os blocos de dados reais não são duplicados; ao mesmo tempo, devido à natureza de cópia em gravação (CoW) do Btrfs, as modificações em qualquer um dos arquivos clonados não são visíveis no arquivo original e vice-versa.[33]

A clonagem não deve ser confundida com links rígidos , que são entradas de diretório que associam vários nomes de arquivos com arquivos reais em um sistema de arquivos. Embora os links rígidos possam ser considerados como nomes diferentes para o mesmo arquivo, a clonagem no Btrfs fornece arquivos independentes que compartilham seus blocos de disco.[33][34]

O suporte para este recurso do Btrfs foi adicionado na versão 7.5 do GNU coreutils , através da opção --reflink para o comando cp.[35][36]

Subvolumes e instantâneos

[editar | editar código-fonte]

Um subvolume Btrfs pode ser considerado como um espaço de nome de arquivo POSIX separado, montável separadamente passando as opções subvol ou subvolid para o utilitário mount. Também pode ser acessado montando o subvolume de nível superior, nesse caso os subvolumes são visíveis e acessíveis como subdiretórios dele.[37]

Subvolumes podem ser criados em qualquer lugar dentro da hierarquia do sistema de arquivos, e eles também podem ser aninhados. Os subvolumes aninhados aparecem como subdiretórios em seus subvolumes pais, de forma semelhante à forma como um subvolume de nível superior apresenta seus subvolumes como subdiretórios. A exclusão de um subvolume não é possível até que todos os subvolumes abaixo dele na hierarquia de aninhamento sejam excluídos; como resultado, subvolumes de nível superior não podem ser excluídos.[38]

Qualquer sistema de arquivos Btrfs sempre tem um subvolume padrão, que inicialmente é configurado para ser o subvolume de nível superior e é montado por padrão se nenhuma opção de seleção de subvolume for passada para mount . O subvolume padrão pode ser alterado conforme necessário.[38]

Um instantâneo do Btrfs é um subvolume que compartilha seus dados (e metadados) com algum outro subvolume, usando os recursos de cópia-em-gravação do Btrfs e as modificações em um instantâneo não são visíveis no subvolume original. Uma vez que um instantâneo gravável é feito, ele pode ser tratado como uma versão alternativa do sistema de arquivos original. Por exemplo, para reverter para um instantâneo, um subvolume original modificado precisa ser desmontado e o instantâneo precisa ser montado em seu lugar. Nesse momento, o subvolume original também pode ser excluído.[37]

A natureza de cópia em gravação (CoW) do Btrfs significa que instantâneos são criados rapidamente, enquanto inicialmente consomem muito pouco espaço em disco. Uma vez que um instantâneo é um subvolume, a criação de instantâneos aninhados também é possível. Tirar instantâneos de um subvolume não é um processo recursivo; Assim, se um instantâneo de um subvolume for criado, cada subvolume ou instantâneo que o subvolume já contém é mapeado para um diretório vazio com o mesmo nome dentro do instantâneo.[37][38]

Tirar instantâneos de um diretório não é possível, pois apenas subvolumes podem ter instantâneos. No entanto, há uma solução alternativa que envolve reflinks espalhados por subvolumes: um novo subvolume é criado, contendo reflinks de subvolume cruzado para o conteúdo do diretório segmentado. Tendo disponível, um instantâneo desse novo volume pode ser criado.[31]

Um subvolume no Btrfs é bastante diferente de um volume lógico tradicional LVM (Logical Volume Manager). Com o LVM, um volume lógico é um dispositivo de bloco separado, enquanto um subvolume Btrfs não é e não pode ser tratado ou usado desse jeito.[37] Fazer instantâneos do btrfs com dd ou LVM leva à perda de dados se ou o original ou a cópia é montada enquanto ambos estiverem no mesmo computador.[39]

Dado qualquer par de subvolumes (ou instantâneos), o Btrfs pode gerar uma diferença binária entre eles (usando o comando btrfs send) que pode ser reproduzido mais tarde (usando btrfs receive), possivelmente em um sistema de arquivos Btrfs diferente. O recurso de envio/recebimento efetivamente cria (e aplica) um conjunto de modificações de dados necessárias para converter um subvolume em outro.[21][40]

O recurso de envio/recebimento pode ser usado com snapshots agendados regularmente para implementar uma forma simples de replicação mestre/escrava do sistema de arquivos, ou com a finalidade de realizar backups incrementais.[21][40]

Grupos de cotas

[editar | editar código-fonte]

Um grupo de cota (ou qgroup) impõe um limite superior ao espaço que um subvolume ou instantâneo podem consumir. Um novo instantâneo inicialmente não consome cotas porque seus dados são compartilhados com seu pai, mas, posteriormente, incorre em cobrança por novos arquivos e operações de cópia em gravação em arquivos existentes. Quando as cotas estão ativas, um grupo de cota é criado automaticamente com cada novo subvolume ou instantâneo. Esses grupos de cotas iniciais são blocos de construção que podem ser agrupados (com o comando btrfs qgroup) em hierarquias para implementar pools de cota.[24]

Os grupos de cotas só se aplicam a subvolumes e instantâneos, enquanto não é possível ter cotas aplicadas em subdiretórios individuais, usuários ou grupos de usuários. No entanto, existem soluções alternativas, como usar diferentes subvolumes para todos os usuários ou grupos de usuários que exigem uma cota para ser aplicada.

Conversão no local a partir de ext2/3/4 e reiserfs

[editar | editar código-fonte]

Como resultado de ter muito pouco metadados ancorados em locais fixos, o Btrfs pode se deformar para se adequar a layouts espaciais incomuns dos dispositivos de armazenamento. A ferramenta btrfs-convert explora essa capacidade de fazer uma conversão no local de qualquer sistema de arquivos ext2/3/4, aninhando os metadados Btrfs equivalentes em seu espaço não alocado — preservando uma cópia não modificada do sistema de arquivos original.[41]

A conversão envolve a criação de uma cópia de todos os metadados ext2/3/4, enquanto os arquivos no Btrfs simplesmente apontam para os mesmos blocos usados pelos arquivos no ext2/3/4. Isso faz com que a maior parte dos blocos sejam compartilhados entre os dois sistemas de arquivos antes que a conversão se torne permanente. Graças à natureza de cópia em gravação do Btrfs, as versões originais dos blocos de dados do arquivo são preservadas durante todas as modificações de arquivos. Até a conversão se tornar permanente, apenas os blocos marcados como livres em ext2/3/4 são usados para manter novas modificações do Btrfs, o que significa que a conversão pode ser desfeita em qualquer momento (embora, ao fazer isso, irá apagar as alterações feitas depois da conversão para Btrfs).[41]

Todos os arquivos convertidos estão disponíveis e podem ser gravados no subvolume padrão do Btrfs. Um arquivo esparso que contém todas as referências ao sistema de arquivos ext2/3/4 original é criado em um subvolume separado, que pode ser montado por conta própria como uma imagem de disco somente leitura, permitindo que os sistemas de arquivos originais e convertidos sejam acessados no mesmo tempo. A exclusão deste arquivo esparso libera o espaço em disco e torna a conversão permanente.[41]

A partir de junho de 2015 e versões 4.x da árvore principal do kernel do Linux, a conversão no local ext3/4 foi considerada não testada e raramente usada.[41] Esse recurso, no entanto, foi reescrito a partir do zero no btrfs-progs versão 4.6.[19] e é considerado estável desde então.

A conversão no local a partir do ReiserFS foi introduzida em setembro de 2017 com o kernel 4.13.

Montagem de união/dispositivo de semente

[editar | editar código-fonte]

Ao criar um novo Btrfs, um Btrfs existente pode ser usado como um sistema de arquivos de "semente" somente leitura.[42] O novo sistema de arquivos atuará como uma sobreposição de cópia em gravação na semente, como uma forma de montagem de união. A semente pode ser mais tarde separada do Btrfs, neste momento o rebalanceador simplesmente irá copiar quaisquer dados da semente ainda referenciados nela para o novo sistema de arquivos antes da separação. Mason sugeriu que isso pode ser útil para um instalador em Live CD, que pode ser iniciado a partir de uma semente Btrfs somente leitura em um disco óptico, rebalancear-se para a partição de destino no disco de instalação em segundo plano enquanto o usuário continua trabalhando e, em seguida, ejetar o disco para completar a instalação sem reiniciar o computador.[43]

Em sua entrevista de 2009, Chris Mason afirmou que o suporte à criptografia estava planejado para a Btrfs.[4] Enquanto isso, uma solução para combinar criptografia com o Btrfs é usar um mecanismo de criptografia de disco completo, como dm-crypt/LUKS, nos dispositivos subjacentes e criar o sistema de arquivos Btrfs em cima dessa camada.

Verificação e recuperação

[editar | editar código-fonte]

Os sistemas Unix tradicionalmente dependem de programas "fsck" para verificar e reparar sistemas de arquivos. Esta funcionalidade é implementada através do programa btrfs check. Desde a versão 4.0, essa funcionalidade é considerada relativamente estável. No entanto, a partir de agosto de 2017, a documentação do btrfs sugere que ela seja usada somente depois de ter tentado outros métodos de recuperação.[44]

Existe outra ferramenta, chamada btrfs-restore, que pode ser usada para recuperar arquivos de um sistema de arquivos não montável, sem modificar o próprio sistema de arquivos quebrado (ou seja, de forma não destrutiva).[45]

Em uso normal, o Btrfs é principalmente auto-curativo e pode se recuperar de árvores raiz quebradas em tempo de montagem, graças à gravação periódica dos dados no armazenamento permanente, por padrão, a cada 30 segundos. Assim, erros isolados causarão um máximo de 30 segundos de alterações no sistema de arquivos a serem perdidas na próxima montagem.[46] Este período pode ser alterado especificando o valor desejado (em segundos) para a opção de montagem commit.[47][48]

Suporte comercial

[editar | editar código-fonte]

Não mais suportado

[editar | editar código-fonte]

Referências

  1. «Btrfs Contributors at kernel.org» (em inglês). kernel.org. 18 de janeiro de 2016. Consultado em 20 de janeiro de 2016 
  2. «btrfs Wiki». kernel.org. Consultado em 19 de abril de 2015 
  3. https://kernelnewbies.org/Linux_4.14
  4. a b Amanda McPherson (22 de junho de 2009). «A Conversation with Chris Mason on BTRfs: the next generation file system for Linux». Linux Foundation. Consultado em 9 de outubro de 2014. Arquivado do original em 24 de junho de 2012. In future releases we plan to add online fsck, deduplication, encryption and other features that have been on admin wish lists for a long time. 
  5. Kerner, Sean Michael (30 de outubro de 2008). «A Better File System for Linux?» (em inglês). www.internetnews.com. Consultado em 2 de agosto de 2017 
  6. Rodeh, Ohad (2007). B-trees, shadowing, and clones (PDF). USENIX Linux Storage & Filesystem Workshop (em inglês)  E Rodeh, Ohad (2008). «B-trees, shadowing, and clones». ACM Transactions on Storage (em inglês) 
  7. Ryan Paul (14 de abril de 2009). «Panelists ponder the kernel at Linux Collaboration Summit» (em inglês). Ars Technica. Consultado em 2 de agosto de 2017 
  8. Britta Wuelfing (12 de janeiro de 2009). «Kernel 2.6.29: Corbet Says Btrfs Next Generation Filesystem» (em inglês). Linux Magazine. Consultado em 16 de agosto de 2017 
  9. «Debian 6.0 "Squeeze" lançado». 6 de fevereiro de 2011. Consultado em 16 de agosto de 2017 
  10. a b «Red Hat Enterprise Linux 6.1 Technical Notes» (em inglês). Consultado em 16 de agosto de 2017 
  11. «SUSE Linux Enterprise Server 12 Release Notes» (em inglês). 6 de abril de 2016. Consultado em 16 de agosto de 2017 
  12. a b «Red Hat Enterprise Linux 7.4 Release Notes, Chapter 53: Deprecated Functionality» (em inglês). 1 de agosto de 2017. Consultado em 16 de agosto de 2017 
  13. mge1512 (23 de agosto de 2017). «Butter bei die Fische!». suse.com. Consultado em 24 de agosto de 2017 
  14. a b «Chapter 12. File systems and storage». Red Hat Customer Portal (em inglês). Consultado em 5 de junho de 2019 
  15. «Btrfs Coming to Fedora 33». Fedora Magazine. 24 de agosto de 2020. Consultado em 27 de outubro de 2020 
  16. a b «Btrfs Wiki: Features» (em inglês). 27 de novembro de 2013. Consultado em 2 de agosto de 2017 
  17. «btrfs: Readonly snapshots». Consultado em 12 de dezembro de 2011 
  18. «Save disk space on Linux by cloning files on Btrfs and OCFS2». Consultado em 1 de agosto de 2017 
  19. a b «Btrfs progs release 4.6» (em inglês). Consultado em 1 de agosto de 2017 
  20. Mason, Chris (12 de janeiro de 2009). «Btrfs changelog». Consultado em 12 de fevereiro de 2012 
  21. a b c Corbet, Jonathan (11 de julho de 2012). «Btrfs send/receive». LWN.net. Consultado em 14 de novembro de 2012 
  22. «Btrfs Wiki: Deduplication». 13 de setembro de 2013. Consultado em 27 de novembro de 2013 
  23. a b «Btrfs Project ideas». 21 de fevereiro de 2013. Consultado em 21 de fevereiro de 2013 
  24. a b Jansen, Arne (2011), Btrfs Subvolume Quota Groups (PDF), Strato AG, consultado em 14 de novembro de 2012 
  25. btrfs (16 de julho de 2016). «RAID 5/6». kernel.org. Consultado em 1 de outubro de 2016 
  26. Corbet, Jonathan (2 de novembro de 2011). «A btrfs updata at LinuxCon Europe». Consultado em 12 de fevereiro de 2012 
  27. Mazzoleni, Andrea. «btrfs: lib: raid: New RAID library supporting up to six parities». Consultado em 16 de março de 2014 
  28. Aurora, Valerie (22 de julho de 2009). «A short history of btrfs». LWN.net. Consultado em 5 de novembro de 2011 
  29. Hilzinger, Marcel (22 de abril de 2009). «Future of Btrfs Secured». Linux Magazine. Consultado em 5 de novembro de 2011 
  30. a b «UseCases – btrfs documentation». kernel.org. Consultado em 4 de novembro de 2013 
  31. «btrfs: allow cross-subvolume file clone». github.com. Consultado em 4 de novembro de 2013 
  32. Meyering, Jim (20 de agosto de 2009). «GNU coreutils NEWS: Noteworthy changes in release 7.5». savannah.gnu.org. Consultado em 30 de agosto de 2009 
  33. a b c d «SysadminGuide – Btrfs documentation». kernel.org. Consultado em 31 de outubro de 2013 
  34. a b c «5.6 Creating Subvolumes and Snapshots». oracle.com. 2013. Consultado em 31 de outubro de 2013 
  35. https://btrfs.wiki.kernel.org/index.php/Gotchas#Block-level_copies_of_devices
  36. a b «5.7 Using the Send/Receive Feature». oracle.com. 2013. Consultado em 31 de outubro de 2013 
  37. a b c d Mason, Chris (25 de junho de 2015). «Conversion from Ext3 (Btrfs documentation)». kernel.org. Consultado em 22 de abril de 2016 
  38. «Seed device» 
  39. Mason, Chris (5 de abril de 2012). «Btrfs Filesystem: Status and New Features». Linux Foundation. Consultado em 16 de novembro de 2012 
  40. «btrfsck» 
  41. «Restore» 
  42. «Problem FAQ - btrfs Wiki». kernel.org. 31 de julho de 2013. Consultado em 16 de janeiro de 2014 
  43. «kernel/git/torvalds/linux.git: Documentation: filesystems: add new btrfs mount options (Linux kernel source tree)». kernel.org. 21 de novembro de 2013. Consultado em 6 de fevereiro de 2014 
  44. «Mount options - btrfs Wiki». kernel.org. 12 de novembro de 2013. Consultado em 16 de janeiro de 2014 
  45. «Oracle Now Supports Btrfs RAID5/6 On Their Unbreakable Enterprise Kernel - Phoronix». www.phoronix.com (em inglês) 
  46. «SUSE reaffirms support for Btrfs [LWN.net]». lwn.net (em inglês) 
  47. «Release Notes | SUSE Linux Enterprise Server 15 GA». www.suse.com (em inglês) 
  48. «DiskStation Manager - Knowledge Base | Synology Inc.». www.synology.com (em inglês) 
  49. «BionicBeaver/ReleaseNotes - Ubuntu Wiki». wiki.ubuntu.com (em inglês) 
  50. «ReactOS File systems support». reactos.org/wiki/ (em inglês) 
  51. «Btrfs Coming to Fedora 33». fedoramagazine.org (em inglês). 24 de agosto de 2020. Consultado em 29 de abril de 2021 
  52. «What's new in Fedora 33 Workstation». fedoramagazine.org (em inglês). 28 de outubro de 2020. Consultado em 29 de abril de 2021 
  53. «⁠Btrfs has been deprecated in RHEL | Hacker News». news.ycombinator.com (em inglês) 
  54. «Red Hat Appears To Be Abandoning Their Btrfs Hopes - Phoronix». www.phoronix.com (em inglês) 

Ligações Externas

[editar | editar código-fonte]