Reiser4

Uma Visão Geral do Sistema de Arquivos Reiser4. Por: Wilian França Costa e Kelly Cristina de Oliveira Cruz

Semântica Básica

Nomes e objetos

O nome é utilizado para selecionar um objeto. Um objeto é qualquer coisa que represente um entidade única. Namespaces (espacos de nomes), é o mapeamento de nomes a objetos. Sistemas de arquivos, bancos de dados, mecanismos de busca, variáveis da ambiente são exemplos de namespaces. A busca por objetos é dividida em camadas: semântica e de armazenamento. A camada semântica manipula os nomes e os convertem em chaves (resolver o nome). A camada de armazenamento (que contém o código para a travessia na árvore), pega a chave e encontra os bytes que armazenam as partes do objeto. Chaves são fundamentais para o Reiser4, pois com elas você pode não somente localizar um objeto, mas também partes dele. Um objectid não pode ser usado para localizar um objeto, ele somente é utilizado para garantir que a chave não está duplicada.

Diretórios

Os diretórios no Reiser4 são implementados utilizando nomes hierárquicos. O primeiro componente do nome hierárquico é o diretório e são usados o '/' para separar os componentes do nome. Um diretório pode aplicar qualquer método arbitrário para solucionar os componentes do nome passados a ele e retorna um conjunto de chaves para objetos como resultado. Os diretórios devolvem uma lista de nomes quando solicitado.

O Plugin de Diretórios Unix.

O plugin de diretórios Unix implementa os diretórios gravando um conjunto de entradas por diretório. Estas entradas contém um nome e uma chave. Quando lhe é passado um nome para resolver, o plugin encontra a entrada para o diretório que contém aquele nome, e retorna uma chave que é a entrada do diretório.

Arquivos que Também são Diretórios

Em Reiser4 (mas não ReiserFS 3) um objeto pode ser ao mesmo tempo um arquivo e um diretório. Se você acessar como um arquivo, obterá uma sucessão nomeada de bytes. Se usá-lo como um diretório poderá ter arquivos contidos nele, listas de diretórios, etc. havia uma discussão prolongada na Lista do Kernel do Linux discutindo se isto era tecnicamente possível fazer. Linus mostrou que era possível sem "quebrar" VFS. Permitir que um objeto possa ser ambos um arquivo e um diretório é uma das características necessárias para compor a presente funcionalidade em fluxos e atributos, usando arquivos e diretórios. Para implementar um arquivo regular unix com todo o seu meta-dado, utilizamos um plugin de arquivo para o corpo do arquivo, um plugin de diretório para encontrar plugins de arquivo para cada meta-dado, e plugins de arquivo específico para cada meta-dado. Usando um plugin de arquivo unix_file para acessar o corpo do arquivo, e um plugin de diretório unix_file_dir para resolver os nomes de seu meta-dado de um plugin de arquivo para um meta-dado específico. Estes plugins de arquivo específico para unix que arquivam meta-dados(dono, permissões, etc.) são implementados para permitir que o meta-dado usado normalmente nos arquivos unix sejam armazenados de uma forma compacta.

Minimizar o numero de primitivas é importante para uma construção abstrata.

Esta afirmação é levada ao extremo no Reiser4, pois como um objeto pode ser ao mesmo tempo um arquivo ou um diretório, os atributos de um arquivo podem ser armazenados como arquivos e podem ser acessados através do nome do arquivo, seguido de '/' mais o nome do atributo. Assim um arquivo tradicional passa a ser implementado para ter algumas das características de um diretório.

Lista de características necessárias para obter atributos através da funcionalidade de fluxos para arquivos e diretórios.

• Api eficiente para arquivos pequenos.
• Armazenamento eficiente de arquivos pequenos.
• Plugins, inclusos plugins que comprimem um serviço de arquivo como um atributo em um único bit.
• Arquivos que atuam como diretório quando acessados como tal.
• Herança (inclui agregação de arquivo).
• Constrição.
• Transações.
• Entradas ocultas de diretório.

Cada uma destas características adicionais é uma característica que beneficiaria o sistema de arquivos. Assim, estão presentes na v4.

Árvores, grafos e a organização dos dados.

Reiser4 usa uma árvore finita (o número de nós está limitado) em sua camada de armazenamento e pesquisa. Não entraremos aqui em detalhes sobre o conceito e árvores e grafo e assumimos que o leitor já tenha algum conhecimento sobre o assunto. Reiser4 utiliza grafos e árvores. Árvores são usadas para quando o sistema de arquivos esta encarregado da organização (quando é chamada a camada de armazenamento que tenta ser simples e eficiente), e grafos para quando o usuário escolhe a organização (na camada semântica que tenta ser expressiva de forma que o usuário possa fazer tudo o que quiser).

Ordenar a árvore ajuda a tornar a busca mais eficiente.

Chaves

Tudo que for armazenado em uma árvore chamaremos de chave. Toda a busca que fizermos será através delas. O uso de chaves nos proporciona uma flexibilidade adicional para ordenarmos as coisas e se as chaves forem pequenas, teremos meios bastante compactos para especificar uma busca por alguma coisa. Também limita as informações que podemos utilizar para encontrar algo. Este limite restringe sua utilidade, assim temos uma camada de armazenamento para buscar através de chaves e uma camada semântica com um rico sistema de nomeação. A camada de armazenamento usa chaves somente para organizar o armazenamento, de certo modo isso melhora o desempenho, e a camada semântica entende os nomes com significado para os usuários. Esta é uma separação útil que permite liberdade e somam melhorias no desempenho da camada de armazenamento, evitando que os efeitos colaterais dessas melhorias afetassem os objetivos de nomeação flexível na camada semântica. A árvore é ordenada de forma que a chave da subárvore mais a esquerda é sempre menor do que a chave da subarvore mais a direita.

Uma busca começará pelo nó raiz, e termina em um nó folha que possuir os dados.

Um exemplo de uma árvore do Reiser4: Ficheiro:Treev4 Reiser4X.gif Figura 1. Àrvore altura 4 de Reiser4, árvore equilibrada com um fanout de 3. Na prática o fanout de Reiser4 é muito maior e varia de nó para nó.

Itens

Os nós do Reiser4 são normalmente iguais a um tamanho de página usado em Gnu/Linux em uma CPU Intel que é atualmente de 4096 bytes. Objetos maiores que 4k bytes são divididos, estes pedaços são chamados de itens e são dimensionados para terem o tamanho de um nó. Sistemas de arquivos convencionais armazenam os arquivos em blocos inteiros, isto significa que em média meio bloco de espaço é perdido por arquivo, pois nem todos os blocos são inteiramente utilizados. Se um arquivo for muito menor que o bloco, então o espaço desperdiçado é maior que o arquivo. Colocando múltiplos ítens em um simples nó no Reiser4 , podemos armazenar pequenos pedaços de arquivos em um bloco, chegando a uma eficiência de 94% com arquivos pequenos.

A estrutura de um item:

Item_Body	. . separated . .	Item_Head
		Item_Key	Item_Offset	Item_Length	Item_Plugin_id

BLOBS desbalanceiam a árvore, reduzindo a performance.

BLOBS (Binary Large Objects), é o nome dado ao método de gravar objetos maiores que o nó armazenado ponteiros para os nós contendo as partes dos objetos. Estes ponteiros normalmente estão localizados no nós folha.

Ficheiro:Blobs Reiser3.gif Figura 2. Um BLOB foi inserido com o ponteiro para seus blocos em um nó folha. Esta é a forma de uma árvore no ReiserFS V3.

O Reiser4 volta a definição clássica de árvore balanceada por altura, no qual o comprimento dos caminhos de todos os nós são iguais, não tenta fingir que objetos maiores que os nós não são parte da árvore. Como resultado a quantidade de RAM exigida para armazenar ponteiros para os nós está drasticamente reduzida. Para configurações típicas, a RAM é grande o bastante para armazenar um nó inteiro.

Ficheiro:Blobs Reiser4.gif Figure 3. Uma árvore de nível 4 no Reiser4, árvore balanceada pela altura com fanout = 3 e os dados que foram armazenados agora em BLOBS. Este tipo de árvore em que os nós folhas se fundem para equilibrar a árvore é chamado de árvores dançantes.

Estrutura padrão de nós no Reiser4

.................................................................................................................................................................................................................................

The Structure of an Item

Item_Body	. . separated . .	Item_Head
		Item_Key	Item_Offset	Item_Length	Item_Plugin_id

A formatted leaf node has the structure:

Block_Head

Item_Body0

Item_Body1

- - -

Item_Bodyn

....Free Space....

Item_Headn

- - -

Item_Head1

Item_Head0

A twig node has the structure:

Block_Head

Item_Body0 NodePointer0

Item_Body1 ExtentPointer1

Item_Body2 NodePointer2

Item_Body3 ExtentPointer3

- - -

Item_Bodyn NodePointern

....Free Space....

Item_Headn

- - -

Item_Head0

A branch node has the structure:

Block_Head

Item_Body0 NodePointer0

- - -

Item_Bodyn NodePointern

........Free Space......

Item_Headn

- - -

Item_Head0

Reiser4 - O Sistema de arquivos atômico.

Quando ocorre uma pane no computador os dados da RAM que ainda não foram transferidos para o disco são perdidos. Suponha que você esta efetuando uma transferência de R$10 da conta A para a conta B, para que a transação ocorra, teriamos duas operações -1) débito de A e 2) crédito de R$10 para B. Suponha que 1) foi efetivada, mas antes de 2) ocorrer houve uma pane no computador. Seria melhor desconsirerar 1), que consirerar 1) mas não 2) , pois assim eliminaríamos uma inconsistência. Quando temos um conjunto de operações e nos asseguramos que, ou todas ocorrem, ou nenhuma ocorre, chamamos todo o conjunto de átomo. Reiser4 implementa todo o seu sistema de arquivos com chamadas de sistema que executam operações atômicas, e permite que sejam desenvolvidas novas operações atômicas através da infra-estrutura de plugins.

Journaling

A tecnologia de "Journaling" possue a capacidade de acompanhar as mudanças que serão feitas no sistema de arquivos (por exemplo, gravações/atualizações de dados) antes que realmente sejam feitas. Essas informações que o Journaling captura são então armazenadas em uma parte separada do sistema de arquivos, denominada "Journal" (mas também conhecida por "registros de log"). Quando as informações são armazenadas no Journal, o sistema de arquivos aplica as mudanças registradas nele e então, remove as informações do Journal. Agora, entenda porque o Journaling é uma solução eficiente para os problemas de erro. Os registros de log são escritos antes que as mudanças efetivamente ocorram no sistema de arquivos e esses registros somente são eliminados quando as mudanças são feitas. Assim, se o computador é indevidamente desligado, o processo de montagem no próximo startup verificará se há mudanças gravadas no Journal "marcadas" como não feitas. Se houver, tais mudanças são então aplicadas ao sistema de arquivos. Isso faz com que os riscos de perda de dados sejam reduzidos drasticamente. Um "journaling filesystem" trabalha de com uma espécie de agenda (um log ou um journal). A escrita ocorre em duas etapas: 1. dados sobre a futura operação de escrita são agendadas (gravadas no journal) 2. a operação de escrita é realmente realizada. Assim, se der um crash na fase de "agendamento", o arquivo não é atualizado, mas se mantém intacto. Se der um problema na fase de escrita propriamente dita, então o journal deve conter as informações necessárias para completar a operação de escrita e o disco é atualizado Existem três "Journaling Filesystems" para Linux: o ext3, o XFS e o ReiserFS. Uma vantagem deste tipo de sistema de arquivos é que o boot é bem mais rápido: ao invés de se verificar o disco todo, verifica-se apenas o que é apontado pelo "Journal".

Referências [Reiser2004] Reiser, Hans T., Reiser4, 2004,. Disponível em: http://www.namesys.com.