Sistema de archivos Unix

El sistema de archivos Unix ( UFS ) es una familia de sistemas de archivos compatibles con muchos sistemas operativos Unix y similares . Es un descendiente lejano del sistema de archivos original utilizado por la versión 7 de Unix .

Un volumen UFS se compone de las siguientes partes:

• Algunos bloques al principio de la partición están reservados para los bloques de arranque (que deben inicializarse por separado del sistema de archivos).
• Un superbloque que contiene un número mágico que lo identifica como un sistema de archivos UFS, y otros números vitales que describen la geometría, las estadísticas y los parámetros de ajuste de comportamiento de este sistema de archivos.
• Un conjunto de grupos de cilindros. Cada grupo de cilindros tiene los siguientes componentes:
  • Una copia de seguridad del superbloque
  • Un encabezado de grupo de cilindros, con estadísticas, listas libres, etc., sobre este grupo de cilindros, similar a los del superbloque.
  • Una serie de inodos , cada uno con atributos de archivo.
  • Una serie de bloques de datos

Los inodos se numeran secuencialmente, comenzando en 0. El inodo 0 está reservado para entradas de directorio no asignadas, el inodo 1 era el inodo del archivo de bloque defectuoso en versiones históricas de UNIX, seguido del inodo para el directorio raíz , que siempre es el inodo 2, y el inodo para el directorio lost+found, que es el inodo 3.

Los archivos de directorio contienen únicamente la lista de nombres de archivo del directorio y el inodo asociado a cada archivo. Todos los metadatos de los archivos se almacenan en el inodo.

Los primeros sistemas de archivos Unix se denominaban simplemente FS . FS solo incluía el bloque de arranque, el superbloque, un grupo de inodos y los bloques de datos. Esto funcionaba bien para los discos pequeños para los que se diseñaron los primeros Unix, pero a medida que la tecnología avanzaba y los discos se hacían más grandes, el movimiento del cabezal entre el grupo de inodos y los bloques de datos a los que se referían provocaba un rendimiento deficiente . Marshall Kirk McKusick , entonces estudiante de posgrado en Berkeley , optimizó la disposición del FS V7 para crear el FFS (Fast File System) de BSD 4.2 mediante la invención de grupos de cilindros, que dividen el disco en fragmentos más pequeños, cada uno con sus propios inodos y bloques de datos. ^{[ 2 ] [ 3 ]}

El objetivo de BSD FFS es intentar localizar los bloques de datos y metadatos asociados en el mismo grupo de cilindros e, idealmente, todo el contenido de un directorio (tanto datos como metadatos de todos los archivos) en el mismo grupo de cilindros o en uno cercano, reduciendo así la fragmentación causada por la dispersión del contenido de un directorio en todo el disco.

Algunos de los parámetros de rendimiento del superbloque incluían el número de pistas y sectores, la velocidad de rotación del disco, la velocidad del cabezal y la alineación de los sectores entre pistas. En un sistema totalmente optimizado, el cabezal podía moverse entre pistas cercanas para leer sectores dispersos de pistas alternas mientras se esperaba a que el plato girara.

A medida que los discos se hicieron más grandes, la optimización a nivel de sector se volvió obsoleta (especialmente con discos que usaban numeración lineal de sectores y sectores variables por pista). Con discos y archivos más grandes, las lecturas fragmentadas se convirtieron en un problema mayor. Para combatir esto, BSD originalmente aumentó el tamaño del bloque del sistema de archivos de un sector a 1  KB en 4.0 BSD; y, en FFS, aumentó el tamaño del bloque del sistema de archivos de 1  KB a 8  KB. Esto tiene varios efectos. La probabilidad de que los sectores de un archivo sean contiguos es mucho mayor. La cantidad de sobrecarga para listar los bloques del archivo se reduce, mientras que la cantidad de bytes que puede representar cualquier número dado de bloques aumenta.

También es posible utilizar discos de mayor tamaño, ya que el número máximo de bloques está limitado por un número de bloque de ancho de bits fijo. Sin embargo, con bloques de mayor tamaño, los discos con muchos archivos pequeños desperdiciarán espacio, puesto que cada archivo debe ocupar al menos un bloque. Por este motivo, BSD añadió la fragmentación a nivel de bloque , también llamada subasignación de bloques, fusión de cola o empaquetamiento de cola , donde el último bloque parcial de datos de varios archivos puede almacenarse en un único bloque de "fragmento" en lugar de en múltiples bloques mayormente vacíos. ^{[ 4 ]}

El trabajo realizado en Berkeley FFS fue ampliamente adoptado por otros proveedores de Unix, y la familia de sistemas de archivos derivados de él se conoce colectivamente como UFS.

Los proveedores de algunos sistemas Unix propietarios, como SunOS / Solaris , System V Release 4 , HP-UX y Tru64 UNIX , y sistemas abiertos derivados de Unix como illumos , han adoptado UFS.

A partir de Solaris 7 , Sun Microsystems incluyó UFS Logging, que introdujo el registro de transacciones del sistema de archivos en UFS, que todavía está disponible en las versiones actuales de Solaris e illumos. ^{[ 5 ]} Solaris UFS también tiene extensiones para archivos y discos grandes y otras características.

En 4.4BSD y los sistemas BSD Unix derivados de él, como FreeBSD , NetBSD , OpenBSD y DragonFly BSD , la implementación de UFS1 y UFS2 se divide en dos capas: una capa superior que proporciona la estructura de directorios y admite metadatos (permisos, propiedad, etc.) en la estructura de inodos, y capas inferiores que proporcionan contenedores de datos implementados como inodos. Esto se hizo para admitir tanto el sistema de archivos tradicional FFS como el sistema de archivos estructurado por registros LFS con código compartido para funciones comunes. La capa superior se llama "UFS", y las capas inferiores se llaman "FFS" y "LFS". En algunos de esos sistemas, el término "FFS" se usa para la combinación de la capa inferior FFS y la capa superior UFS, y el término "LFS" se usa para la combinación de la capa inferior LFS y la capa superior UFS.

McKusick implementó la reasignación de bloques, una técnica que reordena los bloques del sistema de archivos justo antes de que se realicen las escrituras para reducir la fragmentación y controlar el envejecimiento del sistema. También implementó las actualizaciones suaves , un mecanismo que mantiene la consistencia del sistema de archivos sin limitar el rendimiento como lo hacía el modo de sincronización tradicional. Esto tiene como efecto secundario la reducción de la necesidad de comprobar el sistema de archivos tras un fallo o un corte de energía. Para solucionar los problemas que persisten tras un fallo, se introdujo una utilidad fsck en segundo plano.

En UFS2, McKusick y Poul-Henning Kamp extendieron las capas FFS y UFS de FreeBSD para agregar punteros de bloque de 64 bits (lo que permite que los volúmenes crezcan hasta 8 zebibytes ), bloques de tamaño variable (similares a las extensiones ), campos de indicadores extendidos, marcas de tiempo de nacimiento adicionales, soporte de atributos extendido y ACL POSIX1.e. UFS2 se convirtió en la versión UFS compatible a partir de FreeBSD 5.0. FreeBSD también introdujo actualizaciones suaves y la capacidad de crear instantáneas del sistema de archivos tanto para UFS1 como para UFS2. Estas características se han portado posteriormente a NetBSD, pero finalmente las actualizaciones suaves (llamadas dependencias suaves en NetBSD) se eliminaron de NetBSD 6.0 en favor del mecanismo de registro del sistema de archivos menos complejo llamado WAPBL (también conocido como registro), que se agregó a FFS en NetBSD 5.0. OpenBSD admitió actualizaciones suaves desde la versión 2.9 ^{[ 6 ]} hasta que se eliminó el soporte en la versión 7.4, ^{[ 7 ]} y ha tenido soporte para UFS2 (FFS2) (sin ACL) desde la versión 4.2. ^{[ 8 ]} OpenBSD hizo de UFS2 la versión UFS predeterminada con la versión 6.7. ^{[ 9 ]} Desde FreeBSD 7.0, UFS también admite el registro de transacciones del sistema de archivos mediante el proveedor GEOM gjournal . FreeBSD 9.0 agrega soporte para registro de transacciones ligero sobre las actualizaciones suaves (SU+J), lo que reduce en gran medida la necesidad de fsck en segundo plano y ACL de NFSv4.

FreeBSD, NetBSD, OpenBSD y DragonFly BSD también incluyen el sistema Dirhash , desarrollado por Ian Dowse. Este sistema mantiene una tabla hash en memoria para acelerar las búsquedas en directorios. Dirhash soluciona varios problemas de rendimiento asociados con directorios grandes en UFS.

NeXTStep , derivado de BSD, también utilizaba una versión de UFS. En Mac OS X de Apple , estaba disponible como alternativa a HFS+ , su sistema de archivos propietario. Sin embargo, a partir de Mac OS X Leopard , ya no era posible instalar Mac OS X en un volumen con formato UFS. Además, no se pueden actualizar versiones anteriores de Mac OS X instaladas en volúmenes con formato UFS a Leopard; la actualización requiere reformatear el volumen de arranque. ^{[ 10 ]} Existía un límite de 4 GB para los discos con formato UFS en Mac OS X. A partir de Mac OS X Lion , se eliminó por completo la compatibilidad con UFS. ^{[ 11 ]} 

• Comparación de sistemas de archivos

• Jeroen C. van Gelderen (23 de abril de 2003). "Pequeñas preguntas frecuentes sobre UFS2" . FreeBSD . Archivado desde el original el 6 de febrero de 2026 . Consultado el 8 de abril de 2013 .
• "Sistemas de archivos: Cómo usarlos: Otros sistemas de archivos" . El proyecto de documentación de Linux . 27 de enero de 2007.
• El sistema de archivos UFS de Solaris , archivado . Véase también
• Formato USF(sic)/UFS2
• Localidad y el sistema de archivos rápido