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.
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.
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 é 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.
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.
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
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.
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
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
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
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 é 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.
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.
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.
Aprender
-
Consulte
Visão Geral das Tecnologias de Memória Flash e Lista de Sistemas de Arquivos,
da wikipedia, incluindo os sistemas de arquivos baseados em disco, os sistemas de arquivos distribuídos e os sistemas de arquivos com propósitos especiais (inclusive os sistemas de arquivos de mídia de estado sólido).
-
Leia mais sobre a tecnologia flash NAND
vs. NOR.
-
"Anatomia do Sistema de Arquivos do Linux" de Tim
(developerWorks, outubro de 2007) apresenta o VFS,
suas principais estruturas e sua arquitetura. Ele também oferece uma introdução aos sistemas de arquivos e ilustra como o Linux pode oferecer suporte a tantos sistemas de arquivos simultaneamente.
-
Leia como o JFFS e seu sucessor, JFFS2 (arquivo PDF)
têm abordagens diferentes quanto ao gerenciamento de dispositivos flash.
-
Compare YAFFS a outros sistemas de arquivos flash populares.
-
LogFS e UbiFS são dois sistemas de arquivos flash novos que solucionam vários problemas associados aos atuais sistemas de arquivos flash.
- O MTD é um subsistema genérico para dispositivos de memória, como as partes do flash. Ele proporciona uma interface genérica entre os drivers de hardware de nível inferior e as camadas superiores do sistema de arquivos.
-
Cramfs e SquashFS são sistemas de arquivos somente leitura compactados para Linux. Embora ambos tenham sido elaborados para sistemas embarcados com restrições de memória, também serão encontrados SquashFS utilizados nas distribuições de Live CD.
Às vezes são encontrados com
UnionFS, que implementa uma montagem em conjunto de um sistema de arquivos (sobrepondo um sistema de arquivos sobre outro). O SquashFS apresenta a vantagem de melhor compactação e desempenho usando
LZMA e um
conjunto de correções.
- Leia
todos os artigos Anatomia de... de Tim
no developerWorks.
- Leia
todos os artigos Linux de Tim
no developerWorks.
- Na zona Linux do developerWorks,
encontre mais recursos para desenvolvedores Linux e varra nossos
artigos e tutoriais mais
conhecidos.
- Consulte todas as
dicas de Linux
e
tutoriais de Linux
no developerWorks.
- Fique atualizado com eventos técnicos e Webcasts do developerWorks.
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
- Envolva-se com a
comunidade do developerWorks
através de blogs, fóruns, podcasts e tópicos da comunidade em nossos
novos espaços do developerWorks.

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.