O que é Btrfs?
Btrfs (pronunciado como "better F S", "butter F S", "b-tree F S" ou B.T.R.F.S.) é um formato de armazenamento de computador que combina um sistema de arquivos baseado no princípio copy-on-write (COW) com um gerenciador de volume lógico (distinto do LVM do Linux), desenvolvido em conjunto. Foi criado por Chris Mason em 2007 para uso no Linux e, desde novembro de 2013, o formato em disco do sistema de arquivos foi declarado estável no kernel do Linux.
O Btrfs tem como objetivo abordar a falta de pooling, snapshots, checksums e abrangência integral de vários dispositivos em sistemas de arquivos Linux. Mason, o principal autor do Btrfs, declarou que seu objetivo era "deixar [o Linux] escalar para o armazenamento que estará disponível. Escalar não é apenas abordar o armazenamento, mas também significa ser capaz de administrá-lo e gerenciá-lo com uma interface limpa que permite que as pessoas vejam o que está sendo usado e o torna mais confiável".
Histórico
A estrutura de dados central do Btrfs—a árvore B copy-on-write—foi originalmente proposta pelo pesquisador da IBM Ohad Rodeh em uma conferência da USENIX em 2007. Mason, um engenheiro que trabalhava no ReiserFS para SUSE na época, juntou-se à Oracle mais tarde naquele ano e começou a trabalhar em um novo sistema de arquivos baseado nessas árvores B.
Em 2008, o principal desenvolvedor dos sistemas de arquivos ext3 e ext4, Theodore Ts'o, declarou que, embora o ext4 tenha recursos aprimorados, não é um grande avanço; ele usa tecnologia antiga e é uma solução paliativa. Ts'o disse que o Btrfs é a melhor direção porque "oferece melhorias em escalabilidade, confiabilidade e facilidade de gerenciamento". O Btrfs também tem "várias das mesmas ideias de design que o reiser3/4 tinha".
O Btrfs 1.0, com formato finalizado em disco, foi originalmente programado para ser lançado no final de 2008 e foi finalmente aceito na linha principal do kernel Linux em 2009. Várias distribuições Linux começaram a oferecer o Btrfs como uma escolha experimental de sistema de arquivos raiz durante a instalação.
Em julho de 2011, os recursos de desfragmentação e depuração automática do Btrfs foram mesclados na versão 3.0 da linha principal do kernel Linux. Além de Mason na Oracle, Miao Xie na Fujitsu contribuiu com melhorias de desempenho. Em junho de 2012, Mason deixou a Oracle para a Fusion-io, que ele deixou um ano depois 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 do status experimental para o status de 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 (SLE) 12.
Em agosto de 2017, a Red Hat anunciou nas notas de lançamento do Red Hat Enterprise Linux (RHEL) 7.4 que não planejava mais mover o Btrfs para um recurso totalmente suportado (ele foi incluído como uma "prévia de tecnologia" desde o RHEL 6 beta), observando que permaneceria disponível na série de lançamentos do RHEL 7. O Btrfs foi removido do RHEL 8 em maio de 2019. O RHEL mudou de ext4 no RHEL 6 para XFS no RHEL 7.
Em 2020, o Btrfs foi selecionado como o sistema de arquivos padrão para o Fedora 33 para variantes de desktop.
Recursos
Lista de recursos
Implementado
A partir da versão 6.0 do kernel Linux, o Btrfs implementa os seguintes recursos:
- 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>
- 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.
- 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)
- 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)
- Backup incremental
- Desduplicação de dados fora de banda (requer ferramentas de espaço de usuário)
- Capacidade de lidar com arquivos de troca e partições de troca
Implementado, mas não recomendado para uso em produção
- Cotas por subvolume hierarquizadas
- RAID 5, RAID 6
Planejados, mas ainda não implementados
- 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
- RAID 0, RAID 1 e RAID 10 a nível de objeto
- Criptografia
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.
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.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.
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.
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.
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.
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.
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.
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.
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.
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.
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. 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.
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.
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.
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.
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.
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).
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.
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. Esse recurso, no entanto, foi reescrito a partir do zero no btrfs-progs versão 4.6 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.
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.
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).
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. Este período pode ser alterado especificando o valor desejado (em segundos) para a opção de montagem commit.
Suporte comercial
Suportado
- Oracle Linux 7
- SUSE Linux Enterprise Server 15
- Synology Inc. DiskStation Manager (DSM) v6
- Ubuntu
- ReactOS
- Fedora Linux
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.
Comentários
Postar um comentário