Btrfs - Btrfs

Btrfs
Desenvolvedor (s) Facebook , Fujitsu , Fusion-IO , Intel , Linux Foundation , Netgear , Oracle Corporation , Red Hat , STRATO AG e openSUSE
Nome completo Sistema de arquivos B-tree
Introduzido Kernel do Linux 2.6.29, março de 2009 ; Há 12 anos ( 2009-03 )
Estruturas
Conteúdo do diretório Árvore B
Alocação de arquivo Extensões
Limites
Máx. tamanho do volume 16  EiB
Máx. tamanho do arquivo 16 EiB
Máx. número de arquivos 2 64
Máx. comprimento do nome do arquivo 255 caracteres ASCII (menos para codificações de caracteres multibyte , como Unicode )
Caracteres permitidos em nomes de arquivos Todos exceto '/'e NUL( '\0')
Recursos
Datas gravadas Criação (otime), modificação (mtime), modificação de atributo (ctime) e acesso (atime)
Intervalo de datas Deslocamento interno assinado de 64 bits de 1970-01-01T00: 00: 00Z
Resolução de data Nanossegundo
Atributos POSIX e atributos estendidos
Permissões do sistema de arquivos POSIX e ACL
Compressão transparente Sim ( zlib , LZO e (desde 4.14) ZSTD )
Criptografia transparente Planejado
Desduplicação de dados sim
Copy-on-write sim
De outros
Sistemas operacionais suportados Linux , ReactOS
Local na rede Internet btrfs .wiki .kernel .org Edite isso no Wikidata

Btrfs (pronunciado como "best F S", "butter F S", "b-tree F S" ou simplesmente soletrando) é um formato de armazenamento de computador que combina um sistema de arquivos baseado no princípio de cópia na gravação (COW) com um gerenciador de volume lógico (não deve ser confundido com o LVM do Linux ), desenvolvido em conjunto. Ele foi inicialmente projetado na Oracle Corporation 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. De acordo com a Oracle, Btrfs "não é uma sigla verdadeira".

O Btrfs destina-se a resolver a falta de pooling , instantâneos , somas de verificação e abrangência integral de vários dispositivos nos sistemas de arquivos Linux . Chris Mason, o principal autor do Btrfs, afirmou que seu objetivo era "deixar [Linux] escalar para o armazenamento que estará disponível. O escalonamento não é apenas abordar o armazenamento, mas também significa ser capaz de administrar e gerenciá-lo com uma interface que permite que as pessoas vejam o que está sendo usado e o torna mais confiável ".

História

Captura de tela das informações de uso de um sistema de arquivos Btrfs

A estrutura de dados central do Btrfs‍ — ‌a árvore B copy-on-write ‍ — ‌foi originalmente proposta pelo pesquisador da IBM Ohad Rodeh em uma apresentação na USENIX 2007. Chris 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 , afirmou que, embora o ext4 tenha recursos aprimorados, não é um grande avanço; ele usa tecnologia antiga e é um paliativo. 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 "algumas das mesmas idéias de design que o reiser3 / 4 tinha".

O Btrfs 1.0, com o formato em disco finalizado, foi originalmente programado para um lançamento no final de 2008 e foi finalmente aceito na linha principal do kernel do Linux em 2009. Várias distribuições do 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 incorporados à versão 3.0 da linha principal do kernel do Linux . Além de Mason na Oracle, Miao Xie na Fujitsu contribuiu com melhorias de desempenho. Em junho de 2012, Chris Mason trocou a Oracle pela Fusion-io , que deixou um ano depois com Josef Bacik para ingressar no Facebook . Enquanto em ambas as empresas, Mason continuou seu trabalho na Btrfs.

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

Em 2015, o Btrfs foi adotado como sistema de arquivos padrão para o SUSE Linux Enterprise Server 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, que havia sido incluído como uma "amostra de tecnologia" desde o RHEL 6 beta, para um recurso totalmente compatível, observando que permaneceria disponível na série de lançamento RHEL 7. O Btrfs foi removido do RHEL 8 em maio de 2019.

Em 2020, o Btrfs foi selecionado como o sistema de arquivos padrão para o Fedora 33 para variantes de desktop.

Recursos

Implementado

A partir da versão 5.0 do kernel Linux, o Btrfs implementa os seguintes recursos:

  • Principalmente de autocorreção em algumas configurações devido à natureza do copy-on-write
  • Desfragmentação online e uma opção de montagem autodefrag
  • Aumento e redução do volume online
  • Adição e remoção de dispositivos de bloqueio online
  • Balanceamento online (movimento de objetos entre dispositivos de bloco para balancear a carga)
  • Verificação do sistema de arquivos offline
  • Limpeza de dados online para encontrar erros e corrigi-los automaticamente para arquivos com cópias redundantes
  • RAID 0 , RAID 1 e RAID 10
  • Subvolumes (uma ou mais raízes do sistema de arquivos montáveis ​​separadamente dentro de cada partição do disco )
  • Compressão transparente via zlib , LZO e (desde 4.14) ZSTD , configurável por arquivo ou volume
  • Atomic gravável (via cópia na gravação) ou instantâneos somente leitura de subvolumes
  • Clonagem de arquivo ( reflink , copy-on-write) viacp --reflink <source file> <destination file>
  • Soma de verificação de dados e metadados ( CRC-32C ). Novas funções hash são implementadas desde 5.5: xxHash , SHA256 , BLAKE2B .
  • Conversão local de ext3 / 4 para Btrfs (com reversão). Este recurso regrediu em torno do btrfs-progs versão 4.0, reescrito do zero na 4.6.
  • Montagem de união de armazenamento somente leitura, conhecido como propagação do sistema de arquivos (armazenamento somente leitura usado como backup de cópia na gravação para um Btrfs gravável)
  • Descarte de blocos (recupera espaço em algumas configurações virtualizadas e melhora o nível de desgaste em SSDs com TRIM )
  • Enviar / receber (salvando diferenças entre instantâneos em um fluxo binário)
  • Backup incremental
  • Desduplicação de dados fora de banda (requer ferramentas de espaço do usuário)
  • Capacidade de lidar com arquivos de troca e partições de troca

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

Planejado, mas ainda não implementado

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

Clonagem

O Btrfs fornece uma operação de clone que cria atomicamente um instantâneo de cópia na gravação de um arquivo . Esses arquivos clonados às vezes são chamados de reflinks , à luz da chamada de sistema do kernel Linux associada proposta .

Ao clonar, 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 sob certas circunstâncias. Os blocos de dados reais não são duplicados; ao mesmo tempo, devido à natureza de cópia na 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 físicos , que são entradas de diretório que associam vários nomes de arquivo a arquivos reais em um sistema de arquivos. Embora os links físicos possam ter nomes diferentes para o mesmo arquivo, a clonagem em Btrfs fornece arquivos independentes que inicialmente compartilham todos os seus blocos de disco.

O suporte para este recurso Btrfs foi adicionado na versão 7.5 do GNU coreutils , por meio da --reflinkopção do cpcomando.

Além da clonagem de dados ( FICLONE ), o Btrfs também oferece suporte para desduplicação fora da banda via FIDEDUPERANGE . Essa funcionalidade permite que dois arquivos com dados (mesmo parcialmente) idênticos compartilhem o armazenamento.

Subvolumes e instantâneos

Exemplo de instantâneos de um sistema de arquivos Btrfs, gerenciado com snapper

Um subvolume Btrfs pode ser considerado como um namespace de arquivo POSIX separado , montável separadamente passando subvolou subvolidopções para o mount(8)utilitário. Ele também pode ser acessado montando o subvolume de nível superior, caso em que os subvolumes são visíveis e acessíveis como seus subdiretórios.

Os subvolumes podem ser criados em qualquer lugar dentro da hierarquia do sistema de arquivos e também podem ser aninhados. Os subvolumes aninhados aparecem como subdiretórios dentro de seus subvolumes pais, da mesma forma que 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, os subvolumes de nível superior não podem ser excluídos.

Qualquer sistema de arquivos Btrfs sempre tem um subvolume padrão, que é inicialmente definido como 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 Btrfs é um subvolume que compartilha seus dados (e metadados) com algum outro subvolume, usando os recursos de cópia na gravação do Btrfs, e as modificações em um instantâneo não são visíveis no subvolume original. Depois 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 ponto, o subvolume original também pode ser excluído.

A natureza de cópia na gravação (CoW) do Btrfs significa que os instantâneos são criados rapidamente, enquanto inicialmente consomem muito pouco espaço em disco. Como 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; portanto, se um instantâneo de um subvolume é 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 os 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 de destino. Tendo isso disponível, um instantâneo deste novo volume pode ser criado.

Um subvolume em Btrfs é bastante diferente de um volume lógico LVM ( Logical Volume Manager ) tradicional . 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 dessa forma. Fazer snapshots de dd ou LVM de btrfs leva a perda de dados se o original ou a cópia forem montados enquanto ambos estão no mesmo computador.

Enviar receber

Dado qualquer par de subvolumes (ou instantâneos), o Btrfs pode gerar um diff binário entre eles (usando o btrfs sendcomando) que pode ser reproduzido posteriormente (usando btrfs receive), possivelmente em um sistema de arquivos Btrfs diferente. O recurso de envio / recebimento cria (e aplica) efetivamente um conjunto de modificações de dados necessárias para converter um subvolume em outro.

O recurso de envio / recebimento pode ser usado com instantâneos programados regularmente para implementar uma forma simples de replicação do sistema de arquivos ou com o propósito de realizar backups incrementais .

Grupos de cotas

Exemplo de grupos de cotas Btrfs

Um grupo de cotas (ou qgroup ) impõe um limite superior para o espaço que um subvolume ou instantâneo pode consumir. Um novo instantâneo inicialmente não consome cota porque seus dados são compartilhados com seu pai, mas depois disso incorre em cobrança de novos arquivos e operações de cópia na gravação em arquivos existentes. Quando as cotas estão ativas, um grupo de cotas é 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 btrfs qgroupcomando) em hierarquias para implementar pools de cotas.

Os grupos de cotas se aplicam apenas a subvolumes e instantâneos, embora não seja possível impor cotas a subdiretórios, usuários ou grupos de usuários individuais. No entanto, soluções alternativas são possíveis usando subvolumes diferentes para todos os usuários ou grupos de usuários que exigem a aplicação de uma cota.

Conversão in-loco de ext2 / 3/4 e ReiserFS

Como resultado de ter muito poucos metadados ancorados em locais fixos, o Btrfs pode deformar para se ajustar a layouts espaciais incomuns dos dispositivos de armazenamento de backend. A btrfs-convertferramenta explora essa capacidade de fazer uma conversão in-loco de um sistema de arquivos ext2 / 3/4 ou ReiserFS , aninhando os metadados Btrfs equivalentes em seu espaço não alocado - enquanto preserva 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 Btrfs simplesmente apontam para os mesmos blocos usados ​​pelos arquivos 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 copy-on-write do Btrfs, as versões originais dos blocos de dados do arquivo são preservadas durante todas as modificações do arquivo. Até que a conversão se torne permanente, apenas os blocos que foram marcados como livres em ext2 / 3/4 são usados ​​para conter novas modificações do Btrfs, o que significa que a conversão pode ser desfeita a qualquer momento (embora isso apague quaisquer alterações feitas após a 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 contendo todas as referências ao sistema de arquivos ext2 / 3/4 original é criado em um subvolume separado, que pode ser montado sozinho como uma imagem de disco somente leitura, permitindo que os sistemas de arquivos originais e convertidos sejam acessados ​​no mesmo tempo. A exclusão desse arquivo esparso libera espaço e torna a conversão permanente.

Nas versões 4.x do kernel Linux principal, a conversão ext3 / 4 no local era considerada não testada e raramente usada. No entanto, o recurso foi reescrito do zero em 2016 para btrfs-progs4.6. e tem sido considerado estável desde então.

A conversão in-loco do ReiserFS foi introduzida em setembro de 2017 com o kernel 4.13.

Dispositivos de montagem / semente de união

Ao criar um novo Btrfs, um Btrfs existente pode ser usado como um sistema de arquivos "seed" somente leitura. O novo sistema de arquivos agirá então como uma sobreposição de cópia na gravação no seed, como uma forma de montagem de união . A semente pode ser desanexada posteriormente do Btrfs, ponto em que o rebalanceador simplesmente copiará quaisquer dados de semente ainda referenciados pelo novo sistema de arquivos antes de desanexar. Mason sugeriu que isso pode ser útil para um instalador de Live CD , que pode inicializar a partir de uma semente Btrfs somente leitura em um disco óptico, reequilibrar-se para a partição de destino no disco de instalação em segundo plano enquanto o usuário continua a trabalhar e, em seguida, ejetar o disco para completar a instalação sem reinicializar.

Encriptação

Em sua entrevista de 2009, Chris Mason afirmou que o suporte para criptografia foi planejado para Btrfs. Nesse ínterim, uma solução alternativa para combinar criptografia com Btrfs é usar um mecanismo de criptografia de disco completo, como dm-crypt  / LUKS, nos dispositivos subjacentes e criar o sistema de arquivos Btrfs sobre essa camada.

Em 2020, os desenvolvedores estavam trabalhando para adicionar hash com chave como HMAC ( SHA256 ).

Verificação e recuperação

Os sistemas Unix tradicionalmente contam com programas " fsck " para verificar e reparar sistemas de arquivos. Esta funcionalidade é implementada por meio do btrfs checkprograma. Desde a versão 4.0, esta funcionalidade é considerada relativamente estável. No entanto, a partir de agosto de 2017, a documentação do btrfs sugere que ele seja usado somente após 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 é basicamente autocorretivo e pode se recuperar de árvores de raiz quebradas no momento da montagem, graças a liberações periódicas de dados para armazenamento permanente, por padrão a cada 30 segundos. Portanto, erros isolados farão com que no máximo 30 segundos de alterações no sistema de arquivos sejam perdidas na próxima montagem. Este período pode ser alterado especificando um valor desejado (em segundos) para a commitopção de montagem.

Projeto

A proposta original de Ohad Rodeh na USENIX 2007 observou que as árvores B + , que são amplamente usadas como estruturas de dados em disco para bancos de dados, não podiam permitir instantâneos baseados em cópia na gravação porque seus nós de folha estavam vinculados: se uma folha fosse uma cópia não escrito, seus irmãos e pais teriam que estar também, assim como seus irmãos e pais e assim por diante, até que a árvore inteira fosse copiada. Em vez disso, ele sugeriu uma árvore B modificada (que não tem ligação de folha), com um refcount associado a cada nó da árvore, mas armazenado em uma estrutura de mapa livre ad hoc e certos relaxamentos para os algoritmos de balanceamento da árvore para torná-los fáceis de copiar na escrita . O resultado seria uma estrutura de dados adequada para um armazenamento de objeto de alto desempenho que pudesse executar instantâneos de cópia na gravação, enquanto mantinha uma boa simultaneidade .

Na Oracle naquele ano, Chris Mason começou a trabalhar em um sistema de arquivos com capacidade para instantâneos que usaria essa estrutura de dados quase exclusivamente - não apenas para metadados e dados de arquivo, mas também recursivamente para rastrear a alocação de espaço das próprias árvores. Isso permitiu que todas as travessias e modificações fossem canalizadas por meio de um único caminho de código, em relação ao qual recursos como cópia na gravação, soma de verificação e espelhamento precisavam ser implementados apenas uma vez para beneficiar todo o sistema de arquivos.

O Btrfs é estruturado como várias camadas dessas árvores, todas usando a mesma implementação da árvore B. As árvores armazenam itens genéricos classificados por uma chave de 136 bits. Os 64 bits mais significativos da chave são um ID de objeto exclusivo . Os oito bits do meio são um campo de tipo de item: seu uso está embutido no código como um filtro de item em pesquisas de árvore. Os objetos podem ter vários itens de vários tipos. Os 64 bits restantes (menos significativos) são usados ​​de maneiras específicas do tipo. Portanto, itens para o mesmo objeto acabam adjacentes uns aos outros na árvore, agrupados por tipo. Ao escolher certos valores-chave, os objetos podem colocar itens do mesmo tipo em uma ordem específica.

Os nós da árvore interna são simplesmente listas simples de pares de ponteiros-chave, onde o ponteiro é o número do bloco lógico de um nó filho. Os nós de folha contêm chaves de item compactadas na frente do nó e dados de item compactados no final, com os dois crescendo um em direção ao outro à medida que a folha é preenchida.

Árvore do sistema de arquivos

Dentro de cada diretório, as entradas de diretório aparecem como itens de diretório , cujos bits menos significativos de valores de chave são um hash CRC32C de seu nome de arquivo. Seus dados são uma chave de localização ou a chave do item inode para o qual ele aponta. Os itens de diretório juntos podem atuar como um índice para pesquisas de caminho para inode, mas não são usados ​​para iteração porque são classificados por seu hash, permutando- os efetivamente de forma aleatória . Isso significa que os aplicativos do usuário iterando e abrindo arquivos em um diretório grande gerariam muito mais buscas de disco entre arquivos não adjacentes - um dreno de desempenho notável em outros sistemas de arquivos com diretórios ordenados por hash, como ReiserFS , ext3 (com Htree-indexes habilitados ) e ext4, todos com nomes de arquivo em hash TEA . Para evitar isso, cada entrada de diretório possui um item de índice de diretório , cujo valor-chave do item é definido como um contador por diretório que aumenta a cada nova entrada de diretório. A iteração sobre esses itens de índice, portanto, retorna as entradas mais ou menos na mesma ordem que as armazenadas no disco.

Arquivos com links físicos em vários diretórios têm vários itens de referência, um para cada diretório pai. Arquivos com vários links físicos no mesmo diretório agrupam todos os nomes de arquivos dos links no mesmo item de referência. Essa era uma falha de projeto que limitava o número de links físicos no mesmo diretório para quantos cabessem em um único bloco de árvore. (No tamanho de bloco padrão de 4 KiB, um comprimento médio de nome de arquivo de 8 bytes e um cabeçalho por nome de arquivo de 4 bytes, isso seria inferior a 350.) Aplicativos que fazem uso intenso de vários links físicos no mesmo diretório, como Observou-se que git , GNUS , GMame e BackupPC falharam neste limite. O limite foi finalmente removido (e em outubro de 2012 foi mesclado com lançamento pendente no Linux 3.7) pela introdução de itens de referência estendidos de spillover para conter nomes de arquivos de link físico que não cabem de outra forma.

Extensões

Os dados do arquivo são mantidos fora da árvore em extensões , que são execuções contíguas de blocos de dados do disco. Os blocos de extensão têm como padrão 4 KiB de tamanho, não têm cabeçalhos e contêm apenas dados de arquivo (possivelmente compactados). Em extensões compactadas, os blocos individuais não são compactados separadamente; em vez disso, o fluxo de compressão se estende por toda a extensão.

Os arquivos possuem itens de dados de extensão para rastrear as extensões que mantêm seu conteúdo. O valor-chave do item é o deslocamento de byte inicial da extensão. Isso torna as buscas eficientes em arquivos grandes com muitas extensões, porque a extensão correta para qualquer deslocamento de arquivo determinado pode ser calculada com apenas uma pesquisa de árvore.

Instantâneos e arquivos clonados compartilham extensões. Quando uma pequena parte de uma grande extensão é sobrescrita, a cópia na gravação resultante pode criar três novas extensões: uma pequena contendo os dados sobrescritos e duas grandes com dados não modificados em ambos os lados da sobregravação. Para evitar ter que reescrever dados não modificados, a cópia na gravação pode, em vez disso, criar extensões de bookend , ou extensões que são simplesmente fatias de extensões existentes. Os itens de dados de extensão permitem isso incluindo um deslocamento na extensão que eles estão rastreando: itens para bookends são aqueles com deslocamentos diferentes de zero.

Árvore de alocação de extensão

A árvore de alocação de extensão atua como um mapa de alocação para o sistema de arquivos. Ao contrário de outras árvores, os itens nesta árvore não têm ids de objeto. Eles representam regiões do espaço: seus valores-chave contêm os deslocamentos iniciais e os comprimentos das regiões que representam.

O sistema de arquivos divide seu espaço alocado em grupos de blocos que são regiões de alocação de tamanho variável que alternam entre as extensões de metadados preferenciais (nós de árvore) e as extensões de dados (conteúdo do arquivo). A proporção padrão de dados para grupos de blocos de metadados é 1: 2. Eles pretendem usar conceitos do alocador de bloco Orlov para alocar arquivos relacionados juntos e resistir à fragmentação, deixando espaço livre entre os grupos. (Grupos de blocos Ext3, no entanto, têm locais fixos calculados a partir do tamanho do sistema de arquivos, enquanto aqueles em Btrfs são dinâmicos e criados conforme necessário.) Cada grupo de blocos é associado a um item de grupo de blocos . Os itens de inode na árvore do sistema de arquivos incluem uma referência ao seu grupo de blocos atual.

Os itens de extensão contêm uma referência anterior ao nó da árvore ou arquivo que ocupa essa extensão. Pode haver várias referências anteriores se a extensão for compartilhada entre os instantâneos. Se houver muitas referências anteriores para caber no item, elas se espalharão em itens de referência de dados de extensão individual . Os nós de árvore, por sua vez, têm referências anteriores às árvores que os contêm. Isso torna possível encontrar quais extensões ou nós de árvore estão em qualquer região do espaço, fazendo uma pesquisa de intervalo de árvore B em um par de deslocamentos que delimitam essa região e, em seguida, seguindo as referências anteriores. Para realocar dados, isso permite uma passagem eficiente para cima a partir dos blocos realocados para localizar e corrigir rapidamente todas as referências para baixo a esses blocos, sem ter que varrer todo o sistema de arquivos. Isso, por sua vez, permite que o sistema de arquivos reduza, migre e desfragmente com eficiência seu armazenamento online.

A árvore de alocação de extensão, como com todas as outras árvores no sistema de arquivos, é cópia na gravação. As gravações no sistema de arquivos podem, portanto, causar uma cascata na qual os nós da árvore e os dados do arquivo alterados resultam em novas extensões sendo alocadas, fazendo com que a própria extensão da árvore mude. Para evitar a criação de um loop de feedback , os nós da árvore de extensão que ainda estão na memória, mas ainda não confirmados no disco, podem ser atualizados no local para refletir as novas extensões de cópia na gravação.

Em teoria, a árvore de alocação de extensão torna desnecessário um bitmap de espaço livre convencional porque a árvore de alocação de extensão atua como uma versão B-tree de uma árvore BSP . Na prática, entretanto, uma árvore vermelho-preto na memória de bitmaps do tamanho de página é usada para acelerar as alocações. Esses bitmaps são mantidos no disco (começando no Linux 2.6.37, por meio da space_cacheopção de montagem) como extensões especiais que são isentas de soma de verificação e cópia na gravação.

Árvore de soma de verificação e esfrega

Os checksums CRC-32C são calculados para dados e metadados e armazenados como itens de checksum em uma árvore de checksum . Há espaço para 256 bits de somas de verificação de metadados e até um nó completo (cerca de 4 KB ou mais) para somas de verificação de dados. O Btrfs tem disposições para algoritmos de soma de verificação adicionais a serem adicionados em versões futuras do sistema de arquivos.

Há um item de checksum por execução contígua de blocos alocados, com checksums por bloco compactados de ponta a ponta nos dados do item. Se houver mais somas de verificação do que podem caber, elas serão transferidas para outro item de soma de verificação em uma nova folha. Se o sistema de arquivos detectar uma incompatibilidade de soma de verificação durante a leitura de um bloco, ele primeiro tentará obter (ou criar) uma boa cópia desse bloco de outro dispositivo - se o espelhamento interno ou técnicas de RAID estiverem em uso.

O Btrfs pode iniciar uma verificação online de todo o sistema de arquivos, acionando um trabalho de limpeza do sistema de arquivos executado em segundo plano. O trabalho de limpeza verifica a integridade de todo o sistema de arquivos e tenta automaticamente relatar e reparar quaisquer blocos defeituosos que encontrar ao longo do caminho.

Árvore de toras

Uma solicitação fsync confirma os dados modificados imediatamente para o armazenamento estável. Cargas de trabalho pesadas de fsync (como um banco de dados ou uma máquina virtual cujo sistema operacional fsyncs com frequência) podem gerar uma grande quantidade de E / S de gravação redundante, forçando o sistema de arquivos a copiar na gravação repetidamente e liberar partes frequentemente modificadas de árvores para armazenar. Para evitar isso, um temporária per-subvolume árvore de log é criado para revista escreve copy-on-fsync-desencadeadas. As árvores de registro são independentes, rastreando suas próprias extensões e mantendo seus próprios itens de soma de verificação. Seus itens são reproduzidos e excluídos na próxima submissão completa da árvore ou (se houver uma falha no sistema) na próxima remontagem.

Árvores de blocos e dispositivos

Os dispositivos de bloco são divididos em blocos físicos de 1 GiB para dados e 256 MiB para metadados. Pedaços físicos em vários dispositivos podem ser espelhados ou divididos em um único pedaço lógico . Esses pedaços lógicos são combinados em um único espaço de endereço lógico que o resto do sistema de arquivos usa.

A árvore de blocos rastreia isso, armazenando cada dispositivo nele como um item de dispositivo e blocos lógicos como itens de mapa de blocos , que fornecem um mapeamento direto de endereços lógicos para físicos, armazenando seus deslocamentos nos 64 bits menos significativos de sua chave. Os itens do mapa de fragmentos podem ser de vários tipos diferentes:

solteiro
1 lógico para 1 pedaço físico
enganar
1 bloco lógico para 2 blocos físicos em 1 dispositivo de bloco
raid0
N blocos lógicos para N≥2 blocos físicos em dispositivos de bloco N≥2
raid1
1 bloco lógico para 2 blocos físicos em 2 dos dispositivos de bloco N≥2, em contraste com o RAID 1 convencional que tem N blocos físicos
raid1c3
1 bloco lógico para 3 blocos físicos de N≥3 dispositivos de bloco
raid1c4
1 bloco lógico para 4 blocos físicos de dispositivos de bloco N≥4
raid5
N (para N≥2) pedaços lógicos para N + 1 pedaços físicos em dispositivos de bloco N + 1, com 1 pedaço físico usado como paridade
raid6
N (para N≥2) blocos lógicos para N + 2 blocos físicos em dispositivos de bloco N + 2, com 2 blocos físicos usados ​​como paridade

N é o número de dispositivos de bloco que ainda têm espaço livre quando o bloco é alocado. Se N não for grande o suficiente para o espelhamento / mapeamento escolhido, o sistema de arquivos está efetivamente sem espaço.

Árvores de realocação

As operações de desfragmentação, redução e rebalanceamento exigem que as extensões sejam realocadas. No entanto, fazer uma cópia na gravação simples da extensão de realocação interromperá o compartilhamento entre os instantâneos e consumirá espaço em disco. Para preservar o compartilhamento, um algoritmo de atualização e troca é usado, com uma árvore de realocação especial servindo como espaço temporário para os metadados afetados. A extensão a ser realocada é primeiro copiada para seu destino. Então, seguindo referências anteriores para cima através da árvore do sistema de arquivos do subvolume afetado, os metadados que apontam para a extensão antiga são progressivamente atualizados para apontar para a nova; todos os itens recém-atualizados são armazenados na árvore de realocação. Assim que a atualização for concluída, os itens na árvore de realocação são trocados por seus correspondentes no subvolume afetado e a árvore de realocação é descartada.

Superblock

Todas as árvores do sistema de arquivos - incluindo a própria árvore de chunk - são armazenadas em chunks, criando um problema potencial de bootstrap ao montar o sistema de arquivos. Para inicializar em uma montagem, uma lista de endereços físicos de blocos pertencentes ao bloco e às árvores raiz é armazenada no superbloco .

Os espelhos do Superblock são mantidos em locais fixos: 64 KiB em cada dispositivo de bloco, com cópias adicionais de 64 MiB, 256 GiB e 1 PiB. Quando um espelho de superbloco é atualizado, seu número de geração é incrementado. No momento da montagem, a cópia com o maior número de geração é usada. Todos os espelhos superblocos são atualizados em conjunto, exceto no modo SSD que alterna as atualizações entre os espelhos para fornecer algum nivelamento de desgaste .

Suporte comercial

Suportado

Não mais suportado

Veja também

Notas

Referências

links externos