Avançar para a área de conteúdo

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

Na primeira vez que você efetua sign in no developerWorks, um perfil é criado para você. Informações selecionadas do seu perfil developerWorks são exibidas ao público, mas você pode editá-las a qualquer momento. Seu primeiro nome, sobrenome (a menos que escolha ocultá-los), e seu nome de exibição acompanharão o conteúdo que postar.

Todas as informações enviadas são seguras.

  • Fechar [x]

Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

Todas as informações enviadas são seguras.

  • Fechar [x]

Anatomia dos Sistemas de Arquivos Flash do Linux

Opções e Arquiteturas

M. Tim Jones, Consultant Engineer, Emulex Corp.
M. Tim Jones
M. Tim Jones é um arquiteto de firmwares embarcados e autor de Inteligência Artificial: Sistemas de Abordagem, GNU/Linux, Programação de Aplicativos AI (atualmente em sua segunda edição), Programação de Aplicativos AI (em sua segunda edição) e BSD Sockets Programming from a Multilanguage Perspective. Sua formação em engenharia vai desde o desenvolvimento de kernels para nave espacial geossincrônica até a arquitetura de sistema embarcado e o desenvolvimento de protocolos de interligação de redes. Tim é um Engenheiro Consultor para a Emulex Corp. em Longmont, Colorado.

Resumo:  É provável que já tenha ouvido falar de Journaling Flash File System (JFFS) e Yet Another Flash File System (YAFFS), mas sabe o que significa ter um sistema de arquivos que admite um dispositivo flash adjacente? Este artigo lhe apresenta os sistemas de arquivos flash para Linux®, explora como eles lidam com seus dispositivos consumíveis subjacentes (partes flash) por meio de controle de consumo e identifica os diversos sistemas de arquivos flash disponíveis com seus designs fundamentais.

Data:  20/Mai/2008
Nível:  Intermediário
Atividade:  2010 visualizações
Comentários:  


Atualmente, as unidades de estado sólido são bastante populares, mas já há bastante tempo os sistemas embarcados vêm utilizando dispositivos de estado sólido para armazenamento. Os sistemas de arquivos flash são encontrados em computadores de mão (PDAs), celulares, reprodutores de MP3, câmeras digitais, unidades flash USB (UFDs) e até em laptops. Em muitos casos, embora os sistemas de arquivos para dispositivos comerciais possam ser customizados e adquiridos, eles enfrentam os mesmos desafios discutidos abaixo.

Os sistemas de arquivos baseados em flash têm diversos formatos. Este artigo aborda alguns dos sistemas de arquivos de somente leitura e também revisa os vários sistemas de arquivos de leitura e gravação disponíveis atualmente e como eles funcionam. Antes, porém, vamos abordar os dispositivos flash e os desafios que eles apresentam.

Tecnologias de Memória Flash

A memória flash, presente em muitas tecnologias diferentes, é uma memória não-volátil, o que significa que seu conteúdo persiste após a remoção de sua fonte de energia. Para conhecer o histórico dos dispositivos de memória flash, consulte Recursos.

Dois dos tipos mais comuns de dispositivos flash são definidos por suas respectivas tecnologias: NOR e NAND. A tecnologia flash baseada em NOR é a mais antiga e oferecia suporte a um alto desempenho de leitura com baixo custo. Já a tecnologia flash NAND oferece maior capacidade com desempenho significativamente mais rápido para gravar e apagar. A NAND também exige uma interface de entrada/saída (E/S) muito mais complexa.

Normalmente, as partes flash são dividas em partições, permitindo que diversas operações aconteçam simultaneamente (apagar uma partição enquanto estiver lendo outra). Depois as partições são dividas em blocos (em geral de 64KB ou 128KB). Um firmware que utiliza as partições pode, em seguida, aplicar uma segmentação exclusiva nos blocos—por exemplo, segmentos de 512 bytes em um bloco, sem incluir metadados.

Os dispositivos flash apresentam uma restrição comum, exigindo gerenciamento de dispositivos quando comparados a outros dispositivos de armazenamento, como os discos virtuais. A única operação de gravação permitida em um dispositivo de memória flash é alterar um bit de um para zero. Caso seja necessário voltar a operação, o bloco precisa ser apagado (para reconfigurar todos bits para o estado inicial). Ou seja, outros dados válidos do bloco devem ser movidos até esse bloco para serem mantidos. Normalmente, a memória flash NOR pode ser programada a um byte por vez, enquanto a memória flash NAND deve ser programada em bursts de vários bytes (normalmente 512).

O processo de exclusão de um bloco difere entre os tipos de memória. Cada um exige uma operação especial de Exclusão que abrange um bloco completo de memória flash. A tecnologia NOR exige uma etapa anterior para zerar todos os valores antes que a operação de exclusão possa começar. Uma Exclusão é uma operação especial com o dispositivo flash e pode levar algum tempo. A exclusão é uma operação elétrica que puxa os elétrons de cada célula para dentro de um bloco inteiro.

Os dispositivos flash NOR geralmente necessitam de segundos para a operação de exclusão, enquanto um dispositivo NAND pode efetuar tal operação em milissegundos. Uma característica fundamental dos dispositivos flash é o número de operações de exclusão que podem ser desempenhadas. Em um dispositivo NOR, cada bloco na memória flash pode ser apagado até 100 mil vezes. As memórias flash NAND, por outro lado, podem ser apagadas até um milhão de vezes.


Desafios da Memória Flash

Além das restrições abordadas na seção anterior e dos seus resultados, o gerenciamento de dispositivos flash apresenta muitos desafios. Os três mais importantes são a coleta de lixo, o gerenciamento de blocos inválidos e o wear leveling.

Coleta de Lixo

Coleta de Lixo é o processo de recuperar blocos inválidos (os que apresentam certa quantidade de dados inválidos). Isso envolve mover os dados válidos até um bloco novo e, em seguida, apagar o bloco inválido, disponibilizando-o. Esse processo normalmente é feito em segundo plano ou quando necessário, se o sistema de arquivos estiver com pouco espaço disponível.

Gerenciamento de Blocos Inválidos

Com o passar do tempo, à medida que os dispositivos flash são utilizados, eles podem formar blocos inválidos ou, até mesmo, o próprio fabricante pode fornecer blocos inválidos e que não podem ser utilizados. É possível detectar a presença de blocos inválidos em uma operação flash malsucedida (por exemplo, em uma exclusão) ou em uma operação de gravação inválida (descoberta por meio de um código de correção de erro inválido ou ECC).

Após a identificação dos blocos inválidos, eles são marcados no próprio flash, em uma tabela de blocos inválidos. Isso depende do dispositivo, embora ele possa ser implementado em um conjunto separado de blocos reservados separadamente dos blocos de dados normais. O processo de manipulação dos blocos inválidos—estejam eles com defeitos de fábrica ou com defeitos que surgiram com o passar do tempo—é chamado de gerenciamento de blocos inválidos. Em alguns casos, essa funcionalidade é implementada no hardware por um microcontrolador interno e, portanto, invisível ao sistema de arquivos de nível superior.

Wear Leveling

Lembre-se de que os dispositivos flash são partes consumíveis: é possível executar um número finito de ciclos de exclusão em cada bloco antes que ele se torne inválido (e, portanto, precise ser marcado pelo gerenciamento de blocos inválidos). Para maximizar a vida do flash, são fornecidos algoritmos de wear-leveling. O wear leveling apresenta dois formatos: wear leveling dinâmico e wear leveling estático.

O wear leveling dinâmico lida com o problema de um número limitado de ciclos de exclusão de um determinado bloco. Em vez de utilizar blocos de forma aleatória conforme sua disponibilidade, os algoritmos do wear leveling dinâmico tentam distribuir igualmente o uso dos blocos, para que cada um seja usado de modo uniforme. Os algoritmos do wear-leveling estático se deparam com um problema ainda mais interessante. Além do número máximo de ciclos de exclusão, alguns dispositivos flash não ultrapassam um número máximo de ciclos de leitura entre os ciclos de exclusão. Ou seja, se os dados ficarem muito tempo em um bloco e forem lidos várias vezes, podem se dissipar e isso pode resultar em perda. Os algoritmos do wear-leveling estático lidam com isso movendo periodicamente os dados mais antigos para blocos novos.


Arquitetura do Sistema

Até aqui, mostramos os dispositivos flash e seus desafios fundamentais. Agora observe como essas peças se juntam em uma arquitetura em camadas (consulte a Figura 1). Em primeiro lugar temos o Sistema de Arquivos Virtuais (VFS), que apresenta uma interface comum para aplicativos de nível mais alto. Após o VFS, segue-se o sistema de arquivos flash, que será abordado na próxima seção. Em seguida, o Flash Translation Layer (FTL), que fornece gerenciamento geral do dispositivo flash, inclusive alocação de blocos de dispositivos flash subjacentes, conversão de endereço, wear leveling dinâmico e coleta de lixo. Em alguns dispositivos flash, uma parte do FTL pode ser implementada no hardware.


Figura 1. Arquitetura Básica de um Sistema Flash
Arquitetura Básica de um Sistema Flash

O kernel do Linux usa a interface Memory Technology Device (MTD), uma interface genérica para dispositivos flash. O MTD pode detectar automaticamente a largura do barramento do dispositivo flash e o número de dispositivos necessários à implementação dessa largura.


Sistemas de Arquivos Flash

Vários sistemas de arquivos flash estão disponíveis para Linux. As seções a seguir explicam o design e as vantagens de cada um deles.

Sistema de Arquivos Flash com Registro de Mudanças

Um dos primeiros sistemas de arquivos flash para Linux é chamado de Sistema de Arquivos Flash com Registro de Mudanças. O JFFS é um sistema de arquivos estruturado em log elaborado para os dispositivos flash NOR. Ele era exclusivo e lidava com vários problemas dos dispositivos flash, embora criasse outros.

O JFFS visualiza o dispositivo flash como um log circular de blocos. Os dados gravados no flash são gravados até o fim e os blocos no início são procurados. O espaço entre o início e o fim são livres; quando esse espaço fica menor, a garbage collector é executada. O coletor de lixo move os blocos válidos até o fim do log, ignora os blocos inválidos ou obsoletos e os apaga (consulte a Figura 2). O resultado é um sistema de arquivos que realiza automaticamente o wear leveling estático e dinâmico. O problema principal nesta arquitetura é que o dispositivo flash era apagado com frequência (em vez de uma estratégia de otimização de exclusão), o que o desgastava muito depressa.


Figura 2. Log Circular antes e depois da garbage collector
Log Circular antes e depois da Coleta de Lixo

Quando um JFFS é montado, os detalhes estruturais são lidos na memória, o que pode diminuir o tempo de montagem e consumir mais memória do que o desejado.

Sistema de Arquivos Flash 2 com Registro de Mudanças

Embora o JFFS fosse bastante prático em sua época, seu algoritmo de wear leveling tendia a abreviar a vida dos dispositivos flash NOR. O resultado era uma nova elaboração do algoritmo subjacente para a remoção do log circular. O algoritmo JFFS2 foi elaborado para dispositivos flash NAND e também apresenta desempenho e compactação aprimorados.

No JFFS2, cada bloco no flash é tratado de forma independente. O JFFS2 mantém as listas de blocos para que o wear leveling do dispositivo seja efetuado de forma satisfatória. A lista limpa representa blocos no dispositivo repletos de nós válidos. A lista suja contém blocos com pelo menos um nó obsoleto. Por fim, a lista livre representa os blocos que foram apagados e se encontram disponíveis para uso.

O algoritmo da garbage collector pode então decidir, de forma inteligente, o que buscar. Hoje em dia, o algoritmo seleciona, de forma probabilista, das listas limpa ou suja. A lista suja é selecionada 99% das vezes na busca de blocos (movendo o conteúdo válido para outro bloco) e a lista limpa é selecionada 1% das vezes (apenas movendo o conteúdo para um novo bloco). Em ambos os casos, o bloco selecionado é apagado e colocado na lista livre (consulte a Figura 3). Isso permite que o coletor de lixo reutilize blocos que estão obsoletos (ou parcialmente) e que ainda mova os dados do flash, oferecendo suporte ao wear leveling estático.


Figura 3. Gerenciamento de Blocos e Garbage Collecot no JFFS2
Gerenciamento de Blocos e Garbage Colector no JFFS2

Yet Another Flash File System

O YAFFS é outro sistema de arquivos flash desenvolvido para o flash NAND. A primeira versão (YAFFS) oferecia suporte a dispositivos flash com páginas de 512 bytes, enquanto a versão mais recente (YAFFS2) oferece suporte a dispositivos mais novos, com tamanhos maiores de páginas e restrições de gravação maiores.

Na maioria dos sistemas de arquivos flash, os blocos obsoletos são marcados como tais, mas o YAFFS2 marca também os blocos com números de sequência que aumentam de forma uniforme. Quando o sistema de arquivos é escaneado no momento da montagem, os inodes válidos podem ser rapidamente identificados. O YAFFS também mantém árvores em RAM para representar a estrutura de blocos do dispositivo flash, inclusive a montagem rápida por meio de verificação de pontos —um processo que salva a estrutura em árvore RAM no dispositivo flash em uma desmontagem normal para que ele possa ser rapidamente lido e restaurado na RAM no momento da montagem (consulte a Figura 4). O desempenho no momento da montagem é uma grande vantagem do YAFFS2 sobre outros sistemas de arquivos flash.


Figura 4. Otimização do Tempo de Montagem do YAFFS2 através da Verificação de Ponto
Otimização do Tempo de Montagem do YAFFS2 através da Verificação de Ponto

Sistemas de Arquivos Somente Leitura Compactados

Em alguns sistemas embarcados, não é preciso fornecer um sistema de arquivos mutável: Basta que haja um sistema imutável. O Linux oferece suporte a vários sistemas de arquivos somente leitura; dois dos mais úteis são cramfs e SquashFS.

Cramfs

Cramfs é um sistema de arquivos somente leitura Linux compactados que podem existir nos dispositivos flash. Suas características principais são a simplicidade e o uso eficaz de espaço. Esse sistema de arquivos é utilizado em designs embarcados com áreas de cabeçalho reduzidas.

Enquanto os metadados cramfs não são compactados, o camfs utiliza a compactação zlib em cada página, de modo a permitir o acesso aleatório a elas (que são descompactadas quando acessadas).

É possível experimentar o cramfs com o utilitário mkcramfs e o dispositivo loopback.

SquashFS

O SquashFS é outro sistema de arquivos somente leitura Linux compactados, útil nos dispositivos flash. Também é possível encontrar o SquashFS em várias distribuições do Live CD Linux. Além de oferecer suporte à compactação zlib, o SquashFS utiliza o Lembel-Ziv-Markov chain Algorithm (LZMA) para compactação e velocidade aprimoradas.

Assim como o cramfs, é possível utilizar o SquashFS em um sistema padrão Linux com mksquashfs e o dispositivo de loopback.


Indo Além

Como a maioria dos softwares livres, o software continua evoluindo e novos sistemas de arquivos flash estão em desenvolvimento. Uma alternativa interessante ainda em desenvolvimento é o LogFS, que inclui algumas ideias inéditas. Por exemplo, o LogFS mantém uma estrutura em árvore no próprio dispositivo flash para que os tempos de montagem sejam semelhantes aos sistemas tradicionais de arquivos, como o ext2. Ele também usa uma árvore substituta para a garbage collector (um formato B+tree). O que torna o LogFS especialmente interessante, porém, é seu caráter de grande escalabilidade e o fato dele oferecer suporte a grandes partes do flash.

Com a crescente popularidade dos sistemas de arquivos flash, você verá que existe uma quantidade considerável de pesquisas aplicadas a eles. O LogFS é um exemplo, mas outras opções, como o UbiFS, também estão crescendo. Os sistemas de arquivos flash apresentam uma arquitetura interessante e continuarão a ser uma fonte de inovações no futuro.


Recursos

Aprender

Obter produtos e tecnologias

  • Solicite o SEK para Linux, um conjunto de dois DVDs que contém o software de período experimental IBM mais recente para Linux a partir do DB2®, Lotus®, Rational®, Tivoli®e WebSphere®.

  • Com o Software de período experimental IBM, disponível para download diretamente do developerWorks, construa seu próximo projeto de desenvolvimento em Linux.

Discutir

Sobre o autor

M. Tim Jones

M. Tim Jones é um arquiteto de firmwares embarcados e autor de Inteligência Artificial: Sistemas de Abordagem, GNU/Linux, Programação de Aplicativos AI (atualmente em sua segunda edição), Programação de Aplicativos AI (em sua segunda edição) e BSD Sockets Programming from a Multilanguage Perspective. Sua formação em engenharia vai desde o desenvolvimento de kernels para nave espacial geossincrônica até a arquitetura de sistema embarcado e o desenvolvimento de protocolos de interligação de redes. Tim é um Engenheiro Consultor para a Emulex Corp. em Longmont, Colorado.

Ajuda para Relatar Abuso

Relatar abuso

Obrigado. Esta entrada foi sinalizada para atenção do moderador.


Ajuda para Relatar Abuso

Relatar abuso

Falha no envio do Relatório de abuso. Tente novamente mais tarde.


developerWorks: Registre-se


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos de uso do developerWorks.

 


Na primeira vez que você efetua sign in no developerWorks, um perfil é criado para você. Informações selecionadas do seu perfil developerWorks são exibidas ao público, mas você pode editá-las a qualquer momento. Seu primeiro nome, sobrenome (a menos que escolha ocultá-los), e seu nome de exibição acompanharão o conteúdo que postar.

Selecione seu nome de exibição

Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

(Deve possuir de 3 a 31 caracteres.)


Ao clicar em Enviar, você concorda com os termos de uso do developerWorks.

 


Classificar este artigo

Comentários

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Linux
ArticleID=383081
ArticleTitle=Anatomia dos Sistemas de Arquivos Flash do Linux
publish-date=05202008
author1-email=mtj@mtjones.com
author1-email-cc=

Conheça a IBM da sua cidade

Virtual Branch Office Brasil

A IBM está mais perto do que você imagina!


Tags

Help
Use o campo de pesquisa para encontrar todos os tipos de conteúdo no My developerWorks com essa tag.

Use a barra de rolagem para ver mais ou menos tags.

Tags populares mostra as principais tags para esta zona de conteúdo em particular (por exemplo, Java technology, Linux, WebSphere).

Minhas tags mostra suas tags para esta zona de conteúdo em particular (por exemplo, Java technology, Linux, WebSphere).

Use o campo de pesquisa para localizar todos os tipos de conteúdo no Meu developerWorks com essa tag. Tags populares mostra as tags principais para essa zona de conteúdo particular (por exemplo, tecnologia Java, Linux, WebSphere). My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere). Minhas tags mostra as suas tags para essa zona de conteúdo em particular (por exemplo, tecnologia Java, Linux, WebSphere).