Memoria Flash

Linux Magazine Online http://www.linuxmag.com.br/lm/article_online/e...
Menu
Home
Revista
Edies anteriores
Edies especiais
Community Edition
Entrevistas
Artigos Online
Sees
Entrevistas
Corporate
Anlise
Tutorial
SysAdmin
Programao
Linux User
Comunidade
Editorial
Colunas
Redes
Segurana
Insegurana
Assine
Linux Magazine
Admin Redes & Segurana
Loja virtual
Anuncie
Frum
Blogs
Blog do Maddog
Blog do Ricardo Olonca
Blog do Elias Praciano
Blog da Flvia Jobs
Whitepapers
Minha LM
Artigo
Aprenda a trabalhar com memria ash
Os elegantes tablets e smartphones da atual gerao digital abrigam memria Flash, que
economiza espao e energia. Neste artigo, explicamos suas caractersticas e sugerimos
sistemas apropriados para o Linux.
Por Michael Opdenacker
Computadores mais antigos com discos e ventoinhas cada vez mais tm sido escondidos em centros de dados,
blindados pela nuvem. Desta forma, os usurios no notam quanto calor produzem ou quanto barulho eles
fazem. E novos computadores como smartphones e tablets permeiam muitas reas da vida atualmente: anal,
so dispositivos mveis, silenciosos e ecientes em termos de energia.
Uma razo pela qual so mais ecientes vem do fato de que sistemas de armazenamento embarcado utilizam
chips em vez de discos rotativos. Memria Flash em estado slido no possui partes mveis e , portanto,
muito robusta por no possuir estresse mecnico. Alm disso, a memria sem disco acessa os dados
desejados mais rapidamente por no exigir um cabeote em movimento.
1 of 17 29-04-2017 20:38
Um dispositivo sem disco tambm produz menos calor, tornando desnecessrio o barulho provocado pela
vetoinha. Neste artigo, descreveremos alguns sistemas de arquivos Linux e ferramentas que operam com uma
enorme variedade de dispositivos de armazenamento Flash suportados pelo Linux.
Armazenamento Flash
O armazenamento Flash, tambm chamado de estado slido (solid state), possui muitas vantagens em
relao ao armazenamento rotativo (rotating storage). Em primeiro lugar, a ausncia de peas mecnicas e
em movimento elimina o rudo, aumenta a resistncia e segurana a choques e vibraes, e reduz a
dissipao de calor e consumo de energia. Segundo, o acesso aleatrio a dados muito mais rpido, pois j
no preciso mover um cabeote de disco para o local correto no dispositivo, o que pode levar alguns
milissegundos.
Figura 1 O bloco grande no meio do computador de placa nica BeagleBoard um sistema OMAP-on-a-chip
da Texas Instruments, sob o qual o Flash NAND montado.
O Flash tambm tem suas decincias. Primeiro, pelo mesmo preo, temos apenas um dcimo da capacidade
de armazenamento. Segundo, escrever armazenamento Flash possui restries especiais; no podemos
escrever para o mesmo local de um bloco Flash vrias vezes sem apagar todo o bloco, chamado de bloco de
apagar (erase block). Esta restrio tambm pode fazer com que a velocidade de escrita seja muito menor
que a de leitura. Terceiro, os blocos Flash podem suportar apenas um nmero limitado de erases de alguns
milhares de chips NAND mais densos a um milho, no mximo. Hardware e software, portanto, precisam
espalhar as operaes de escrita em um processo conhecido como nivelamento de desgaste (wear leveling).
NAND/NOR
2 of 17 29-04-2017 20:38
A memria Flash NOR (Not OR), que nomeia as portas usadas no chip, foi o primeiro tipo de armazenamento
Flash inventado. O NOR conveniente pois a CPU pode acessar qualquer byte diretamente e em ordem
aleatria. Deste modo, o processador pode executar o cdigo diretamente da NOR, permitindo que seja
utilizado em bootloaders, e no necessita ser copiado para a RAM antes de ser executado.
O tipo mais popular de armazenamento a memria Flash NAND (Not AND) (gura 1), que oferece maior
capacidade de armazenamento ao menor preo. A desvantagem que, como um dispositivo externo, o
armazenamento NAND est conectado via controlador, atravs do qual possvel acessar os dados. A CPU
no pode executar cdigo da NAND sem copiar o cdigo para a memria RAM primeiro. Outra restrio que
os dispositivos Flash NAND podem possuir blocos defeituosos (bad blocks) fora da caixa, exigindo solues de
hardware ou software que funcionam em torno desta limitao durante a operao.
Dois tipos de armazenamento Flash NAND esto disponveis hoje. O primeiro tipo emula um bloco padro de
interface e contm um hardware Flash Translation Layer (camada de traduo Flash) que cuida de apagar
blocos e implementar nivelamento de desgaste, assim como o gerenciamento de blocos defeituosos.
Dispositivos deste tipo incluem drives USB Flash, cartes de mdia, cartes multimdia embutidos (eMMCs), e
discos de estado slido (da sigla SSDs, de solid state disks). O sistema operacional no tem controle sobre a
forma como so geridos os setores Flash pois s considera um dispositivo emulado de bloco.
Embora esta abordagem reduza a complexidade do software do lado do sistema operacional, os fabricantes
de hardware costumam manter em segredo os algoritmos da camada de traduo Flash, deixando os
desenvolvedores de sistemas sem alternativas para vericar e ajustar estes algoritmos ou corrigir
implementaes pobres.
Figura 2 A arquitetura MTD do kernel Linux permite o gerenciamento independente de hardware de

armazenamento Flash.
O segundo tipo de memria NAND a raw Flash. O sistema operacional tem acesso ao controlador de Flash e
pode gerenciar diretamente seus blocos. O raw Flash pode usar um block erase count para determinar com
qual frequncia um bloco tem sido sobrescrito. O kernel Linux implementa um subsistema Memory
Technology Device (MTD) que permite o acesso e controle de vrios tipos de dispositivos Flash com uma
interface comum (gura 2).
Parties
Acesso bruto (raw access) signica que nenhum sistema de arquivo necessrio, a menos que o usurio
3 of 17 29-04-2017 20:38
deseje armazenar muitos arquivos; um nico e grande arquivo binrio suciente para alguns aplicativos.
Dispositivos MTD geralmente so particionados para denir reas com ns especcos, como o gerenciador
de inicializao (bootloader) ou o sistema de arquivos raiz. Acessar as parties e o armazenamento raw ash
algo semelhante a acessar dispositivos brutos do bloco (raw block devices) atravs de arquivos de
dispositivos (por exemplo, todo o dispositivo com /dev/sda ou parties com /dev/sda1, /dev/sda2, etc.
Declarar parties somente leitura (da sigla RO, de read-only) pode proteger o sistema contra erros e
tentativas de modicao no autorizadas. Observe tambm que as parties no podem ser ignoradas,
acessando todo o dispositivo como compensao, uma vez que o Linux no possui nenhum arquivo de
dispositivo para este tipo de acesso.
A gura 3 mostra um esquema de particionamento tpico. Em contraste com os discos rgidos, a tabela de
partio no salva no ambiente MTD um local inseguro por conta dos blocos potencialmente ruins. Em vez
disso, uma estrutura de dados no kernel Linux dene as parties.
A listagem 1 mostra o excerto relevante do arquivo arch/arm/machOMAP2/board-OMAP3Beagle.c, que dene

as parties para o Flash NAND na BeagleBoard. Felizmente, podemos substituir estas conguraes padro
sem necessidade de recompilar o kernel. Para identicar o nome do dispositivo MTD, percorra as mensagens
de inicializao do kernel. Neste exemplo de BeagleBoard, a listagem 2 mostra que o nome do dispositivo
NAND omap2-nand.0.
Logo que o nome do dispositivo conhecido, o parmetro de boot mtdparts passa no particionamento com
(tudo em uma nica linha):
mtdparts=omap2nand.0:128k(XLoader)ro,256k(UBoot)ro,128k(Environment),4m(Kernel)ro,32m(RootFS)ro,(Data)
O cdigo acima dene seis parties:
Primeiro estgio do bootloader (128KB, RO) Bootloader U-Boot (256KB, RO) Variveis de ambiente
U-Boot (128KB) Kernel Linux (4MB, RO) Sistema de arquivos raiz (16MB, RO) Dados (espao de
armazenamento restante)
O tamanho da partio deve ser um mltiplo do tamanho do erase block, que pode ser encontrado no sistema
de destino em /sys/class/mtd/mtdx/erasesize. Os tamanhos das parties recm-criadas, que o usurio
pode ver em /proc/mtd esto em hexadecimal (listagem 3).
Nomes de arquivos para parties de dispositivo de bloco se referem ao nome completo do dispositivo (por
exemplo, /dev/sda1 para a primeira partio /dev/sda), mas note que as parties MTD so mostradas como
dispositivos MTD independentes; portanto, o mtd1 poderia ser a segunda partio do primeiro dispositivo
Flash ou a primeira partio do segundo dispositivo Flash. No possvel perceber a diferena de nomes dos
dispositivos.
A partio "Environment onde as variveis de ambiente U-Boot bootloader so armazenadas. Estas

variveis podem ser alteradas a partir do U-Boot Shell mas tambm a partir do Linux, piscando (ashing) uma
nova imagem para a partio. Os desenvolvedores da Free Electrons tm contribudo de forma bastante til
para gerar tal imagem [1].
Manipulao de dispositivos MTD
4 of 17 29-04-2017 20:38
Os dispositivos MTD podem ser endereados atravs de duas interfaces. A primeira utiliza o identicador
(letra) do dispositivo dev/mtd//N// (onde N o nmero do dispositivo MTD) e o driver mtdchar. Em
particular, este identicador fornece os comandos ioctl, que so geralmente utilizados por mtd-utils para
manipular e apagar blocos de um dispositivo MTD. A segunda interface fornece o dispositivo de bloco
dev/mtdblock//N// e o driver mtdblock. Este dispositivo usado principalmente para montar sistemas de
arquivos MTD, como JFFS2 e YAFFS2, pois o comando mount s funciona com dispositivos de bloco.
Embora possamos ser tentados a usar este dispositivo para gravar no MTD, o driver correspondente no
sosticado o suciente para uso em produo por no suportar nivelamento de desgaste; uma srie de
gravaes para a mesma parte do dispositivo de bloco poderia danicar muito rapidamente os
correspondentes erase blocks. Pior, se copiarmos uma imagem de sistema de arquivos para /dev/mtdblock
//N//, o sistema de arquivos poderia ser corrompido pois os blocos danicados no so levados em conta.
Portanto, a maneira ideal de manipular dispositivos MTD atravs do identicador de interface (character
interface) e mtd-utils [2].
Os comandos mais importantes so:
mtdinfo: informaes detalhadas sobre um dispositivo MTD flash_eraseall: apaga por completo um
dado dispositivo MTD flashcp: escreve para Flash NOR nandwrite: escreva para Flash NAND
Utilitrios UBI (veja o tpico UBI e UIFS) mkfs.jffs2, mkfs.ubifs: ferramentas de criao de imagem de
sistema de arquivo Flash
Estes comandos esto disponveis atravs do pacote mtdutils em distribuies GNU/Linux e tambm podem
ser compilados de forma cruzada (cross-compiled) a partir da fonte por sistemas embarcados Linux, tais como
o BuildRoot [3] e o OpenEmbedded [4]. Simples implementaes dos comandos mais comuns tambm esto
disponveis no BusyBox [5], tornando muito mais fcil de fazer a compilao cruzada em sistemas embarcados
menos complexos.
JFFS2
O Journaling Flash File System verso 2 (JFFS2) [6], que foi adicionado ao kernel Linux em 2001, um
sistema de arquivos muito popular para o armazenamento Flash. Como esperado para um sistema de
arquivos Flash, ele implementa a deteco e gesto do bloco danicado, bem como o nivelamento de
desgaste. Tambm projetado para car em um estado consistente aps falhas abruptas de energia e
quebras do sistema. Por ltimo, mas no menos importante, o JFFS2 tambm armazena dados compactados.
Diversos esquemas de compresso esto disponveis de acordo com o que mais importante: desempenho
para ler/escrever ou taxa de compresso. Por exemplo, o zlib comprime melhor que o lzo, mas tambm
muito mais lento.
A implementao de arquivos de sistemas em Flash possui restries especiais. Para modicar um arquivo
existente, no podemos simplesmente copiar os blocos correspondentes para a RAM, apag-los e piscar
(ash) os blocos com a nova verso. Primeiro, uma falha de energia durante este procedimento poderia
causar perda de dados irrecuperveis. Segundo, podemos rapidamente desgastar blocos especcos, fazendo
vrias atualizaes para o mesmo arquivo.
Uma alternativa seria escrever os novos dados para um novo bloco e atualizar os indicadores (pointers) para
os dados antigos. Contudo, isto implicaria outra escrita, que poderia provocar outras modicaes at que a
referncia root fosse alcanada.
O JFFS2 resolve estes problemas com uma abordagem de log estruturado [7]. Cada arquivo mapeado para
5 of 17 29-04-2017 20:38
um n com dados e metadados, e cada n tem um nmero de verso associado. Em vez de fazer alteraes
locais, a ideia escrever uma verso mais recente do n em outra parte do erase block com espao livre. Isto
simplica as operaes de escrita, mas complica as operaes de leitura, pois o sistema de arquivos precisa
localizar o n mais recente.
Figura 3 O armazenamento MTD normalmente dividido em parties gravveis e somente leitura.
Para otimizar o desempenho, o JFFS2 mantm um mapa de memria dos ns mais recentes para cada
arquivo; no momento da montagem, digitaliza os ns, cria e armazena o mapa. Uma vez que o tempo de
montagem do JFFS2 proporcional ao nmero de ns, sistemas embarcados utilizando JFFS2 em grandes
parties Flash podero incorrer em enormes sanes no momento de inicializao. Felizmente, foi
adicionada uma opo do kernel CONFIG_JFFS2_SUMMARY que confere ao Linux o armazenamento do mapa
entre as aes de montagem no dispositivo Flash, reduzindo drasticamente o tempo de montagem. No
entanto, esta opo no ativada por padro.
Ns mais velhos devem ser recuperados em algum ponto para manter o espao livre para novas escritas. Um
n criado como vlido e considerado obsoleto quando uma nova verso criada. O JFFS2 gerencia
trs tipos de blocos Flash:
Blocos limpos, que contm apenas ns vlidos Blocos sujos, que contm pelo menos um n obsoleto
Blocos livres, que no contm nenhum n
O JFFS2 executa um coletor de lixo em segundo plano, que recicla blocos sujos transformando-os em blocos
livres. Faz isso atravs do recolhimento de todos os ns vlidos em um bloco sujo e os copia para um bloco
limpo (com o espao que restar) ou para um bloco livre. O antigo bloco sujo ento apagado e marcado como
livre. Para fazer todos os erase blocks participarem do nivelamento de desgaste, o coletor de lixo
ocasionalmente tambm consome blocos limpos.
H duas maneiras de criar uma partio JFFS2. A primeira apagar a partio, format-la para JFFS2, e
depois mont-la:
flash_eraseall j /dev/mtd2
mount t jffs2 /dev/mtdblock2 /mnt/flash
o flash_eraseall e o -j apagam a partio do Flash e os formata para JFFS2. A segunda opo geralmente
uma melhor combinao para o uxo integrado de trabalho do desenvolvedor pois cria a imagem JFFS2 no
6 of 17 29-04-2017 20:38
computador desktop e escreve a imagem na partio. Para criar a imagem, use o comando mkfs.jffs2
fornecido pelo mtd-utils, mas no se confunda com seu nome: ao contrrio de alguns outros comandos mkfs,
ele no cria um sistema de arquivos, mas uma imagem de sistema de arquivos.
O comando seguinte cria um arquivo de imagem com o nome rootfs.jffs2. Para este exemplo, vamos
assumir que o tamanho do erase block de 256MB.
mkfs.jffs2 pad nocleanmarkers eraseblock=256 d rootfs/ o rootfs.jffs2
O parmetro -d indica o diretrio com o contedo desejado para o sistema de arquivos e o --pad cria uma
imagem que de tamanho mltiplo ao do erase block; o nocleanmarkers s deve ser utilizado para o
Flash NAND. Para formatar a partio alvo e escrever a imagem, utilize:
flash_eraseall /dev/mtd2
nandwrite p /dev/mtd2 rootfs.jffs2
Se a imagem menor que a partio, o JFFS2 ainda pode utilizar todo o espao posteriormente, fornecido
pela partio que foi completamente apagada anteriormente. Para preparar dispositivos de produo, muito
mais conveniente escrever as parties MTD do bootloader, utlizando um comando que pode lidar com os
blocos danicados sem inicializar o Linux. Desta forma, utilitrios de desenvolvimento como o
flash_eraseall no precisam estar na raiz do sistema de arquivos Linux, que outra razo pela qual as
imagens do sistema de arquivos so teis.
Normalmente, baixamos a imagem do sistema de arquivos para a memria RAM e copiamos a imagem para o
Flash. Quando fazemos isso, apenas temos que nos certicar de haver copiado o tamanho exato da imagem.
Com as imagens JFFS2, se copiarmos mais bytes da RAM para o Flash, acabaremos escrevendo bytes
aleatrios no nal da imagem, o que ir corromper o sistema de arquivos.
YAFFS2
Uma alternativa ao JFFS2 o YAFFS2 [8] (sigla para Yet Another Flash Filesystem) encontrado em
smartphones com as primeiras verses do Android. O YAFFS2 no usa compresso, mas apresenta tempos de
montagem muito mais rpidos, bem como melhor desempenho de escrita e leitura. O cdigo duplamente
licenciado, sob o GPL e uma licena proprietria (ou seja, GPL para uso no kernel Linux e a licena para
sistemas operacionais proprietrios). A receita da licena proprietria tem nanciado seu desenvolvimento.
O YAFFS2 menos popular que o JFFS2, provavelmente por no fazer parte do planejamento do kernel Linux.
Em vez disso, est disponvel como um patch externo com um conjunto de scripts auxiliares. Um esforo foi
feito para t-lo na linha de frente cerca de um ano atrs, mas esta tentativa falhou pois as alteraes
solicitadas pelos mantenedores do kernel teriam quebrado a portabilidade para outros sistemas operacionais.
Depois de fazer o patch do kernel, o usurio pode criar um novo sistema de arquivos YAFFS2 com o comando:
flash_eraseall /dev/mtd2
O sistema de arquivos formatado automaticamente na primeira montagem:
7 of 17 29-04-2017 20:38
mount t yaffs2 /dev/mtdblock2/mnt/flash
Outra opo consiste em utilizar a ferramenta mkyaffs, dos utilitrios YAFFS2 [9].
UBI e UBIFS
O JFFS2 e o YAFFS2 tm um problema em comum: eles implementam o nivelamento de desgaste,

restringindo-o a parties individuais. No entanto, os nveis de utilizao podem ser muito diferentes.
Parties so montadas muitas vezes no modo somente leitura, enquanto as parties de dados esto
expostas a muitas escritas razo pela qual so conhecidas como parties quentes. Para evitar o desgaste
de parties quentes muito rapidamente, todas as reas da memria Flash precisam participar do
nivelamento de desgaste. Isto exatamente o que o projeto Unsorted Block Images (UBI) oferece.
O UBI uma camada acima do MTD que gerencia erase blocks e bad blocks e implementa o nivelamento de
desgaste, tirando estas tarefas dos ombros do sistema de arquivos. O UBI tambm suporta parties ou
volumes exveis, que podem ser criados e redimensionados dinamicamente, parecido com o que o Logical
Volume Manager opera para dispositivos de bloco.
O UBI implementa o Logical Erase Blocks (LEBs), que o mapeia para o Physical Erase Blocks (PEBs) (gura
4). Camadas superiores, tais como sistemas de arquivos, apenas visualizam os LEBs. Se uma LEB visualiza
muita ao, o UBI pode trocar os ponteiros, substituindo o PEB quente por um frio. Este mecanismo
requer alguns PEBs livres para trabalhar de forma eciente, e a sobrecarga faz a UBI menos apropriada para
dispositivos menores com apenas alguns megabytes de espao.
Um sistema de arquivos para UBI, chamado UBIFS, foi criado pelo projeto MTD Linux como sucessor do
JFFS2. O UBIFS suporta a compresso e apresenta desempenhos de mount, escrita e leitura muito melhores.
No Linux, o UBI e o UBIFS so iniciados com alguns comandos. Primeiro, o root precisa montar o diretrio do
dispositivo como um pseudo sistema de arquivos devtmpfs. O comando
ubiformat /dev/mtd1
exclui uma partio Flash sem precisar reiniciar a contagem erase (erase count). Para habilitar o UBI na
partio MTD, digite:
ubiattach /dev/ubi_ctrl m 1
Isto cria uma nova identidade (letra) para o dispositivo, /dev/ubi0. Agora podemos criar um ou vrios
volumes sobre o dispositivo,
ubimkvol /dev/ubi0 N test s 116MiB
ubimkvol /dev/ubi0 N test m
onde o -m o tamanho mximo disponvel. Para montar um sistema de arquivos UBIFS vazio no novo volume
de teste, insira
mount t ubifs ubi0:test /mnt/flash
8 of 17 29-04-2017 20:38
e para popular o sistema de arquivos com os arquivos. Uma abordagem alternativa primeiro criar uma
imagem do sistema de arquivos UBIFS com o comando mkfs.ubifs e copiar a imagem com ubiupdatevol.
Outra abordagem criar uma imagem de todo o espao UBI, que pode ser escrito do bootloader com o
comando que pode lidar com blocos danicados (bad blocks). Para fazer isso, primeiro crie um arquivo
ubi.ini descrevendo o espao UBI, seus volumes e seus contedos. Um exemplo mostrado na listagem 4.
Este arquivo descreve quais volumes devem ser criados, juntamente com seus tamanhos. A imagem UBI
criada com o comando
ubinize o ubi.img p 128KiB m 4096 ubi.ini
que tambm especica erase blocks fsicos 128KB e um tamanho mnimo de I/O de 4096 bytes. Para
transferir a imagem, use uma ferramenta bootloader que possa lidar com os bad blocks. Alm disso, a linha
de comando do kernel precisa da opo ubi.mtd=1 (equivalente ao ubiattach).
Se quiser que o UBIFS controle a partio root, adicione
rootfstype=ubifs root=ubi0:rootfs
ao comando boot.
LogFS
O LogFS [10] outro sistema de arquivos estruturado em log para a memria Flash que possui um design
inovador e tem sido parte principal do kernel Linux desde a verso 2.6.34. O inovador sistema de arquivos
poderia ter inuncia sobre o UBIFS mas, infelizmente, mostrou-se instvel, causando problemas no kernel
no momento de desmontagem, quando testado pela Free Electrons. Graas integrao com o kernel Linux
ocial, h boas chances de que o desenvolvedor venha a resolver estes problemas.
SquashFS
Parties somente leitura podem usar o sistema de arquivos de blocos SquashFS em dispositivos MTD. Copiar
uma imagem SquashFS diretamente para o dispositivo /dev/mtdblock//N// funciona bem anal, no temos
que nos preocupar com o nivelamento de desgaste at encontrar bad blocks no dispositivo. Mais uma vez, o
driver mtdblock no pode lidar com bad blocks, ento outra soluo se faz necessria.
Figura 4 O UBI gerencia volumes lgicos da mesma forma que o Logical Volume Manager, garantindo
9 of 17 29-04-2017 20:38
desgaste equilibrado entre os blocos fsicos.
Uma possibilidade consiste em utilizar o driver gluebi, que emula um dispositivo MTD em cima de um
volume UBI. Como o UBI descarta bad blocks, o mdtblock pode agora ser usado com segurana.
Uma segunda possibilidade usar o driver ubiblk, que implementa um dispositivo de bloco somente leitura
diretamente acima da UBI. A Free Electrons apresentou o ubiblk Linux Kernel Mailing List [11], mas ainda
no foi considerado (mainlined). Os benchmarks mostram que o ubiblk uma soluo eciente, por no
precisar emular um dispositivo intermedirio MTD.
Benchmarks
Com nanciamento da Linux Foundation, a Free Electrons testou o desempenho de vrios sistemas de
arquivos Flash em diferentes verses do kernel. Os resultados (gura 5) esto descritos online [12]. Em
resumo, o JFFS2 teve o pior desempenho e deve ser compilado com CONFIG_SUMMARY para um tempo de
inicializao aceitvel. No entanto, o JFFS2 ainda a melhor promessa para dispositivos com parties Flash
pequenas que necessitam de compresso e onde o UBI teria muita sobrecarga. Esta a razo pela qual o
JFFS2 ainda est em uso no OpenWRT, uma distribuio focada principalmente em dispositivos embarcados,
como gateways residenciais e roteadores, geralmente com 4MB a 16MB de armazenamento Flash.
Graas a melhorias nos ltimos anos, o YAFFS2 apresenta desempenho muito bom, seno o melhor, em
muitos cenrios de teste. No entanto, a falta de compresso continua sendo uma desvantagem, assim como
sua ausncia no kernel Linux. O YAFFS2 tambm mostra problemas de desempenho incomuns na gesto de
diretrios. O UBIFS agora a melhor soluo em termos de desempenho e espao. A necessidade de espao
adicional ser um problema somente em parties muito pequenas. A implementao tambm requer um
pouco mais de trabalho do que os outros candidatos.
No momento da publicao deste artigo, o LogFS ainda muito experimental para ser usado em sistemas de
produo, embora possamos esperar que seus bugs sejam corrigidos com o tempo. O SquashFS exibe boa
compresso e tempo de mount, assim como desempenho de leitura no Flash MTD em sistemas com parties
somente leitura. A necessidade de parear o SquashFS com o UBI, no entanto, compromete o desempenho do
tempo de mount. Em sistemas de arquivos de bloco, o SquashFS exibe o melhor tempo de mount, mas perde
muito tempo com a UBI, o que leva a uma quantidade substancial de tempo para inicializar (a operao
ubiattach).
A boa notcia que muito barato mudar sistemas de arquivos. Os aplicativos nem sequer notaro a
diferena. Como os benchmarks mostram, podemos obter resultados de desempenho notvel, dependendo do
tamanho e nmero das parties e arquivos, da leitura e escrita padres do sistema, e da necessidade de
compresso. Tudo o que o usurio precisa fazer tentar vrios sistemas de arquivos, executar seus
aplicativos e testes de sistema, e manter a soluo que maximiza o desempenho do seu sistema particular.
Sovinas
A memria Flash em seu estado natural (raw) oferece aos desenvolvedores de sistemas embarcados muitas
oportunidades de otimizao. A tendncia entre os fabricantes de hardware, no entanto, est longe da
memria exvel NAND incorporada ao MMC. Estas superfcies montadas de cartes de memria usam uma
interface mais parecida com a de uma placa externa. Elas escondem os detalhes dos blocos ruins e de
nivelamento de desgaste do sistema operacional. Por serem muito acessveis, provavelmente iro derrubar o
Flash mais caro.
10 of 17 29-04-2017 20:38
Figura 5Tempo de CPU necessrio para montar sistemas de arquivos. As longas barras vermelhas mostram
o demorado processo de mount no JFFS2.
Felizmente, o eMMC no totalmente opaco. Arnd Bergmann, desenvolvedor do kernel, escreveu uma
ferramenta chamada Flashbench [13] que permite determinar experimentalmente as caractersticas da mdia
de armazenamento, tais como o tamanho dos blocos de apagar. Com a ajuda destes resultados, podemos
tambm otimizar os parmetros do sistema de arquivos que estivermos utilizando. Bergmann descreve seu
trabalho em um artigo online [14].
Conselhos nais
Algumas simples regras de ouro so necessrias para trabalhar com memria Flash, incluindo no criar uma
partio swap em Flash. Sempre que possvel, devemos montar parties somente leitura. Dados volteis, tais
como arquivos de log, podem ser mantidos na memria RAM, usando o pseudo sistema de arquivos tmpfs.
Mais informaes
[1] Image tool for U-Boot environment: http://free-electrons.com/blog/mkenvimage-uboot-binary-env-generator/

[2] mtd-utils: http://git.infradead.org/mtd-utils.git
[3] BuildRoot: http://buildroot.uclibc.org/
[4] OpenEmbedded: http://www.openembedded.org/
[5] BusyBox: http://www.busybox.net/
[6] JFFS2: http://www.linux-mtd.infradead.org/faq/js2.html
[7] Log-structured lesystem: http://en.wikipedia.org/wiki/Log-structured_le_system/
[8] YAFFS2: http://www.yas.net/
[9] yas2utils: http://code.google.com/p/yas2utils/
[10] LogFS: https://github.com/prasad-joshi/logfs/
[11] biblk: Read-only block layer on top of UBI: https://lkml.org/lkml/2011/6/24/122/
[12] Flash lesystem benchmarks: http://elinux.org/Flash_Filesystem_Benchmarks/
[13] Flashbench benchmark tool: http://git.linaro.org/gitweb?p=people/arnd/ashbench.git;a=summary
[14] Optimizing Linux with Cheap Flash Drives by Arnd Bergmann, http://lwn.net/Articles/428584/
11 of 17 29-04-2017 20:38
Listagem 1: Parties denidas no kernel
01 static struct mtd_partition omap3beagle_nand_partitions[] = {

02 /* All the partition sizes are listed in terms of NAND block size */
03 {
04 .name = "X-Loader",
05 .oset = 0,
06 .size = 4 * NAND_BLOCK_SIZE,
07 .mask_ags = MTD_WRITEABLE, /* force readonly */
08 },
09 {
10 .name = "UBoot",
11 .oset = MTDPART_OFS_APPEND, /* Oset = 0x80000 */
13 .mask_ags = MTD_WRITEABLE, /* force readonly */
14 },
15 {
16 .name = "UBoot Env",
19 },
20 {
21 .name = "Kernel",
24 },
25 {
26 .name = "File System",
28 .size = MTDPART_SIZ_FULL,
29 },
30 };
Listagem 2: Mensagens de inicializao
01 omap2nand driver initializing

02 ONFI ash detected
03 NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB 1,8V 16bit)
04 Creating
5 MTD partitions on "omap2nand.0": 05 0x0000000000000x000000080000 : "XLoader"
06 0x0000000800000x000000260000 : "UBoot"
07 0x0000002600000x000000280000 : "UBoot Env"
08 0x0000002800000x000000680000 : "
09 0x0000006800000x000010000000 : "File System"
Listagem 3: /proc/mtd
01 dev: size erasesize name

02 mtd0: 00020000 00020000 "XLoader"
03 mtd1: 00040000 00020000 "UBoot"
04 mtd2: 00020000 00020000 "Environment"
05 mtd3: 00400000 00020000 "Kernel"
06 mtd4: 02000000 00020000 "File System"
07 mtd5: 0dbc0000 00020000 "Data"
12 of 17 29-04-2017 20:38
Listagem 4: ubi.ini
01 [RFSvolume]
02 mode=ubi
03 image=rootfs.ubifs
04 vol_id=1
05 vol_size=30MiB
06 vol_type=dynamic
07 vol_name=rootfs
08 vol_ags=autoresize
09 vol_alignment=1
Notcias
Novo evento "Universidade Livre" ser realizado em Belm/PA em 06/05/2017
Publicado em: 28/04/2017 s 11:19 | leituras |
Novo evento sobre Software Livre ser realizado no Instituto de Estudos Superiores da Amaznia (IESAM).
Soluti Certicao Digital em busca de especialista Linux
A Soluti Certicao Digital est em busca de um prossional para atuar como especialista Linux em
Goinia.
Vaga para analista de TI com experincia em ECM/GED, BPM e BI
Renomada empresa de servios de consultoria em TI, est em busca de um analista de TI para trabalhar em
projetos de implementao de solues ECM/GED, BPM e BI usando os sistemas Alfresco, Activiti, Bonita,
Camunda e SpagoBI.
Nova verso do Scalix Groupware oferece suporte completo a IBM Power & IBM Mainframes
A nova verso d liberdade de escolha s empresas para usar as tecnologias mais modernas oferecidas pelo
mercado como base para sua soluo de e-mail e colaborao
Software Livre e de Cdigo Aberto: uma questo de economia, no de poltica
Os argumentos apresentados neste artigo so todos aspectos econmicos, e no aspectos polticos. Decises
baseadas em poltica (e no em economia) devem ser lembradas pelos eleitores nas prximas eleies.
13 of 17 29-04-2017 20:38
Mais notcias
lanamento!
LM 119 | Backup e Restaurao
Impressa esgotada
R$ 10,90 Digital
Busca
+ lidas
+ procuradas
1. Baixe o curso de shell script do Julio Cezar Neves

Publicado em 07/04/2008 s 19:41 | 408452 leituras
1. Resultado do concurso "Por que eu mereo ganhar um netbook?"

1. Software pblico brasileiro na Linux Magazine Especial

1. Lanado o phpBB 3
1. TeamViewer disponvel para Linux

1. Pesquisa de escala global revela mudanas na rea de TI nas empresas

1. Ruby on Rails: vulnerabilidade SQL injection para todas as verses

1. Novo GIMP em uma janela

1. Sistemas SAP vulnerveis expostos na Internet

1. HTML5 ainda no est pronto para uso amplo na web, admite W3C
14 of 17 29-04-2017 20:38
whitepapers
Comparativo entre
SQL Server 2012 e
MySQL
Oracle Database
11g
Case: AntiSpam
denitivo no mundo
do Concreto
Oracle Exalogic
Elastic Cloud: Viso
geral do sistema
Backup e
recuperao de
bancos de dados
Oracle com o
recurso de Snapshot
Estudo de Caso -
Spam? Esse no
mais um problema
na Viavale Telecom!
Por que os cenrios

de uso de unidades
de solid state em
data centers esto
aumentando?
mais whitepapers
facebook
15 of 17 29-04-2017 20:38
twitter
Tweets about "@linux_magazine"

Sees
Entrevistas
Corporate
Anlise
Tutorial
SysAdmin
Programao
Linux User
Comunidade
Editorial
Colunas
Redes
Segurana
Insegurana
Especiais
Edies Especiais
Community Edition
Edies Anteriores
Livros
Shopping
Guia de TI
Revista C't
Siga-nos
Facebook
Twitter
RSS
Blogs
Blog da Redao
Blog do Maddog
Blog do Ricardo Olonca
Blog do Elias Praciano
Blog da Flvia Jobs
Contedo
Matrias Online
Contedo exclusivo para assinantes
A Revista
Edio do ms
Assine
Poltica de Privacidade
RSS
Expediente
Contato
Sites relacionados
Admin Magazine
Cloud Conf
/sys/dev
Loja virtual Linux Magazine
Sites parceiros
Dicas-l
Viva o Linux
BR-Linux
Esprito Livre
Under Linux
iMasters
Outros sites da Linux New Media
16 of 17 29-04-2017 20:38
ALEMANHA:
Linux Magazin
Linux User
Easy Linux
Linux-Community
OpenBytes
EUROPA:
EasyLinux Polnia
Linux Magazine Polnia
Darmowe Programy
Linux Magazine Espanha
INTERNACIONAL:
Linux Magazine International
Admin Redes & Segurana International
BRASIL:
Linux Magazine Brasil
Admin Redes & Segurana Brasil
CloudConf LatAm
Copyright 2014 | Linux New Media do Brasil
17 of 17 29-04-2017 20:38

Memoria Flash

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Memoria Flash

Enviado por

Direitos autorais:

Formatos disponíveis

Linux Magazine Online http://www.linuxmag.com.br/lm/article_online/e...

Aprenda a trabalhar com memria ash

Por Michael Opdenacker

Figura 2 A arquitetura MTD do kernel Linux permite o gerenciamento independente de hardware de

A listagem 1 mostra o excerto relevante do arquivo arch/arm/machOMAP2/board-OMAP3Beagle.c, que dene

O cdigo acima dene seis parties:

A partio "Environment onde as variveis de ambiente U-Boot bootloader so armazenadas. Estas

Manipulao de dispositivos MTD

Os comandos mais importantes so:

Figura 3 O armazenamento MTD normalmente dividido em parties gravveis e somente leitura.

mount t jffs2 /dev/mtdblock2 /mnt/flash

mkfs.jffs2 pad nocleanmarkers eraseblock=256 d rootfs/ o rootfs.jffs2

nandwrite p /dev/mtd2 rootfs.jffs2

O sistema de arquivos formatado automaticamente na primeira montagem:

mount t yaffs2 /dev/mtdblock2/mnt/flash

O JFFS2 e o YAFFS2 tm um problema em comum: eles implementam o nivelamento de desgaste,

ubimkvol /dev/ubi0 N test s 116MiB

ubimkvol /dev/ubi0 N test m

mount t ubifs ubi0:test /mnt/flash

ubinize o ubi.img p 128KiB m 4096 ubi.ini

Se quiser que o UBIFS controle a partio root, adicione

desgaste equilibrado entre os blocos fsicos.

[1] Image tool for U-Boot environment: http://free-electrons.com/blog/mkenvimage-uboot-binary-env-generator/

Listagem 1: Parties denidas no kernel

01 static struct mtd_partition omap3beagle_nand_partitions[] = {

Listagem 2: Mensagens de inicializao

01 omap2nand driver initializing

01 dev: size erasesize name

Novo evento "Universidade Livre" ser realizado em Belm/PA em 06/05/2017

Publicado em: 28/04/2017 s 11:19 | leituras |

Soluti Certicao Digital em busca de especialista Linux

Publicado em: 19/04/2017 s 17:18 | leituras |

Vaga para analista de TI com experincia em ECM/GED, BPM e BI

Publicado em: 16/12/2016 s 11:12 | leituras |

Publicado em: 14/12/2016 s 12:59 | leituras |

Software Livre e de Cdigo Aberto: uma questo de economia, no de poltica

Publicado em: 12/11/2016 s 12:36 | leituras |

LM 119 | Backup e Restaurao

1. Baixe o curso de shell script do Julio Cezar Neves

1. Resultado do concurso "Por que eu mereo ganhar um netbook?"

1. Software pblico brasileiro na Linux Magazine Especial

1. TeamViewer disponvel para Linux

1. Pesquisa de escala global revela mudanas na rea de TI nas empresas

1. Ruby on Rails: vulnerabilidade SQL injection para todas as verses

1. Novo GIMP em uma janela

1. Sistemas SAP vulnerveis expostos na Internet

Publicado em 08/10/2010 s 17:22 | 7734 leituras

Por que os cenrios

Tweets about "@linux_magazine"

Outros sites da Linux New Media

Copyright 2014 | Linux New Media do Brasil

Você também pode gostar