Sistemas de ficheros para dispositivos embebidos

1,186 views

Published on

Presentación sobre la tecnología de las memorias Flash (NOR/NAND) y los sistemas de ficheros diseñados para dispositivos embebidos

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,186
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Sistemas de ficheros para dispositivos embebidos

  1. 1. Sistemas de ficheros para dispositivos embebidos Raúl Fraile
  2. 2. Contenidos • Memoria Flash • Características, historia y uso. • Limitaciones • Tipos: NOR, NAND • Wear leveling • Sistemas de ficheros • Conceptos básicos • cramfs, squashfs, romfs, JFFS2 y YAFFS2 • Demo
  3. 3. Memoria Flash
  4. 4. Memoria flash Características •Sistema de almacenamiento no volátil. •Evolución de EEPROM (electrically erasable programmable read-only memory). •EEPROM: Debe ser completamente borrada para poder escribir de nuevo. •Flash: Se reescribe en bloques/páginas/bytes. •Hay dos tipos principales: NOR y NAND
  5. 5. Memoria flash Historia •Inventada por el Dr. Fujio Masuoka mientras trabajaba en Toshiba en 1980. •En 1988, Intel lanzó el primer chip de memoria Flash (NOR).
  6. 6. Memoria flash Uso
  7. 7. Memoria flash Limitaciones •La principal limitación de las memorias flash es el número limitado de ciclos program-erase (P/E). •Un sistema de ficheros que no tenga en cuenta esta limitación puede agotar el número de ciclos rápidamente.
  8. 8. Memoria flash Tipos NOR NAND
  9. 9. Memoria flash Tipo NOR • Se llama NOR porque su funcionamiento se asemeja al de una puerta lógica NOR. • Lecturas rápidas (<80 ns), borrados/escrituras lentas (1 s/ sector, 9 μs/Word). • Permite acceso aleatorio (random access, mapeado en memoria). • Entre 10.000 y 100.000 ciclos de P/E. • Permite eXecute In Place (XIP). • Alto coste por MB.
  10. 10. Memoria flash Tipo NAND Se llama NAND porque su •asemeja al de una puerta funcionamiento se lógica NAND. Lecturas, •ms/sector,borrados y escrituras rápidas (20 μs, 1 400 μs/page). Permite acceso secuencial. •necesidad de implementar Interfaz más compleja y un sistema de detección y corrección de errores (EDC/ECC). •Entre 100.000 y 1.000.000 ciclos de P/E. •Bajo coste por MB.
  11. 11. Memoria flash Sistemas de ficheros •Debido a las limitaciones en el número de ciclos de P/E de las memorias Flash, es necesario utilizar un controlador que realice wear leveling o un sistema de ficheros diseñado específicamente para este tipo de memoria. •Los sistemas de archivos convencionales reescriben sus estructuras de datos y metadatos repetidamente en la misma área, haciendo que las celdas contenidas en ese área alcancen el límite de ciclos P/E.
  12. 12. Memoria flash Wear leveling (I) •Sin wear leveling, cada vez que se reescribe un bloque previamente escrito, éste debe ser: leído, borrado, modificado y reescrito en la misma posición. •Problema principal: algunos bloques muy usados mientras que otros prácticamente sin usar.
  13. 13. Memoria flash Wear leveling (II) La técnica de wear leveling pretende distribuir •ciclos de P/E proporcionalmente, para alargar los la vida de la memoria. Utiliza un Addresses) •relacionar mapa (Logical Blocken el SO conpara los bloques lógicos los físicos de la flash. Cada vez que se reescribe un bloque, se hace en una nueva dirección, y se marca en el mapa el anterior bloque como invalid data. El static leveling, además, va rotando •bloques wearno cambian frecuentemente. los que
  14. 14. Memoria flash Wear leveling (III) Static Dynamic Tiempo de vida Mayor Menor Rendimiento Más lento Más rápido Complejidad Alta Baja Uso típico SSD Memorias USB
  15. 15. Sistemas de ficheros
  16. 16. Filesystems Linux. Conceptos básicos •El kernel y el RFS (Root File System) son independientes, aunque el kernel necesita de un RFS al iniciarse. •initrd/initramfs se utilizan para crear un sistema de ficheros temporal en memoria antes de que el sistema real pueda ser montado. •Está diseñado para poder utilizar cualquier sistema de ficheros que pueda comunicarse con el virtual file system (VFS).
  17. 17. Filesystems Virtual File System •VFS es una capa de abstracción que proporciona un interfaz común. Permite que distintos sistemas de ficheros interaccionen con el sistema de almacenamiento de la misma manera. •Filesystem in Userspace (FUSE) permite crear sistemas de ficheros que se ejecutan en modo usuario. Por ejemplo, utilizando la API de Amazon S3 es posible crear un filesystem para acceder “localmente” de forma transparente.
  18. 18. Filesystems Dispositivos embebidos •Los sistemas de ficheros para dispositivos embebidos deben cumplir algunas características: •Eficiencia (mínimo consumo de energía). •Optimización del espacio ocupado. •Si se trata de memoria flash, y hay operaciones de lectura y escritura, deben proveer un sistema de wear leveling.
  19. 19. Filesystems cramfs (I) •cramfs (compressed ROM file system) es un sistema de ficheros de solo lectura, normalmente usado en sistemas embebidos o con recursos muy limitados. •Los archivos se comprimen usando zlib. •Los metadatos no se comprimen, pero se almacena menos información y de forma más eficiente. •Ha sido usado para imágenes de initrd e instalaciones.
  20. 20. Filesystems cramfs (II) •Limitaciones: •Sistema de ficheros hasta 256 MB. •Archivos de hasta 16 MB. •Máximo 2 archivos. •Todos los archivos pertenecen a root. No se •epoch,almacenan timestamps (por defecto 1970 GMT). 16
  21. 21. Filesystems SquashFS (I) •Sistema de ficheros de solo lectura, con algunas mejoras respecto a cramfs. •La versión original utilizaba gzip para la compresión de archivos, directorios e inodes. En la versión 2.6.34 del kernel se añadió soporte para LZMA y LZO, mientras que 2.6.38 lo hizo para LZMA2 (usado por xz). •Soporte para Extended file attributes desde la versión 2.6.35 del kernel.
  22. 22. Filesystems SquashFS (II) •Consigue una mayor compresión con tamaños de bloque ajustables (máximo 1 MB, 128 KB por defecto) y reduciendo el tamaño de los metadatos (8 bytes de media). •Usado en live CDs en las principales distribuciones, así como recientemente en el dispositivo Chromecast (media player de Google).
  23. 23. Filesystems SquashFS (III) •Limitaciones: •Sistema de ficheros hasta 2 GB. •Archivos de hasta 2 TB. •Máximo 2 archivos. •Todos los archivos pertenecen a root 32 32
  24. 24. Filesystems romfs •Sistema de ficheros de solo lectura extremadamente simple. Utilizado principalmente para initrd o instalaciones. •El principal objetivo de romfs es tener un kernel muy pequeño, con el sistema de ficheros enlazado y poder cargar cualquier módulo a continuación. Filesystem temporal. •No utiliza ninguna técnica de compresión de datos.
  25. 25. Filesystems JFFS2 (I) •JFFS2 (Journalling Flash File System version 2). Sistema de ficheros de lectura y escritura diseñado específicamente para almacenamiento flash. •Es un sistema de ficheros log-structured. Los datos y metadatos se escriben en un buffer circular (log). •No reduce la cantidad de metadatos que almacena. Cumple con POSIX metadata. Usuario, grupo, timestamps... son almacenados.
  26. 26. Filesystems JFFS2 (II) •JFFS2 añadió soporte para memorias NAND, no disponible en JFFS. •Utiliza compresión de datos. Los algoritmos disponibles son zlib, rubin, rtime y lzo. •Dispone de un garbage collector que marca bloques dirty, como free. También se usa para wear leveling, marcando ocasionalmente como free bloques clean.
  27. 27. Filesystems JFFS2 (III) •Limitaciones: •Sistema de ficheros hasta 2 GB. •Máximo 2 archivos. •Montaje lento, ya que tiene que leer todos los 32 32 nodos antes de montarse.
  28. 28. Filesystems YAFFS2 (I) •YAFFS2 (Yet Another Flash File System) funciona de forma similar a JFFS2, aunque está diseñado específicamente para memorias NAND. •A diferencia de JFFS2, no utiliza compresión de datos. •Compatible con POSIX metadata. •Utilizado en Android hasta la versión 2.2.
  29. 29. Filesystems YAFFS2 (II) •Limitaciones: •Sistema de ficheros hasta 2 GB. •Máximo 2 archivos. •Aunque ha sido utilizado en memorias NOR, no 32 32 funciona del todo bien.
  30. 30. Demo
  31. 31. • Dos directorios: • test:1.txt, 1.html (113 bytes) • test2: 1.txt, 1.html, jquery.js y logo.png (324 kb) • Crear y montar un filesystem con cramfs • mkcramfs -n testfs test cramfs.test • hexdump -C cramfs.test • mkcramfs -n testfs2 test2 cramfs.test2 • Comparar con ls -h el tamaño de ambos filesystems • sudo mount cramfs.test2 /mnt/cramfs -t cramfs -o loop • Utilizar el filesystem (ls, cat...). Escritura no permite (touch) nombre carpeta archivo de salida loopback dev (acceso por bloques)
  32. 32. • Crear y montar un filesystem con SquashFS • mksquashfs ./test squashfs.test -noappend -comp lzo -info • hexdump -C squashfs.test • Crear test2 con los 3 tipos de compresión y comparar: • mksquashfs ./test2 squashfs.test2.lzo -noappend -comp lzo info carpeta archivo de salida no añadir a existente comp. (lzo, gzip, xz) archivos y % comp. • mksquashfs ./test2 squashfs.test2.gzip -noappend -comp gzip -info • mksquashfs ./test2 squashfs.test2.xz -noappend -comp xz info • sudo mount squashfs.test2.xz /mnt/squashfs -t squashfs -o loop • Utilizar el filesystem (ls, cat...). Escritura no permite (touch) • Comparar scramfs y SquashFS
  33. 33. • Crear y montar un filesystem con romfs • genromfs -f romfs.test -d ./test que • Comprobar de 1el tamaño es 1 kb, esto es debidoaa1quesidebe ser múltiple kb, por lo que hace un padding kb es menor. • hexdump -C romfs.test (no hay compresión de datos) • sudo mount romfs.test /mnt/romfs -t romfs -o loop • Utilizar el filesystem (ls, cat...). Escritura no permite (touch) • Crear filesystem de test2 y comparar tamaño con cramfs y SquashFS: • genromfs -f romfs.test2 -d ./test2
  34. 34. ¿Preguntas?
  35. 35. Raúl Fraile @raulfraile

×