1
Sistema de archivos orientado a multimedia
Andrés Páez-Martı́nez
A01213800
Arturo Gómez-Chávez
A01109703
Edgar Alejandro Cabrera-Rivas
A01123471
Responsable: Mario Farias-Elinos
División de Ingenierı́a y Arquitectura, ITESM CCM
Abstract—El sistema de archivos orientado a multime-
dia (Media File System o MFS)es un sistema de alma-
cenamiento implementado para GNU/Linux, optimizado
para archivos grandes (contenido audiovisual) para poder
organizarlos y accederlos de manera rápida y sencilla.
Abstract—The Multimedia Oriented File System (Media
File System or MFS) is a storage system implemented for
GNU/Linux, optimized for big files (audiovisual content) so
they can be organized and accessed in a quick and simple
way.
Index Terms—File System, multimedia, GNU/Linux.
I. I NTRODUCCI ÓN
E L almacenamiento masivo de información es
una parte fundamental de la computación. Para
ello existen sistemas de archivos. El cómo se mane-
jen estos sistemas dependerá del tipo de información
que se quiera almacenar y la manera en la que se
accederá a ellos; con el fin de obtener un resultado
óptimo en un área, por ejemplo, rendimiento, pode-
mos hacer la información más sensible a pérdidas,
o bien, podemos hacerlo menos sensible a fallas,
aunque con menor rendimiento.
Para el caso de este proyecto se optó por pensar
en un sistema de archivos que cubrirá una de las ten-
dencias más notables en cuanto a almacenamiento:
multimedia. Las librerı́as personales de música se
hacen cada vez mayores, ası́ como la cantidad de
imágenes y vı́deos que inundan nuestros discos
duros. Este tipo de información, por comodidad
del usuario final, es importante accederla de man-
era rápida y organizada, pero siempre teniendo en
cuenta que el tamaño de estos archivos es grande
y debido a su elevado número de archivos, la
organización debe de se flexible.
Es por lo anterior que se buscó plantear los
objetivos claros que querı́an alcanzarse con este
sistema, los cuales se listan a continuación:
• Número alto de bytes por sector
• Soporte para un gran número de archivos y
directorios
• Facilidad de organización para el usuario
• Protección de datos
• Interfaz para un sistema operativo popular
(GNU/Linux)
A partir de estos lineamientos se comenzó la
tarea de realizar un sistema de archivos que por
el momento no soporta una interfaz nativa con
el sistema operativo, pero que permite algunas de
las operaciones básicas más utilizadas dentro de
un shell de comandos: copiar, crear directorio, ver
listado, ası́ como moverse entre directorios.
Se eligió C como lenguaje de desarrollo y
GNU/Linux como plataforma para poder realizar
operaciones de nivel medio sobre el volumen for-
mateado como MFS.
La manera en que se implementaron estas solu-
ciones se muestran a continuación.
II. E STRUCTURA GENERAL
El sistema de archivos incluye cuatro secciones
principales en las cuáles está distribuida la estruc-
tura para poder realizar las operaciones necesarias.
A. Encabezado
El encabezado está ampliamente inspirado en el
encabezado del sistema de archivos FAT[2], con un

tamaño de 512 bytes a partir del inicio del volumen.
Consta, en este orden, de los siguientes elementos.
• DIR SALTO - 3 bytes para el salto al sector
de arranque para una arquitectura Intel x86.
• OEM ID - 8 bytes para el nombre y versión
del sistema de archivos.
• NUM DIR - 1 byte para el número de copias
de la zona de directorios.
• TAM DIR - 2 bytes indicando el número de
sectores que ocupa la zona de directorios.
• BYTS SECTOR 1 Byte para indicar un expo-
nente de 2, para saber el número de bytes por
cada sector.
• BYTS MINI SECTOR - 1 byte para in-
dicar,con un exponente de 2, el número de
bytes por sector de la zona de directorios.
• TOT SECTOR - 4 bytes para el número de
sectores para el volumen.
• MEDIA - 1 byte. Descriptor de dispositivos
con el mismo formato que FAT.
• HID SECTOR - 4 bytes. Conteo de sectores
ocultos.
• VOL ID - 4 bytes para el número de serie del
volumen.
• VOL ET - 11 bytes para la etiqueta del volu-
men.
• Espacio reservado - 24 bytes para posible
crecimiento futuro.
• BOOT CODE - 448 bytes para el código
bootstrap de arranque.
B. Zona de directorios
La zona de directorios utiliza 3 sectores a partir
del boot sector. Debido a que requieren menos
espacio, cada directorio ocupa lo que se definió
como mini sector. Los directorios contienen
un conjunto de ligas tanto a subdirectorios, que
se trabajan como ligas de cuatro bytes, como a
archivos, que son ligas de ocho bytes. El motivo de
la diferencia de tamaños es que se requiere menos
espacio para direccionar directorios. Cada directorio
de esta zona cuenta con el siguiente formato, en el
mismo órden en el que se presentan:
• NOMBRE - 19 bytes para contener 16 car-
acteres con el nombre del archivo, además de
3 caracteres para la extensión. La codificación
utilizada es ASCII.
• SEC USD - 2 bytes. Número de mini sectores
ocupados por el directorio. Al menos ocupa
2
uno, o bien, cero para indicar que el espacio
se encuentra disponible.
• BLOQUE SIG - 4 bytes. Este atributo es el
que permite expandir la cantidad de archivos
contenidos por el directorio, ya que se puede
tener un sólo directorio fragmentado a lo largo
de varios mini sectores. Este atributo es un
apuntador al siguiente mini sector. Si no hay
fragmentación, se le asigna un valor de cero.
• ATRIBUTOS - 1 sólo byte, donde cada bit rep-
resenta una bandera de validación para distintas
propiedades del directorio, como se muestran a
continuación:
– SOLO LECTURA: 0x01
– OCULTO: 0x02
– SISTEMA: 0x04
– NOMBRE LARGO: 0x08
Además, es posible notar que quedan bits libres
para que alguna otra implementación sobre el
MFS pueda tener un mayor grado de organi-
zación para las operaciones sobre directorios.
• TIEMPO CR - 2 bytes. Tiempo de creación
del directorio (se explicará más adelante el
formato implementado).
• FECHA CR - 2 bytes. Fecha en la cuál fue
creado el directorio.
• TIEMPO ULT ACC - 2 bytes. Tiempo del
último acceso al directorio.
• FECHA ULT ACC - 2 bytes. Fecha de último
acceso al directorio.
• LIGA PADRE - 4 bytes. Cada uno de los
directorios sólo puede ser apuntado por un
directorio padre. La dirección de este padre se
encuentra aquı́.
• NUM AR - 2 bytes. Número total de archivos
en el directorio.
• NIM DIR - 2 bytes. Número de subdirectorios
contenidos en el directorio.
• TAM BYTS - 4 bytes. Tamaño del directorio
(expresado en bytes).
Lo anterior es el encabezado del directorio.
Nótese que existe el atributo NOMBRE LARGO.
Se tendrı́a que reservar espacio para los caracteres
sobrantes, sin embargo, dado que no siempre es
necesario, se puede agregar o no los siguientes
dos campos, inmediatamente a continuación del
encabezado, dependiendo si el atributo está activo:

• TAM NOM L - 2 bytes que indican el tamaño
del nombre largo. El hecho de reservar tanto
espacio ayuda a poder tener nombres lo sufi-
cientemente especı́ficos como para poder orga-
nizar de manera fácil y personalizada nuestra
biblioteca multimedia.
• NOM L - El tamaño de este campo está es-
pecificado por el atributo anterior, y contiene
el resto del nombre del directorio.
Una vez terminado el encabezado y el espacio
del nombre largo (si se utilizó) se encuentran las
ligas a subdirectorios y archivos (en el encabezado
del directorio ya está establecido el número de
ligas). Como ya se mencionó, la cantidad de ligas y
subdirectorios que un directorio puede direccionar
es expandible por medio de otros mini sectores. Para
evitar tener información redundante, cada contin-
uación es un mini sector que contiene los siguientes
cuatro campos:
• SEC USD - 2 bytes. Mini sectores utilizados.
• TAM BYTS - 4 bytes para contener el tamaño
total en bytes.
• BLOQUE SIG - 4 bytes. Apuntador en sec-
tores a la continuación siguiente. Si es 0, quiere
decir que no hay más continuaciones.
• BLOQUE ANT - 4 bytes. Apuntador en sec-
tores a la continuación anterior.
Nótese que si un directorio está fragmentado,
es posible moverse sobre él como una lista doble-
mente ligada, con el fin de realizar operaciones más
rápidas, sobre todo si se están ejecutando constantes
operaciones de acceso aleatorio.
C. Zona de archivos
La zona de archivos es la siguiente sección del
volumen. Hay dos puntos destacables a cerca de
los archivos del MFS; primero, son fácilmente ex-
tendibles, al igual que los directorios, y segundo,
pueden ser apuntados por más de un directorio. Es
posible profundizar más en la estructura si se obser-
van los atributos del encabezado de cada archivo:
• NOMBRE - 19 bytes para el nombre corto,
lo que implica 19 caracteres en codificación
ASCII, utilizando 16 para el nombre y 3 para
la extensión.
• SEC USD - 2 bytes para indicar el número
de sectores ocupados por el archivo. Al menos
debe ocupar uno.
3
• BLOQUE SIG 8 bytes para apuntar al sigu-
iente sector. Si es 0, significa que no hay
fragmentación.
• ATRIBUTOS - 1 byte, siguiendo el mismo
esquema y especificaciones que los atributos
de los directorios.
• TIEMPO CR - 2 bytes. Tiempo en el que fue
creado el archivo.
• FECHA CR - 2 bytes. Fecha en la cual fue
creado el archivo.
• TIEMPO ULT ACC - 2 bytes. Tiempo de
último acceso al archivo.
• FECHA ULT ACC - 2 bytes. Fecha de último
acceso al archivo.
• TIEMPO ULT ESC - 2 bytes. Tiempo en
el que se realizó la última escritura sobre el
archivo. Notemos que una escritura implica
modificación de contenido, mientras que un
acceso puede implicar también una lectura. Por
fines de seguridad y mantener integridad de
información existe esta diferenciación.
• FECHA ULT ESC - 2 bytes. Fecha en la que
se realizó la última escritura.
• LIGAS PADRES - 2 bytes. Número de ligas
padres. Como se mencionó, un archivo puede
estar apuntado por más de un directorio debido
a que esto permite mayor facilidad de organi-
zación. El motivo de la existencia de las ligas
a los padres es que al remover o modificar
un archivo, no es necesario buscar en todo el
volumen las referencias al archivo, sino que se
pueden eliminar las referencias directamente de
los padres.
• TAM BYTS - 8 bytes indicando el tamaño en
bytes del directorio.
• LIGAS - 256 bytes designados para las ligas
a los padres, lo cual implica un máximo de 64
padres por archivo. Una liga con un valor de
-1 significa un espacio disponible.
Al igual que en la zona de directorios, los
archivos pueden tener un nombre largo, ası́ que
dependiendo del atributo correspondiente, se puede
o no reservar una zona para los caracteres extra de la
misma manera en la que se hace en la zona anterior.
Las continuaciones de los archivos fragmentados
se realizan de la misma manera que los directorios,
con la diferencia en que cada uno de los atributos
de los encabezados ocupa el doble de espacio.

D. Lista de espacios vacı́os
Esta parte del MFS es más abstracta en cuanto
a su ubicación, pues se trata de una serie de apun-
tadores entre los sectores vacı́os. La estructura de
datos utilizada es una lista doblemente ligada. El
motivo de la existencia de esta lista es poder conocer
todo el tiempo los espacios asignables para colocar
archivos, dependiendo de su tamaño, y no tener que
hacer un recorrido entero del sistema de archivos
para verificar esta información. La única condición
que se debe de respetar para el formato de listas
ligadas en una implementación de MFS es que no
se puede modificar la cabeza de la lista. El formato
de los espacios vacı́os es el siguiente:
• SEC USD - 4 bytes para sectores utilizados.
• BLOQUE SIG - 8 bytes que funciona como
apuntador para el siguiente sector de espacios
vacı́os. Si el valor está en 0,indica el final de
la lista.
• BLOQUE ANT - 8 btes para el blque anterior
de espacios vacı́os. Solo la cabeza de la lista
debe tener un valor de 0 en este campo.
E. Otros formatos
1) Formato de ligas: Si se están leyendo las ligas
en 4 bytes, un -1 indica un cambio a 8 bytes y
viceversa.
2) Formato de fechas:
• Bits 0-4: Valor con el dı́a del mes, entre 1 y
31.
• Bits 5-8: Mes del año, número entre 1 y 12.
• Bits 9-15: Años a partir del 2000.
3) Formato de tiempos:
• Bits 0-4: Mitad de la cantidad de segundos.
• Bits 5-10: Valor de minutos entre 0 y 59.
• Bits 11-15: valor entre 0 y 23 indicando las
horas.
III. V ENTAJAS DEL MFS
Si se quiere analizar los pros y contras del MFS,
inevitablemente habrá que recalcar el objetivo del
sistema, y cuáles fueron las decisiones que implica-
ban ganancia o pérdida en distintas áreas.
Primero se debe analizar la decisión respecto al
tamaño de los sectores. En general, los archivos
multimedia son archivos grandes. Incluso en un
formato de compresión musical de mediana calidad
4
como lo es el MP3, una canción ocupará un prome-
dio de 3MB. Una pelı́cula en calidad media ocupará
en promedio un 1GB. Es por esto que se eligió
utilizar un número de bytes por sector considerable.
Esto puede traer problemas si se agregan archivos
pequeños, puesto que se comienza a desperdiciar
mucho espacio. Por otro lado, debido a que gen-
eralmente las bibliotecas multimedia son accesadas
constantemente, se reduce la fragmentación y au-
menta la velocidad de acceso, pues se tiene que
hacer una menor cantidad de saltos, ya que la
información se mantiene más contigua. Otra ventaja
de esto es que para archivos muy grandes, se reduce
también el overhead producido por la suma de
cabeceras generada por la fragmentación del archivo
en distintos bloques.
Otro punto importante a tener en cuenta es el he-
cho de que un mismo archivo puede estar apuntado
por diferentes directorios. Esto se pensó teniendo
en cuenta que las bibliotecas multimedia pueden
llegar a ser difı́ciles de organizar, debido a la gran
cantidad de formas para clasificar los archivos. Un
ejemplo de ello son las bibliotecas de música. Si se
organizan por autor, y después se desea reproducir
un determinado género, habrı́a que cargar en RAM
la información del género dentro de los archivos y
crear una serie de listas virtuales. Por otro lado, si se
otra carpeta que organice nuestra música por género,
simplemente habrı́a que navegar por los directorios.
Esto lleva a organizaciones muy personalizadas y
tan complejas como el usuario desee.
IV. I MPLEMENTACI ÓN
Por el momento, no existe soporte para ningún
sistema operativo para integrar MFS con el explo-
rador de manera directa. No obstante, dado que el
MFS está optimizado para volúmenes dedicados a
guardar un tipo especı́fico de información, se am-
pliará, primero, sobre las consideraciones que hay
que tener en cuenta para crear una implementación
del MFS, y segundo, sobre la implementación real-
izada durante este proyecto.
A. Consideraciones para implementar MFS
Primero, se debe de tener en cuenta que el MFS
está pensado para guardar archivos multimedia. Es
capaz de soportar un código bootstrap de arranque
si se quiere montar un sistema operativo sobre el
MFS, pero se debe tener en consideración que en un

sistema operativo donde muy probablemente existan
una gran cantidad de archivos de configuración
pequeños, o donde se guardarán documentos de
texto, entonces se comenzará a tener una pérdida
de espacio.
Una mejor opción es dedicar este sistema de
archivos a dispositivos especializados en guardar
contenido multimedia, como reproductores de MP3,
o tarjetas multimedia, en dónde se aproveche el
espacio y se obtenga lo mejor del MFS.
Es importante revisar la estructura general del
MFS si se quiere realizar una implementación, evi-
tando por ejemplo, borrar el primer apuntador de la
lista de espacios vacı́os, no modificando las fechas,
teniendo a consideración el uso de nombres largos,
etc.
B. Implementación realizada
Para probar el MFS se utilizaron memorias Flash
USB de al menos 1GB para verificar que era
factible realizar operaciones básicas de un sistema
de archivos con la información provista por las
estructuras implementadas. El primer punto a con-
siderar es que se eligió C como lenguaje por su
rapidez y capacidad de integración con el sistema
operativo, y GNU/Linux debido a que es muy
fácil realizar operaciones de bajo nivel sobre los
volúmenes, puesto que se pueden tratar como si
fueran archivos mientras se tengan privilegios de
administrador.
Se creó una aplicación sin GUI que funciona
como un bash dentro de la consola estándar, in-
dicándonos el directorio actual dentro del MFS
sobre el cual se está operando. El principal detalle
es que su ejecución requiere privilegios de admin-
istrador, puesto que se trabaja directamente sobre
el directorio /dev. Se utilizaron sólo las librerı́as
estándar de C. Previo a la implementación, se debe
de utilizar el programa “format”, el cual recibe
como argumento la ubicación dentro de /dev del
archivo que representa al volumen. Una vez hecho
esto, se puede correr la aplicación principal, la cual
puede realiza los comandos listados a continuación:
• ls/dir : Comandos para listar directorios y
archivos contenidos dentro del directorio ac-
tual.
• quit : Permite salir de la aplicación principal.
• mkdir : Crea un directorio, dándole el nombre,
dentro del directorio actual.
5
• readroot : Por motivos de prueba,despliega la
información contenida en el encabezado del
MFS.
• imp : Se le dan dos números enteros que
representan rangos de memoria, e imprime el
contenido de esos rangos. Principalmente se
utiliza para fines de prueba.
• cd : Para cambiar el directorio actual al direc-
torio especificado.
• printdir : Para fines de prueba, imprime un
directorio en un determinado byte.
• del : Borra el elemento que se le de como
argumento.
• cat : Lee el contenido de un archivo que se le
pase como parámetro.
• copy : Se pedirá especificar entre distintos
tipos de copiado, ya que puede ser dentro del
mismo sistema de archivos, o bien, puede ser
un copiado desde o hacia Linux.
V. P OSIBLES MEJORAS O IMPLEMENTACIONES
Por supuesto, MFS tiene mucho espacio para
mejorar, y este tipo de consideraciones son las que
ponen en perspectiva del potencial de este proyecto.
Primero, dado que se trata de un producto des-
tinado a usuarios finales, la facilidad de uso es
un factor importante, por lo que tener en cuenta
que puede haber una gran cantidad de usuarios
de diferentes regiones y que puede haber proble-
mas de decodificación con los nombres. Se puede
tomar como ejemplo lo realizado por el sistema de
archivos HFS+ de apple, el cual utiliza por default
decodificación UNICODE[1], pero deja espacio a
especificar dentro del volumen el tipo decodifi-
cación que se está usando.
Otro aspecto importante que por el momento no
se encuentra implementado, es el que un directorio
también pueda ser apuntado por más de un direc-
torio. Por supuesto, se requiere tener cuidado en
cuanto no crear problemas con las ligas cuando la
organización se vuelva muy compleja, pero también
traerı́a ventajas al usuario para poder crear organi-
zaciones más personalizadas.
Quizás una de las implementaciones más atracti-
vas, serı́a poder soportarlo de manera nativa desde
algún sistema operativo, para no tener que hacerlo
exclusivo de volúmenes externos y poder mover
archivos de una manera más intuitiva. Se podrı́a
tener una partición dedicada y optimizada para
 6

multimedia, y poder accederla desde cualquier apli-

cación para reproducireste tipo de contenidos sin
requerir librerı́as extra. Es por ello que uno de los
trabajos futuros más importantes para este proyecto
serı́a crear un módulo para el Kernel de GNU/Linux
para poder leer los volúmenes MFS de manera
nativa, como si se tratase de una partición ext2 o
ext3[3].

VI. C ONCLUSIONES
El MFS es un sistema de archivos que si bien aún
se encuentra en una etapa de desarrollo muy tem-
prana, posee los elementos para poder convertirse
en una solución viable al almacenamiento masivo
de contenidos audiovisuales, puesto que aumenta
velocidades de acceso y permite un buen grado
de organización para bibliotecas multimedia muy
grandes. Aunado a esto, el MFS podrı́a fácilmente
implementarse en dispositivos portátiles o sistemas
dedicados a la reproducción de contenidos de audio
y video.
Es importante reconocer que también tiene
muchas limitantes, sobre todo si se compara con
sistemas de archivos de uso general, como lo son el
ext2/3, el NTFS o el HFS+, que son ampliamente
utilizados en computadoras de escritorio, puesto que
el MFS no está pensando para almacenar todo tipo
de información.
Es por los motivos anteriores que se llegó a la
conclusión de que el MFS es capaz de convertirse
en un modelo de almacenamiento multimedia que
le puede traer comodidad a los usuarios que posean
gran cantidad de este tipo de información, y a los
desarrolladores que busquen crear sistemas dedica-
dos a la reproducción de contenidos digitales.

R EFERENCES
[1] Apple, Inc. Technical Note TN1150: HFS Plus Volume Format,
http://developer.apple.com/library/mac/#technotes/tn/tn1150.html,
March 05, 2004.
[2] Microsoft, Corp. FAT: General Overview of On-Disk Format,
Hardware White Paper, May 05, 1999.
[3] Anne Shepherd. The Second Extended File System (ext2fs),
Linux Kernel Internals, Fall 2001.