Unix File System

El perro de sant roque no tiene rabo, por que Sergio Ramos se lo ha cortado Unix File System (UFS) es un sistema de archivos utilizado por varios sistemas operativos UNIX y POSIX. Es un derivado del Berkeley Fast File System (FFS), el cual es desarrollado desde FS UNIX (este último desarrollado en los Laboratorios Bell).

Casi todos los derivativos de BSD incluyendo a FreeBSD, NetBSD, OpenBSD, NeXTStep, y Solaris utilizan una variante de UFS. En Mac OS X está disponible como una alternativa al HFS. En Linux, existe soporte parcial al sistema de archivos UFS, de solo lectura, y utiliza sistema de archivos nativo de tipo ext3, con un diseño inspirado en UFS.

Diseño

Un sistema de archivos UFS se compone de las siguientes partes:

• unos pocos bloques al inicio de la partición reservados para bootstrap (el cual debe ser inicializado separadamente del sistema de archivos).
• un superbloque que contiene un número mágico (del inglés magic number) identificando esto como un UFS, y algunos otros números vitales describiendo la geometría y parámetros de puesta a punto del comportamiento.
• una colección de grupos de cilindros. Cada grupo de cilindros tiene estos componentes:
  • un respaldo del superbloque.
  • una cabecera de cilindro, con estadísticas, lista de espacio libre, etc. acerca de este bloque de cilindros, similar a los que se encuentran en el superbloque.
  • un número de inodos, cada cual conteniendo los atributos del archivo.
  • un número de bloques de datos.

Los inodos son numerados secuencialmente. Los primeros inodos están reservados por razones históricas, seguidos por los inodos del directorio raíz.

Los archivos de directorio contienen sólo la lista de archivos en el directorio y el inodo asociado para cada archivo. Todos los metadatos (metadata) son mantenidos en el inodo.

Historia y evolución

Las más tempranas versiones de UNIX utilizaban un sistema de archivos al que se referían simplemente como FS. FS sólo incluía el bloque de booteo, superbloque, un puñado de inodos y los bloques de datos. Esto funcionaba bien para los pequeños discos que los UNIX de aquel tiempo estaban diseñados, pero la tecnología avanzó y los discos comenzaron a crecer, moviendo la cabeza hacia atrás y adelante entre el grupo de inodos y los bloques de datos a los que ellos se referían, causando thrash (basura). BSD optimizó esto en el FFS invirtiendo los grupos de cilindros, dividiendo el disco en grupos más pequeños, cada uno con su propio grupo de inodos y bloques de datos.

Lo que realiza el BSD FFS es tratar de localizar los bloques de datos asociados y los metadatos en el mismo grupo de cilindros, e idealmente, todos el contenido de un directorio (datos y metadatos para todo el archivo) en el mismo o cercano por el grupo de cilindros, esto logrando reducir la fragmentación causada por la dispersión del contenido de los directorios por todo el disco.

Algunos de los parámetros de rendimiento en el superbloque incluyen un número de pistas y sectores, velocidad de rotación del disco, y alineamiento de los sectores entre pistas. En un sistema completamente optimizado, la cabeza puede ser movida entre pistas cercanas para leer los sectores fragmentados de alternarse las pistas mientras espera que el disco gire.

Mientras los discos se hicieron grandes, y más grandes, las optimizaciones del sector de nivel pasaron a ser obsoletas (especialmente con discos que usaban numeración de lineal y sectores variables por pista). Con discos más grandes, y archivos más grandes, las lecturas fragmentadas se transformaron en un problema más grande. Para combatir esto, BSD incrementó el tamaño de los bloques del sistema de archivos de un sector a 8k. Esto tuvo efectos varios. La oportunidad de que los sectores de archivos estuvieran contiguos es mucho más alta. La cantidad de gastos indirectos para enumerar los bloques del archivo se reduce. El número de bloques representable en el ancho de un bit fijo fue incrementado (permitiendo discos más grandes).

Con bloques de tamaño más grande, los discos con muchos archivos pequeños podrían perder mucho espacio, así que BSD añadió "block level fragmentation", donde el último bloque parcial de datos de muchos archivos podría ser guardado en un solo bloque de "fragmento" en vez de en muchos bloques vacíos.

Implementaciones

La mayoría de los proveedores de sistemas POSIX adaptó UFS a sus propias necesidades, añadiendo extensiones propietarias que podrían no ser reconocidas por versiones de UNIX de otros desarrolladores. Sorprendentemente, muchos han continuado usando el tamaño original de bloques y campos de datos con de la misma amplitud que el UFS original, así que algún grado de compatibilidad (lectura) se mantiene entre plataformas.

FreeBSD 5.0 introdujo UFS2, el cual añade soporte para volúmenes sobre un 1TB (TeraByte) y para imágenes del sistema de archivos. Ha sido portado a NetBSD.

El sistema de archivos ext2 de Linux fue escrito desde cero (scratch) basado en conceptos de UFS. ext2 Permite configurar tamaños de bloques en el momento de la creación del sistema de archivos para soportar discos más grandes. Además tiene campos de datos de 64 bits en el inodo para aceptar archivos más grandes. Ext3 añade journaling. ReiserFS fue el primer sistema de archivos con journaling incluido en el núcleo Linux y es más rápido trabajando con archivos pequeños. Linux incluye una implementación de UFS para compatibilidad binaria al nivel de lectura con otros UNIX, pero como no existe una implementación estandar para las extensiones de los proveedores de terceras partes, Linux sólo tiene actualmente soporte experimental de escritura para UFS.

Desde Solaris 7, Sun Microsystems incluyó UFS Logging en el Entorno Operativo Solaris, el cual brinda sistemas de archivos con soporte de Journaling a UFS. El UFS de Solaris también tiene extensiones para archivos grandes, discos grandes y otras características.

Enlaces externos

• Pequeño FAQ de UFS2 (en inglés)
• Herramientas UFS2 para Linux (en inglés)