Conteúdo


Próxima Geração de Sistemas de Arquivos Linux: NiLFS(2) e exofs

Avançando sistemas de arquivos Linux com logs e objetos

Comments

Existe algo animador e assustador sobre o anúncio de um novo sistema de arquivos Linux. É animador porque sistemas de arquivos representam um novo território para avanços interessantes. É assustador porque um sistema de arquivos nos primeiros estágios tende a ser experimental e a não estar totalmente pronto para o horário nobre. Mas, às vezes, esses anúncios são sobre investimento no futuro do Linux, e um anúncio recente para 2.6.30-rc1 indica um futuro muito interessante, de fato. Nos últimos trimestres, o Linux fez três importantes anúncios de sistema de arquivos. No final de 2008 apresentou o B-Tree File System (Btrfs) e, mais recentemente, dois outros sistemas de arquivos exclusivos foram apresentados: NiLFS(2) e exofs.

Histórico do Sistema de Arquivos

Vamos começar com uma rápida introdução a essas abordagens de sistema de arquivos não tradicionais e, depois, explorar aspectos específicos do NiLFS(2) e do exofs.

Sistemas de arquivos estruturados em log

Sistemas de arquivos estruturados em log têm um rico histórico em sistemas de computação modernos. O primeiro sistema de arquivos estruturado em log foi proposto por John Ousterhout e Fred Douglis em 1988 e, subsequentemente, implementado no sistema operacional Sprite em 1992. Como o nome indica, um sistema de arquivos estruturado em log visualiza o sistema de arquivos como um log circular no qual novos dados e metadados de sistema de arquivos são gravados no início do log, e o espaço livre é reivindicado a partir do final (veja a Figura 1). Isso significa que os dados podem aparecer duas ou mais vezes no log, mas como o log avança cronologicamente, os dados mais recentes são visualizados como os dados ativos. Ter múltiplas cópias de dados no log apresenta alguns benefícios interessantes, que serão abordados com mais detalhes abaixo.

Figura 1. Visualização simples de um sistema de arquivos estruturado em log
Sistema de arquivos estruturado em log
Sistema de arquivos estruturado em log

Apesar de a abordagem estruturada em log ser mais um detalhe arquitetônico do que um ponto de venda, a abordagem oferece algumas vantagens distintas. Uma vantagem-chave é a recuperação a partir de travamentos do sistema, que é mais simples usando-se a abordagem estruturada em log.

Outra vantagem é o uso do sistema de armazenamento subjacente para explorar o desempenho. Você deve se lembrar de que a gravação sequencial em discos é muito mais rápida do que E/S aleatória. Como todas as gravações ocorrem sequencialmente, a taxa de busca é diminuída, resultando em E/S de disco mais rápida e, subsequentemente, um sistema de arquivos mais rápido.

Sistemas de armazenamento baseados em objeto

Sistemas de armazenamento tradicionais contam com unidades de disco e suas interfaces nativas para persistentemente armazenar dados. Essas interfaces contam com uma semântica de armazenamento em bloco, em que blocos de dados pequenos e de tamanho fixo são comunicados junto com seus mapeamentos (metadados de sistema de arquivos). Sistemas de armazenamento de objetos usam uma abordagem muito diferente: em vez de gerenciar blocos de tamanho fixo, eles gerenciam objetos de tamanho variável e metadados associados (que fornecem informações de nível de sistema sobre o objeto).

Os sistemas de armazenamento de objetos são um caminho exclusivo para armazenamento muito escalável que incorpora multi-tenancy e segurança. O OSD como um padrão (veja a barra lateral) pode ser construído de diversas maneiras. É possível usar componentes compatíveis com OSD (como unidades e iniciadores OSD) ou componentes de nível mais alto (sistemas de destino que constroem comportamento OSD sobre unidades tradicionais). Mas a diferença fundamental entre sistemas de armazenamento baseados em blocos e baseados em objetos é que no baseado em blocos, você cria objetos de coletas de blocos que contêm dados e metadados usando um protocolo que se comunica com blocos. No baseado em objetos, você se comunica com objetos e seus metadados associados (veja a Figura 2). Então, os dispositivos de armazenamento de objetos se tornam espaços de nomes de objetos simples, nos quais a hierarquia (se necessário) é construída mais alto na pilha do sistema de armazenamento.

Figura 2. Sistemas de armazenamento baseados em blocos versus baseados em objetos
Sistemas de armazenamento baseados em blocos versus baseados em objetos
Sistemas de armazenamento baseados em blocos versus baseados em objetos

Este artigo explora uma implementação de um sistema de arquivos sobre um sistema de armazenamento baseado em objetos.

Nova implementação de um sistema de arquivos estruturado em log: NiLFS(2)

NiLFS(2) é a segunda iteração de um sistema de arquivos estruturado em log desenvolvido no Japão pela Nippon Telegraph and Telephone (NTT). O sistema de arquivos está sob desenvolvimento muito ativo, tendo recentemente entrada no kernel Linux de mainline (além do kernel NetBSD). A primeira versão do NILFS (versão 1) apareceu em 2005, mas não tinha nenhuma forma de coleta de lixo. Em meados de 2007, a versão 2 foi lançada pela primeira vez, que incluía um coletor de lixo e a capacidade de criar e manter múltiplas capturas instantâneas. Neste ano (2009), o sistema de arquivos NiLFS(2) entrou no kernel de mainline e pode ser ativado simplesmente por meio da instalação de seu módulo carregável.

Um aspecto interessante do NiLFS(2) é sua técnica de captura de tela contínua. Como o NILFS é estruturado em log, dados novos são gravados no início do log enquanto dados antigos ainda existem (até que seja necessário coletá-los como lixo). Uma vez que os dados antigos estão lá, é possível retornar no tempo para inspecionar as épocas do sistema de arquivos. Essas épocas são chamadas de pontos de verificação em NiLFS(2) é são uma parte integral do sistema de arquivos. O NiLFS(2) cria esses pontos de verificação à medida que mudanças são feitas, mas também é possível forçar a ocorrência de um ponto de verificação.

Como eu mostrarei mais adiante, pontos de verificação (pontos de recuperação) podem ser visualizados e também alterados em uma captura instantânea. Capturas instantâneas podem ser montadas no espaço de sistema de arquivos Linux como quaisquer outros sistemas de arquivos, mas atualmente eles podem ser somente leitura. Isto é bastante útil, pois é possível montar uma captura instantânea e recuperar arquivos que foram previamente excluídos ou verificar versões anteriores de arquivos.

Além de capturas instantâneas contínuas, o NiLFS(2) fornece vários outros benefícios. Um dos mais importantes de uma perspectiva de disponibilidade é o reinício rápido. Se o ponto de verificação atual estava inválido, o sistema de arquivos precisa somente voltar para o último ponto de verificação bom para um sistema de arquivos válido. Isto certamente supera o processo fsck.

Desafios do NiLFS(2)

Apesar de a captura instantânea contínua ser um excelente recurso, um custo está associado a ela. O lado positivo, como eu mencionei, é que ela é estruturada em log, então as gravações são sequenciais por natureza (minimizando o comportamento de busca do disco físico) e, assim, muito rápidas. O lado negativo é que ela é estruturada em log, e é necessária a coleta de lixo para limpar dados e metadados antigos. Normalmente, o sistema de arquivos opera muito rapidamente, mas quando a coleta de lixo é necessária, o desempenho diminui.

Explorando o NiLFS(2)

Vamos dar uma olha no NiLFS(2) em ação. Esta demonstração mostra como criar um sistema de arquivos NiLFS(2) em um dispositivo de loop (um método simples para testar sistemas de arquivos) e, depois, foca em alguns dos recursos do NiLFS(2). Comece instalando o módulo do kernel NiLFS(2):

$ sudo modprobe nilfs2
$

A seguir, crie um arquivo que conterá o sistema de arquivos (uma área no sistema operacional do host que você monta como seu próprio sistema de arquivos através do dispositivo de loop) e, depois, construa o sistema de arquivos NiLFS(2) dentro dele usando o mkfs (consulte a Lista 1).

Lista 1. Preparando o sistema de arquivos NiLFS(2)
$ dd if=/dev/zero of=/tmp/disk.img bs=384M count=1
1+0 records in
1+0 records out
402653184 bytes (403 MB) copied, 60.7253 s, 6.6 MB/s
$ mkfs.nilfs2 /tmp/disk.img
mkfs.nilfs2 ver 2.0
Comece gravando os dados iniciais do sistema de arquivos no dispositivo
       Tamanho do bloco:4096  Dispositivo:/tmp/disk.img  
       Tamanho do dispositivo:402653184 Inicialização do 
                              sistema de arquivos bem-sucedida !!
$

Agora você está com a sua imagem de disco rígido inicializada com o formato do sistema de arquivos NiLFS(2). A seguir, monte o sistema de arquivos sobre um ponto de montagem usando o dispositivo de loop (consulte a Lista 2). Observe que quando o sistema de arquivos é montado, um programa de espaço do usuário chamado nilfs_cleanerd também é iniciado para fornecer serviços de coleta de lixo.

Lista 2. Montando o NiLFS(2) usando o dispositivo de loop
$ sudo losetup /dev/loop0 /tmp/disk.img
$ sudo mkdir /mnt/nilfs
$ sudo mount -t nilfs2 /dev/loop0 /mnt/nilfs/
mount.nilfs2: AVISO! - O formato em disco NILFS pode ser alterado a qualquer momento.
mount.nilfs2: AVISO! - Não coloque dados cruciais em um sistema de arquivos NILFS.
$ ls /mnt/nilfs
$

Agora, inclua alguns arquivos no sistema de arquivos e, então, use o comando lscp para listar os pontos de verificação disponíveis (consulte a Lista 3). Defina uma captura instantânea usando o comando mkcp e, depois, verifique os pontos de verificação novamente. No segundo lscpvocê pode ver sua captura instantânea criada recentemente (com todos os pontos de verificação e capturas instantâneas tendo um CNO ou número de ponto de verificação).

Lista 3. Listando pontos de verificação e criando uma captura instantânea
$ cd /mnt/nilfs
$ sudo touch file1.txt file2.txt
$ lscp
                 CNO        DATE     TIME  MODE  FLG   NBLKINC       ICNT
                   1  2009-08-21 22:29:31   cp    -         11          3
                   2  2009-08-21 22:36:44   cp    -         11          5
$ sudo mkcp -s
$ lscp
                 CNO        DATE     TIME  MODE  FLG   NBLKINC       ICNT
                   1  2009-08-21 22:29:31   cp    -         11          3
                   2  2009-08-21 22:36:44   ss    -         11          5
                   3  2009-08-21 22:39:47   cp    i          7          5
$

Agora que você tem uma captura instantânea, inclua mais alguns arquivos no seu sistema de arquivos atual, novamente com o comando touch (consulte a Lista 4).

Lista 4. Incluindo mais alguns arquivos no seu sistema de arquivos NiLFS(2)
$ sudo touch file3.txt file4.txt
$ ls
file1.txt  file2.txt  file3.txt  file4.txt
$

Agora, monte sua captura instantânea como um sistema de arquivos somente leitura. Faça isso da mesma forma que a sua montagem anterior, mas, neste caso, é necessário especificar a captura instantânea a ser montada. Faça isso com a opção cp . Observe a partir do lscp anterior que a sua captura instantânea era CNO=2. Use este CNO para o comando mount para montar o sistema de arquivos somente leitura. Depois de montado, você primeiro ls seu sistema de arquivos de leitura/gravação montado e vê todos os arquivos. Na captura instantânea somente leitura, você vê somente os dois arquivos que existiam no momento da captura instantânea (consulte a Lista 5).

Lista 5. Montando a captura instantânea NiLFS(2) somente leitura
$ sudo mkdir /mnt/nilfs-ss2
$ sudo mount.nilfs2 -r /dev/loop0 /mnt/nilfs-ss2/ -o cp=2
$ ls /mnt/nilfs
file1.txt  file2.txt  file3.txt  file4.txt
$ ls /mnt/nilfs-ss2/
file1.txt  file2.txt
$

Observe que essas capturas instantâneas persistem uma vez convertidas a partir de pontos de verificação. Os pontos de verificação podem ser recuperados a partir do sistema de arquivos quando espaço é necessário, mas as capturas instantâneas são persistentes.

Esta demonstração mostrou dois dos utilitários de linha de comandos para o NiLFS(2): lscp (listar pontos de verificação e capturas instantâneas) e mkcp (fazer ponto de verificação ou captura instantânea). Também existe um utilitário chamado chcp , para conversão de um ponto de verificação para uma captura instantânea ou vice-versa, e rmcppara invalidar um ponto de verificação ou captura instantânea.

Dada a natureza temporal do sistema de arquivos, a NTT considerou algumas outras ferramentas muito inovadoras para o futuro—por exemplo, tls (temporal ls), tdiff (temporal diff) e tgrep (temporal grep). Introduzir a funcionalidade baseada em tempo parece ser a próxima etapa lógica.

O Extended Object File System (exofs)

O Extended Object File System (exofs) é um sistema de arquivos Linux tradicional construído sobre um sistema de armazenamento de objetos. O Exofs foi inicialmente desenvolvido pela Avnishay Traeger da IBM e, naquele momento, foi chamado de sistema de arquivos OSD, ou osdfs. A Panasas (uma empresa que constrói sistemas de armazenamento de objetos) desde então assumiu o projeto e o renomeou para exofs (já que sua origem é o sistema de arquivos ext2).

Um sistema de arquivos sobre um sistema de armazenamento de objetos

Conceitualmente, um sistema de armazenamento de objetos pode ser visualizado como um espaço de nomes simples de objetos e seus metadados associados. Compare isso aos sistemas de armazenamento tradicionais baseados em blocos, com os metadados ocupando alguns blocos para fornecer a cola semântica. Num nível alto, o exofs é construído como mostrado na Figura 3. O Virtual File System Switch (VFS) fornece o caminho para exofs, no qual exofs se comunica com o sistema de armazenamento de objetos através de um iniciador OSD local. O iniciador OSD implementa o conjunto de comandos SCSI padrão OSD T-10.

Figura 3. Visualização de alto nível do ecossistema exofs/OSD
Visualização de alto nível do ecossistema exofs/OSD
Visualização de alto nível do ecossistema exofs/OSD

A ideia por trás do exofs é fornecer um sistema de arquivos tradicional sobre um backstore OSD. Desta forma, é mais fácil migrar para o armazenamento de nível de objeto, porque o sistema de arquivos apresentado é um sistema de arquivos tradicional.

Mapeamento do sistema de arquivos

Cada objeto em um OSD é representado por um identificador de 64 bits em um espaço de nomes simples. Para sobrepor a interface POSIX padrão sobre um sistema de armazenamento de objetos, é necessário um mapeamento. O exofs fornece um mapeamento simples que também é escalável e extensível.

Os arquivos dentro de um sistema de arquivos são representados exclusivamente como inodes. O exofs mapeia inodes para os identificadores de objetos (OIDs) no sistema de objetos. A partir dai, os objetos são usados para representar todos os elementos do sistema de arquivos. Os arquivos são mapeados diretamente para objetos, e os diretórios são simplesmente arquivos que fazem referência aos arquivos contidos dentro do diretório (como nome do arquivo e pares inode-OID). Isto é ilustrado de forma simples na Figura 4. Outros objetos existem para suportar coisas como bitmaps de inode (para alocação de inode).

Figura 4. Visualização de alto nível das representações OSD
Visualização de alto nível das representações OSD
Visualização de alto nível das representações OSD

Os OIDs usados para representar objetos dentro do espaço de objetos têm 64 bits de tamanho, suportando, assim, um grande espaço de objetos.

Por que armazenamento de objetos?

O armazenamento de objetos é uma ideia interessante e torna um sistema muito mais escalável. Ele remove partes do sistema de arquivos do host e as empurra para dentro do subsistema de armazenamento. Existem desvantagens aqui, mas ao distribuir partes do sistema de arquivos para múltiplos terminais, você distribui a carga de trabalho, tornando o método baseado em objeto mais simples para escalar para sistemas de armazenamento muito maiores. Ao invés de o sistema operacional do host precisar se preocupar com o mapeamento de bloco-para-arquivo, o próprio dispositivo de armazenamento fornece esse mapeamento, permitindo ao host operar no nível de arquivo.

Os sistemas de armazenamento de objetos fornecem a capacidade de consultar os metadados disponíveis. Isso fornece algumas vantagens adicionais porque a capacidade de busca pode ser distribuída para os sistemas de objetos do terminal.

O armazenamento de objetos fez uma reaparição recentemente na área de armazenamento em nuvem. Os provedores de armazenamento em nuvem (que vendem armazenamento como um serviço) representam seu armazenamento como objetos em vez de API de bloco tradicional. Esses provedores implementam as APIs para transferência e gerenciamento de objeto e gerenciamento de metadados.

O que vem pela frente?

Ainda que o NiLFS(2) e o exofs sejam adições interessantes e úteis ao inventário do sistema de arquivos Linux, há mais a caminho. Vimos o Btrfs introduzido recentemente (da Oracle), que oferece uma alternativa Linux ao Zettabyte File System (ZFS) da Sun Microsystems. Outro recente sistema de arquivos é o Ceph, que fornece um sistema de arquivos distribuído baseado em POSIX confiável com nenhum ponto de falha. Hoje, encontramos um novo sistema de arquivos estruturado em log e a introdução de um sistema de arquivos sobre um armazenamento de objeto. O Linux continua a provar que é a plataforma de pesquisa escolhida, assim como um sistema operacional de classe corporativa.


Recursos para download


Temas relacionados


Comentários

Acesse ou registre-se para adicionar e acompanhar os comentários.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Linux
ArticleID=447869
ArticleTitle=Próxima Geração de Sistemas de Arquivos Linux: NiLFS(2) e exofs
publish-date=11182009