Tercera entrega de la serie sobre Sistemas de Archivos, donde ya me meto en faena. Lo ideal sería empezar con Windows, ya que es el más utilizado con diferencia, pero así ya puedo continuar con Linux Fácil donde lo dejé. Esta entrada va a ser un tanto técnica y quizás aburrida, pero estamos ante el "apasionante" mundo de los sistemas de archivos, si estás leyendo esto es de suponer que algo sí te interesa :P.

He reescrito este artículo lo menos un par de veces, porque al principio era demasiado ligero en cuanto a contenido y luego demasiado técnico. Así que al final, al no poder equilibrarlo, he decidido hacer una pequeña introducción de cada sistema de archivos y si alguien quiere saber algo más técnico, puede seguir leyendo, en caso contrario, salta al siguiente sistema de archivos. Espero que guste.

UNIX

De forma tradicional en Unix y muchos de sus derivados como BSD se utilizaba UFS (Unix File System), pero es muy similar a "EXT" en su forma de organizar el contenido del disco duro, así que voy a explicar este último que es el que se usa actualmente en Linux. La diferencia más importante que se aprecia a primera vista con respecto a los sistemas Windows, es que no existen unidades propiamente dichas como las que aparecen en "Mi PC", sino que todo parte de un único directorio raíz. Cuando se introduce un nuevo dispositivo de almacenamiento se monta en algún directorio definido a partir de la raíz y es por tanto, para el sistema, un hijo de éste. En Windows, en cambio, tenemos tantos "árboles" como unidades haya conectadas al ordenador.

Para que lo entendáis mejor, el directorio raíz vendría a ser C:\. Pero si tuvierias una unidad de CD o DVD, no habría un D:\, sino que se encontraría en alguna carpeta como /media/cdrom, la cual la elige la distribución aunque se puede modificar manualmente. Por tanto, en este ejemplo, todos los archivos del disco introducido se accedería a través de /media/cdrom. Es una diferencia no excesivamente importante en la práctica pero hay que reseñarla. Explicaré con más detalle las carpetas que hay generalmente en Linux en la próxima entrega de Linux Fácil. Ahora voy con sistemas de archivos concretos.

EXT2

Es el sistema de archivos adoptado de manera más común para Linux. Sustituyó al temprano EXT (Extended File System) que duró realmente poco durante el nacimiento de este sistema operativo debido a que presentaba ciertos fallos. Emplea una estructura de datos llamada inodos. Ésta consiste en que cada archivo se define como una lista de todas las posiciones en las que se encuentra dividido en el disco duro (se anotan los clústeres concretamente [agrupaciones de sectores, ya explicados en el primer artículo]). De este modo se consigue una importante mejora en el rendimiento, ya que se puede copiar un inodo entero a memoria RAM desde el disco duro para ir accediendo de manera más directa a sus distintas partes. Como veremos en próximos días, en sistemas más antiguos como FAT había que recorrer secuencialmente todas las partes del fichero para llegar a cada una de ellas, no pudiendo ir a un fragmento determinado de forma inmediata.

Además, en EXT2 se divide el disco duro en parcelas. En lugar de escribir un dato tras otro allá donde quepan, su destino está más o menos prefijado incluso antes de que se sepa que ese archivo se va a almacenar. Esto se debe a que se intenta que todos los ficheros y directorios que estén cerca (los directorios en realidad son archivos normales y corrientes, pero contienen enlaces a sus contenidos) en cuanto a la manera en que nosotros los hemos organizado, también estén cerca en el disco duro, es decir, en la misma parecela. Así se logra reducir el tiempo de acceso medio cuando navegamos por carpetas próximas.

Cuestiones técnicas

Los vectores de inodos tienen una longitud máxima, pero se puede hacer referencia a otros inodos cuando llegamos al final del que nos encontramos leyendo para continuar mirando el archivo, alcanzando hasta un tercer grado de indirección. Se pueden mantener, por tanto, tamaños de archivo grandes que pueden llegar hasta los 2 TB, mientras que el tamaño máximo de la partición es de 16 TB. La longitud de un inodo se puede ajustar según nos convenga al formatear la partición, pero suele dejarse que lo elija la distribución que instalamos, siendo normalmente de 128 bytes. En el inodo también se guarda información adicional (metadatos) como el usuario creador del archivo, la fecha, los permisos con los que se ha creado, etc.

En realidad en "EXT" no se habla de clústeres sino de bloques, una unidad de asignación similar, cuyo tamaño resulta independiente del tamaño de la partición y también es seleccionable por el usuario. Por lo general son de 1 KB ya que reduce la fragmentación interna, pero pueden alcanzar hasta 4KB. La semana pasada dije que la fragmentación interna era que se dejase espacio inutilizable dentro de un sector, bueno, pues también puede darse, lógicamente, dentro de un bloque o clúster. Una unidad EXT2 está dividida en grupos de bloques, cuántos hay en total en este caso sí depende del tamaño de la partición además del de los bloques. A ver si puedo explicar de forma sencilla a qué se debe esto. Es una mera curiosidad que realmente podéis saltar si queréis.

Dentro de cada grupo hay un bloque concreto en el que se guarda información sobre cada bloque de dicho grupo. Exactamente dice si están usados o no. Para ello, utiliza un único bit para decir sí o no, '1' ó '0'. Esa tablita únicamente puede ocupar un bloque, así que hay, siempre como máximo, tantos bloques como bits haya en ese bloque. Esto viene a ser 8 (número de bits en un byte) por el número de bytes del bloque, como puede ser 1 KB (1024 bytes). En este caso tendríamos 8 x 1024 = 8192 bloques por grupo. Si el tamaño de la partición es, por ejemplo, 10 GB, estamos hablando de 1024 x 1024 x 1024 bytes (2³⁰), 1 073 741 824 bytes. Ahora sólo hay que hacer una simple división, 1073741824 / 8192 = 131072 grupos.

Lo de los grupos es interesante, porque como he dicho se intenta que los archivos de un mismo directorio siempre caigan en un mismo grupo, lo que contribuye a acelerar el tiempo de acceso entre ficheros próximos. Además, reduce la fragmentación (externa en esta ocasión) ya que el espacio libre de cada grupo está preasignado. Puede suceder que un archivo se tenga que partir, pero es menos común que en NTFS, y si ocurre, lo más probable es que las distintas partes estén próximas entre sí dada esta organización, así que el impacto es menor.

Al principio del volumen se encuentra el increíble y todopoderoso superbloque, en el que se guardan datos como el tamaño que usamos de bloque y demás cuestiones sobre la configuración del sistema de archivos. Es tan sumamente importante, que hay una copia en cada uno de los grupos de bloques para sustituirla por la original en caso de detectar que contiene errores. Tras el superbloque vienen los descriptores de grupo, que son una lista de estructuras donde se almacenan datos variados sobre los grupos, como dónde se encuentran en el disco duro o dónde están sus componentes como el mapa de bits de los bloques o la tabla de inodos. También se copian en cada uno de los grupos.

Otras de las características de fiabilidad y seguridad que incluye EXT2 es la capacidad de detectar si un disco se desmonta incorrectamente. Además, almacena información sobre la última vez que se montó un volumen, se tuvo acceso a él o se comprobó su integridad y el número de veces que ha sido montado desde la última comprobación automática. Como en NTFS, incorpora permisos para los archivos, soporte para corrección y detección de errores y un tiempo de respuesta mucho menor respecto al sistema FAT. Sin embargo, requiere un mayor uso de memoria RAM debido a los inodos.

EXT3

Es un sistema muy similar a EXT2 pero con un añadido más que relevante, el journal (diario o bitácora). Sirve para almacenar en un registro las distintas modificaciones que se realizan en el sistema de archivos, antes de que se produzcan, para reparar los cambios en caso de que no se lleven a cabo correctamente o suceda una interrupción (un corte de luz, un bloqueo del sistema, etc.) y no se termine la operación completamente. En la próxima entrega explicaré en más detalle en qué consiste el "journaling".

Gracias a esta característica se consiguió una mayor robustez y fiabilidad en el sistema. Además, presenta la ventaja de que es muy sencilla la migración desde EXT2 al ser dos formatos tan parecidos. Y por otra parte, un volumen EXT3 puede ser montado como EXT2 si se ha desmontado correctamente, ya que en caso contrario el sistema de archivos encontraría información en la bitácora que no podría manejar. Esta funcionalidad da la posibilidad de hacer EXT3 retrocompatible con aplicaciones que no lo soporten como algunas utilidades de recuperación de Linux.

Otros cambios incluidos fueron la posibilidad del aumento del tamaño de la partición estando montada y una nueva manera más eficiente de almacenar la información sobre directorios que ocupan varios bloques.

EXT4

Es seguramente el futuro para Linux, al menos a nivel de usuario. Su principal novedad es algo ya presente en la gran mayoría de sistemas de archivos para entornos Unix, los llamados "extents". Se trata de una forma de reservar espacio para un fichero a continuación de donde ha sido escrito si se necesita porque se prevee que vaya a crecer de tamaño. De este modo, lo puede hacer de forma consecutiva, reduciendo o casi haciendo desaparecer la tan indeseable fragmentación. Otros sistemas de archivo necesitan escribir ceros en las áreas reservadas, lo que reduce el rendimiento.

También aumenta el tamaño máximo de las particiones hasta 1024 petabytes, el tamaño de archivo hasta los 16 terabytes y elimina el límite de número de directorios de 32768. Con la llegada de los 64 bits con los AMD 64 y los Core 2 Duo a la plataforma x86 (los PCs de toda la vida), es posible almacenar números para la dirección de los bloques más grandes, lo que permite organizar un disco duro de mucho mayor tamaño y EXT4 se aprovecha de ello.

Cuestiones técnicas

Los extents no sólo sirven para eso que he indicado, sino que suponen una sustitución del uso de inodos indirectos de hasta tercer grado que usaban ext2/3, ya que resultaban tremendamente ineficientes para archivos grandes. Un extent puede indexar hasta 128 MB con un tamaño de clúster de 4 KB, es un descriptor ideal para zonas de disco duro continuas, ya que simplemente guarda el inicio de la misma y cuánto ocupa. Se pueden guardar hasta tres extents dentro de un i-nodo, y si se necesitan más, se utilizan árboles B (ya iréis viendo lo que son más adelante, es una estructura de lo más recurrente ya que la emplean todos los sistemas de archivos modernos) para organizarlos. Para estas y otras características el tamaño de los inodos ha de ser como mínimo de 256 bytes.

El rendimiento mejorará con la implementación de la escritura retardada, que por decirlo de algún modo espera hasta el último momento posible para escribir una información en disco, reduciendo los accesos necesarios. Aparte, se han añadido una serie de sumas redundantes ("checksums") sobre el contenido del sistema de archivos (inodos, extents, journal...) que sirven para verificar que son correctos y no se han corrompido.

En cuanto a la compatibilidad con anteriores versiones, una partición EXT3 puede ser montada perfectamente como EXT4 y una EXT4 como EXT3, salvo que se haya activado el uso de "extents", que actualmente ya viene por defecto, así que ya no será posible utilizar herramientas diseñadas para EXT2. Sin embargo, se están creando una serie de utilidades específicas para EXT4 como un desfragmentador en línea (esto es, un desfragmentador que no requiere desmontar la partición). De momento no es interesante instalarlo ya que sigue evolucionando y está más indicado para particiones que superen el terabyte de tamaño, aunque al ritmo que vamos no falta tanto. Pero será un cambio mucho más radical en todos los sentidos respecto a lo que supuso EXT3 para EXT2.

REISERFS

Antes que EXT3, hizo aparición de la mano de Hans Reiser este sistema de archivos que, aunque en principio fue creado de propósito general, fue acogido por alguna de las distribuciones de Linux actuales, como Linspire, Knoppix o Suse (que posteriormente pasó a utilizar EXT3). Destacó en su momento por adelantarse al resto de sistemas de archivos con algunas de sus características, como journaling, lo que facilitó su rápida difusión. No obstante, presenta una desventaja importante frente a EXT3, y es que la migración desde EXT2 no es tan sencilla y requiere un formateo completo del volumen donde lo queremos implementar. Desde EXT3 no existe ese problema .

ReiserFS no utiliza bloques de longitud fija, sino que los ajusta según el tamaño del archivo que se va a almacenar, lo que le proporciona una velocidad mucho mayor a la hora de manejar directorios que contienen ficheros pequeños y disminuye el desperdicio de espacio que supone no rellenar un bloque completamente. Admite archivos mayores de 2 GB y tiene un rendimiento mejor a la hora de acceder a los directorios al emplear una estructura de datos llamada “árbol balanceado”, que trata toda la partición como si fuese una única tabla que contiene directorios, archivos y metadatos (datos sobre los datos, como puede ser la fecha de creación).

Cuestiones técnicas

Es algo complejo de explicar así que no voy a profundizar en esto. La principal diferencia es que no existe una tabla al principio de la partición tras la que vienen los datos, como se hace en el resto de los casos, sino que toda la partición en sí es un gran árbol algo especial por su construcción, que se hace de forma ordenada, y se pueden transformar sobre la marcha reduciendo o aumentando las ramas según convenga (la semana que viene os enseñaré de forma muy leve cómo se crea un árbol B, que también los usa NTFS). En él se van anotando en los nodos intermedios los directorios y otra información adicional y en las hojas se ponen el contenido de los ficheros. De esta manera los metadatos y el contenido de los ficheros están situados de manera muy próxima y el tiempo de acceso de unos a otros se reduce.

Es especialmente interesante para determinados servidores que lidien con archivos pequeños, como pueden ser correos electrónicos o caches de páginas, en un ordenador particular no se aprecia tanta mejora. Es capaz incluso de disminuir la fragmentación interna incluyendo más de un fichero dentro de un mismo bloque (no dentro de un mismo sector, eso sí, son cosas distintas, recordad ;)). Hace un uso intensivo de la memoria RAM para preparar cualquier escritura en disco, que es una de las principales ventajas por las que gana en velocidad, limitando los accesos necesarios, aunque también exige tener bastante memoria RAM si no queremos que, al contrario, vaya más lento.

Se puede aumentar el tamaño de la partición estando montada con gran facilidad, e incluso reducirlo si la desmontamos (significa que, aunque esté conectado, no se puede acceder a los datos, como cuando le das a extraer en Windows a un USB pero no lo quitas del ordenador). Esto es gracias a algunas utilidades adicionales que se ofrecen, no hay que recurrir a programas endemoniados que hacen mil virguerías como Partition Magic.

Uno de los inconvenientes que presenta ReiferFS es que no trabaja correctamente con sistemas de archivos de red o NFS, ya que pese a que existen algunos parches que palian algunos de los problemas, no los solucionan del todo. Además, con ficheros grandes no se aprecia un aumento del rendimiento en comparación con otros sistemas de archivos. Pero el mayor problema es que su complejo algoritmo provoca que si una partición con ReiserFS muere, lo hace definitivamente, se queda completamente corrupta ya que es muy difícil recuperarla. Un corte de luz puede ser mortal incluso con journal y yo mismo lo he vivido, de hecho. Menos mal que por aquel entonces apenas empezaba a probar Linux, no como ahora. De todos modos, es poco probable que ocurra algo así.

Fin cuestiones técnicas

Actualmente la empresa de Reiser, Namesys, está trabajando en Reiser 4, la próxima versión de este sistema de archivos, que promete ser mucho más eficiente (las pruebas actuales parecen confirmarlo, ganando en rendimiento a la competencia) gracias en gran parte al uso del ¿árbol bailarín? (dancing tree), más moderno que el tradicional árbol B que se utiliza en Reiser 3. Incluso es capaz de hacer compresión de archivos automática aumentando la capacidad de los discos duros en consecuencia. Sin embargo, de momento no ha sido acogido en el kernel de Linux y no se sabe si se finalizará su desarrollo.

La causa de que no puediera terminarse es que Hans Reiser, crudamente lo suelto, ha sido condenado por el asesinato de su esposa, hace apenas unas semanas además, el 28 de abril. Se enfrenta a 25 años de prisión y eso significa que, obviamente, no puede dirigir su compañía dentro de la cárcel, pese a que desde ella han asegurado que piensan seguir trabajando en Reiser 4. Hans Reiser declaró a finales de 2006, cuando comenzó el proceso judicial, que vendería Namesys para pagar a sus abogados, pero a día de hoy sigue en su poder.

XFS

Es más antiguo que ReiserFS, nacido en 1993, y fue el primer sistema de archivos para sistemas Unix en incorporar una bitácora. Sin embargo, no fue liberado bajo licencia GPL hasta el año 2000. Posteriormente sí se incluyó soporte dentro del kernel de GNU/Linux. Fue desarrollado en sus inicios por SGI, la antigua Silicon Graphics, quien lo sigue apoyando. Utiliza 64 bits para guardar las posiciones de los archivos. Como ya he comentado anteriormente, 64 bits significa números más grandes, lo cual es ideal para particiones enormes como las que podemos encontrar en un servidor, llegando hasta los 8 exabytes. En máquinas de 32 bits el tope de la partición es de 16 terabytes.

Cuestiones técnicas

Los volúmenes XFS pueden ser formateados con un tamaño de bloque que varía de 512 Bytes a 64 KB, dependiendo del tamaño de los archivos que vayamos a guardar. Lleva los grupos de bloques de EXT hasta el extremo, ya que cada grupo puede incluso gestionar sus inodos y su espacio libre (que tiene anotado en dos árboles B+, uno ordenado por el tamaño de los espacios y otro por la posición de los mismos en el disco) de forma completamente independiente, casi dividiendo la partición en varios pequeños sistemas de archivos dentro de uno grande.

Se hace así para permitir escalabilidad, algo muy atractivo para entornos de servidores donde múltiples ordenadores comparten la información. De este modo, sería posible por ejemplo que dos ordenadores o incluso dos procesadores dentro de un mismo servidor accedieran a la vez al disco duro, en grupos de bloques distintos, sin que hubiera que impedir el paso a uno de los dos para evitar que se "pisen". Aparte, también soporta "extents"

JFS

Éste únicamente menciono su existencia dado que su difusión es muy baja y aún está en desarrollo para Linux. Es otro sistema de archivos con journaling como su propio nombre indica (Journaled File System), el cual gestiona muy eficientemente. Fue creado por IBM en un principio para AIX (un sistema Unix propiedad de la compañía) pero finalmente está siendo llevado a GNU/Linux. Al igual que XFS, con el que comparte otras muchas características, al ser de 64 bits soporta ficheros y particiones grandes, que como he mencionado es útil para servidores, mercado de especial interés para IBM.

Cuestiones técnicas

Muy breve, no me voy a extender. Es más dinámico a la hora de asignar el tamaño de un inodo mediante el uso de extensiones (extents) que almacena en árboles B+ (un tipo especial de árbol B). También sigue la política de grupos de bloques de EXT (y UFS en realidad).


MAC-OS

En los ordenadores personales de Apple, más conocidos como Macintosh, se emplea un sistema de archivos propios llamado HFS que, fuera de sus computadoras, sólo se ha empleado en discos compactos creados ex profeso para ellos. Con anterioridad, durante los primeros años, usaron MFS, un sistema bastante sencillo pero útil para ese momento.

MFS

Éste sistema de archivos es historia pura y relativamente antigua. Apple sacó al mercado el Macintosh File System en 1984 junto al Macintosh 128k para formatear disquetes de 400k, ya que recordemos que por aquel entonces el sistema operativo usualmente se arrancaba desde disquetes y no existían los discos duros. Tuvo el mérito de introducir los "forks", que vienen a ser maneras de almacenar en un mismo fichero distintos tipos de datos como imágenes y el código binario de un ejecutable. Así, todos los datos de un programa podía guardarse en un único archivo. Sin embargo, dado que sólo está disponible en MacOS, por razones de compatibilidad con otros sistemas operativos esta característica apenas se usa hoy en día, pese a que sigue estando soportada por los sistemas de archivos actuales.

Más relevante es el hecho de que podía almacenar "metadatos" o informaciones adicionales sobre un fichero que eran útiles para Finder, el explorador de archivos de MacOS, que por aquella época ya tenía una atractiva interfaz gráfica en blanco y negro (aunque no fueron los primeros en conseguirla). MFS no soportaba carpetas y éstas eran creadas de manera virtual por Finder realizando una anotación especial en los metadatos para incluir el nombre del directorio. Sin embargo, en los diálogos de apertura o guardado de archivos de los programas no se mostraban los directorios, así que se veía una laaaaaaaaarga lista de archivos (bueno, depende de lo que tuviéramos guardado) y no se podían tener ficheros con el mismo nombre pese a que en teoría estuvieran en distintas carpetas. Para crear un nuevo directorio, había que llenar una carpeta que siempre estaba vacía en la raíz, y entonces aparecía una nueva carpeta vacía y la anterior pasaba a ser un directorio normal y corriente. No era posible crear una carpeta dentro de otra carpeta.

Cuestiones técnicas

Soportaba nombres de hasta 255 caracteres, pese a que Finder los limitaba a 63 y en posteriores versiones a 31. El disco se dividía en bloques lógicos de 512 bytes que a su vez se agrupaban en bloques reservables (bueno, no sé como traducirlo exactamente, en inglés eran "allocating blocks"). Utilizaba una lista ordenada donde se anotaban múltiples entradas de 12 bits de tamaño que indicaban si un bloque estaba reservado para un archivo o no. Si esos 12 bits eran 0, significaba que el bloque estaba libre. En cambio, si ponía otro número distinto también de 1, indicaba dónde estaba la siguiente parte del fichero. Finalmente, si ponía un 1, quería decir que era el último trozo. Simple pero efectivo para ese tamaño de disquetes (había un total de 4094 bloques).

Tras esa lista, venía otra en la que se indicaban el nombre de cada archivo y su posición en el disco duro. Cuántos archivos cabían ahí dependía de la longitud de los nombres, así que es normal que fueran limitados por Finder, ya que el espacio que se utilizaba para esa lista era fijo. En los disquetes de 400k, por ejemplo, se usaban 12 bloques lógicos para esta información.

Había un total de 4096 bloques, 4x2¹⁰, pero el primero y el segundo no se podían escribir ya que eran utilizados en el arranque del sistema operativo, algo que se mantuvo en HFS, el sistema de archivos que sustituyó a MFS en 1985. A partir de Mac OS 7.6.1 se eliminó la compatibilidad con volúmenes formateados en MFS. Actualmente, para acceder a ellos, se pueden hacer mediante un complemento externo llamado MFSLives desarrollado por la propia Apple, pero sólo en modo lectura.

HFS

HFS es un sistema de archivos mucho más avanzado que MFS, aunque lo toma como base. Llegó para resolver los problemas de rendimiento de MFS, que no estaba pensado para los rápidos discos duros, sino para los disquetes. Mantenía los forks, como ya he comentado. HFS sustituyó la vetusta tabla de MFS que era como un fichero único por una estructura mucho más avanzada, el archivo de catálogo (Catalog File) que emplea otra variante de los mencionadísimos árboles balanceados, en este caso los B* (o "be estrella"), con los que se logra una búsqueda mucho más rápida.

Cuestiones técnicas

Se ampliaron una serie de parámetros a la par que se hizo en los ordenadores (el paso de los 16 a los 32 bits), pero no se incrementó el número máximo de archivos, 65000 (redondeando). Los bloques 0 y 1 siguen siendo los de arranque. En el 2 se almacena cierta información sobre el volumen como la fecha de creación o la situación de otras estructuras del sistema de archivos como el mapa de bits de la partición. Ya en el bloque 3 empieza el mapa de bits, que de modo similar a como sucede en EXT2, indica qué bloques están libres y cuáles ocupados.

A continuación tenemos el archivo de catálogo, que guarda información sobre los ficheros y los directorios. Contiene cuatro tipos de registros diferentes. Para definir un fichero utiliza uno llamado "File Thread Record", donde sólo aparece el ID del directorio donde se encuentra y el nombre del archivo, y un "File Record", donde ya mete los metadatos (incluyendo los que utilice Finder) y las direcciones de los bloques que lo componen. De manera análoga, un directorio requiere otros dos registros, "Directory Thread Record" y "Directory Record", sólo que en este caso lógicamente no hay que apuntar a dónde se encuentran las partes del archivo porque no existen. Aunque antes no lo he comentado, tanto en MFS como en HFS los ficheros tienen un número identificador único por el que son reconocidos.

Si el "File Record" se queda sin espacio, se utiliza otra estructura aparte del archivo de catálogo, el "Extent Overflow File" (otra vez los dichosos extents, sí). Se trata de otro árbol B* en el que se meten listas de bloques asignados a un fichero que no caben en el archivo de catálogo. Además, si hay algún bloque del disco duro que no funciona correctamente, para evitar que sea asignado también se introduce aquí. Muy bien pensado, la verdad.

Una vez más, al igual que con MFS, se quedó pequeño. Los 65535 (ahora no me da la gana redondear) archivos que como máximo podía almacenar obligaban a que estos tuvieran un tamaño exageradamente grande en discos duros de una capacidad relevante. Para un disco duro de 1 GB tienes que tener archivos de 16 KB por ejemplo (1024 MB por GB x 1024 KB por MB / 65535 archivos), se desaprovecha muchísimo espacio. Para ser exactos, eran 65000 (pues en este caso sí redondeo, ¿por qué he dicho para ser exactos? ) grupos de bloques, pero cada grupo sólo pertenecía a un archivo, así que un archivo como mínimo ocupaba un grupo entero pese a que fuera mucho más pequeño. Un claro caso de fragmentación interna. Cada bloque tenía un tamaño de 512 bytes.

Además, presentaba un fallo grave de fiabilidad, y es que si el archivo de catálogo resultaba dañado la partición se echaba a perder. No es como en otros sistemas de archivos como EXT, en los que se guardan las direcciones de los archivos en varias estructuras en el disco duro y no en un único fichero.

HFS Plus

La evolución de HFS y que es utilizado actualmente por MacOS X, aunque fue introducido para MacOS 8.1. También se emplea en los iPods formateados en un Mac, no así en los que se conectan con PCs con Windows para poder mantener la compatibilidad. Curiosamente, según tengo entendido, cuando compras un iPod y lo enchufas a un ordenador por primera vez, éste se formatea de un modo u otro dependiendo de si está en MacOS o Windows, aunque yo no lo he comprobado, como anti-Apple que soy.

Las secciones que comprende una partición HFS+ son muy similares a las de HFS. Los primeros dos bloques vienen a ser los mismos, esto se mantuvo así para permitir que Macintosh más antiguos, sin soporte para HFS+, arrancaran de todos modos para mostrar un mensaje en el que se invitaba al usuario a actualizar el equipo. En realidad, tenía más miga por lo visto, sólo le aparecía un fichero que ponía "where are my files?" ("¿dónde están mis archivos?") o algo similar en el que ya se explicaba la necesidad de la migración. Yo me lo perdí así que tampoco lo sé al 100%. Una versión más reciente de HFS+, denominada HFSX, elimina esta cuestión porque hoy en día ya no es necesaria.

HFS+ ha sufrido varios cambios a lo largo de su historia. El principal es que soporta "journaling" desde MacOS 10.2.22 y los volúmenes que hacen uso de él presentan la leyenda "HFSJ". Está activo por defecto desde MacOS 10.3, la misma versión en la que se introdujo HFSX.

Cuestiones técnicas

En HFS+ las direcciones de los bloques alcanzan los 32 bits, en lugar de los 16 anteriores, así que se supera el límite de los 65 535 grupos de bloques, pasando a nada menos que 4 294 967 296. El tamaño de bloque de 512 bytes se mantiene. Utiliza Unicode para el nombre de los archivos, como en NTFS, mientras que en EXT lo puede decidir el usuario. Siguen existiendo los forks, pero continúan sin apenas uso.

El segundo sector también muestra datos sobre el volumen, empezando por la situación de las otras estructuras del sistema de archivos, al igual que en HFS. El archivo de catálogo viene a ser igual, pero ahora los registros son algo más grandes, para permitir entre otras cosas los nombres de fichero en UTF, pasando de 512 Bytes a 4 KB en MacOS y 8 KB en MacOS X. Además, el tamaño de los distintos campos almacenados puede variar dinámicamente según lo que se guarde en ellos, en HFS eran fijos. El Extents Overflow File funciona igualico, pasando a 1 KB de tamaño de cada registro en MacOS y 4 KB en MacOS X. Los dos últimos sectores, como en HFS, almacenan por un lado información sobre el tamaño de las distintas estructuras del sistema de archivos y por otro datos que Apple graba durante la fabricación del aparato.

La novedad está en un archivo de atributos que, como su propio nombre indica, almacena diversos atributos en tres clases de registros diferentes, "Inline Data Attribute", donde directamente aparecen los datos, "Fork Data Attribute", que contiene enlaces a otros registros con atributos (hasta un máximo de 8), y "Extension Attribute", que son los registros enlazados por los "Fork Data Attribute" donde también aparecen los atributos directamente. Sirven para añadir información adicional sobre permisos de acceso de los distintos ficheros y directorios.



Bueno, imagino que esta vez os habréis aburrido muchísimo, aunque he tratado de informar sin ser demasiado técnico, pero en este caso quería ser algo más riguroso. Supongo que cuando hable de FAT y NTFS os llamará algo más la atención por ser lo que utilizáis cada día la mayoría.