Btrfs

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

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

• Cotas por subvolume hierarquizadas^[24]
• RAID 5, RAID 6^[25]

Planejados, mas ainda não implementados^[16]

• Desduplicação de dados em-banda
• Verificação do sistema de arquivos on-line^[26]
• RAID com até seis dispositivos de paridade, superando a confiabilidade do RAID 5 e RAID 6^[27]
• RAID 0, RAID 1 e RAID 10 a nível de objeto
• Criptografia^[23]

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]

Clonagem

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

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]

Send-receive

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

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

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

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]

Criptografia

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

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]

Suportado

• Oracle Linux 7^[49]
• SUSE Linux Enterprise Server 15^[50][51]
• Synology Inc. DiskStation Manager (DSM) v6^[52]
• Ubuntu^[53]
• ReactOS^[54]
• Fedora Linux^[55][56]

Não mais suportado

• Btrfs foi incluído como "technology preview" no Red Hat Enterprise Linux 6 e 7; ele foi removido no RHEL 8 em 2018.^{[10][12][14][57][58]}

• APFS, sistema de arquivos baseado em cópia em gravação da Apple para macOS, iOS, tvOS e watchOS
• HAMMER, sistema de arquivos semelhante para DragonFly BSD
• LVM - Logical Volume Manager (para Linux), suporta instantâneos (snapshots)
• ReFS – sistema de arquivos baseado em cópia em gravação da Microsoft para Windows Server 2012, que têm suporte à resiliência a danos
• Reiser4
• ZFS, sistema de arquivos semelhante para FreeBSD, Linux, OpenSolaris e Solaris

• Sítio oficial