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 a Unix. Es un descendiente lejano del sistema de archivos original utilizado por la versión 7 de Unix.

Diseño

Un volumen UFS se compone de las siguientes partes:

• A pocas cuadras al comienzo de la partición reservada para bloques de arranque (que deben ser inicializados por separado del sistema de archivos)
• Un superbloque, que contiene un número mágico que identifica esto como un sistema de archivos UFS, y algunos otros números vitales que describen la geometría y estadísticas de este sistema de archivos y parámetros de ajuste conductual
• Una colección de grupos de cilindros. Cada grupo de cilindros tiene los siguientes componentes:
  • Una copia de seguridad de la superbloque
  • Un encabezado de grupo de cilindros, con estadísticas, listas gratuitas, etc., acerca de este grupo de cilindros, similar a los del superbloque
  • Un número de inodes, cada archivo que contiene atributos
  • Un número 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 las 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 perdido+encontrado que es el inodo 3.

Los archivos de directorio contienen solo la lista de nombres de archivo en el directorio y el inodo asociado con cada archivo. Todos los metadatos del archivo se mantienen en el inodo.

Historia y evolución

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 funcionó bien para los discos pequeños para los que se diseñaron los primeros Unix, pero a medida que la tecnología avanzó y los discos se hicieron más grandes, mover la cabeza de un lado a otro entre el grupo de inodos y los bloques de datos a los que se referían causaba problemas. Marshall Kirk McKusick, entonces un estudiante graduado de Berkeley, optimizó el diseño V7 FS para crear FFS (Fast File System) de BSD 4.2 al inventar grupos de cilindros, que dividen el disco en partes más pequeñas, y cada grupo tiene su propio inodos y bloques de datos.

La intención de BSD FFS es tratar de localizar bloques de datos y metadatos asociados en el mismo grupo de cilindros e, idealmente, todo el contenido de un directorio (tanto datos como metadatos para todos los archivos) en el mismo cilindro o en un cilindro cercano. grupo, lo que reduce la fragmentación causada por la dispersión del contenido de un directorio en todo el disco.

Algunos de los parámetros de rendimiento en el 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 completamente optimizado, la cabeza podría moverse entre pistas cercanas para leer sectores dispersos de pistas alternas mientras espera que el plato gire.

A medida que los discos crecían más y más, la optimización a nivel de sector se volvió obsoleta (especialmente con discos que usaban numeración de sector lineal 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 K en 4.0 BSD; y, en FFS, aumentó el tamaño del bloque del sistema de archivos de 1 K a 8 K. Esto tiene varios efectos. La posibilidad de que los sectores de un archivo sean contiguos es mucho mayor. Se reduce la cantidad de sobrecarga para enumerar los bloques del archivo, mientras que aumenta la cantidad de bytes representables por cualquier número de bloques.

También son posibles tamaños de disco más grandes, 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 tamaños de bloque más grandes, los discos con muchos archivos pequeños desperdiciarán espacio, ya que cada archivo debe ocupar al menos un bloque. Debido a esto, BSD agregó fragmentación a nivel de bloque, también llamada subasignación de bloque, fusión de cola o empaquetado de cola, donde el último bloque parcial de datos de varios archivos se puede almacenar en un solo " fragmento" bloque en lugar de múltiples bloques en su mayoría vacíos.

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

Implementaciones

Los proveedores de algunos sistemas Unix patentados, como SunOS/Solaris, System V Release 4, HP-UX y Tru64 UNIX, y sistemas abiertos derivados de Unix como illumos, han adoptado UFS. La mayoría de ellos adaptaron UFS a sus propios usos, agregando extensiones propietarias que pueden no ser reconocidas por otros proveedores. versiones de Unix. Muchos han seguido usando el tamaño de bloque original y los anchos de campo de datos como el UFS original, por lo que se mantiene cierto grado de compatibilidad de lectura entre plataformas. La compatibilidad entre las implementaciones en su conjunto es irregular en el mejor de los casos.

A partir de Solaris 7, Sun Microsystems incluyó UFS Logging, lo que llevó el registro diario del sistema de archivos a UFS, que todavía está disponible en las versiones actuales de Solaris e illumos. Solaris UFS también tiene extensiones para archivos grandes y discos grandes y otras funciones.

En los sistemas 4.4BSD y BSD Unix derivados, como FreeBSD, NetBSD, OpenBSD y DragonFlyBSD, 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 del inodo y capas inferiores que proporcionan contenedores de datos implementados como inodos. Esto se hizo para admitir tanto el FFS tradicional como el sistema de archivos con estructura de registro 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 utiliza para la combinación de la capa inferior FFS y la capa superior UFS, y el término "LFS" se utiliza para la combinación de la capa inferior LFS y la capa superior UFS.

Kirk McKusick implementó la reasignación de bloques, una técnica que reordena los bloques en el sistema de archivos justo antes de que se realicen las escrituras para reducir la fragmentación y controlar el envejecimiento del sistema de archivos. También implementó 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 el efecto secundario de reducir el requisito de verificación del sistema de archivos después de un bloqueo o falla de energía. Para superar los problemas restantes después de una falla, se introdujo una utilidad fsck en segundo plano.

En UFS2, Kirk McKusick y Poul-Henning Kamp ampliaron las capas de FreeBSD FFS y UFS para agregar punteros de bloque de 64 bits (permitiendo que los volúmenes crezcan hasta 8 zebibytes), bloques de tamaño variable (similares a las extensiones), bandera extendida campos, adicional 'hora de nacimiento' sellos, compatibilidad con atributos extendidos y ACL POSIX1.e. UFS2 se convirtió en la versión de UFS admitida a partir de FreeBSD 5.0. FreeBSD también introdujo actualizaciones suaves y la capacidad de realizar instantáneas del sistema de archivos para UFS1 y UFS2. Desde entonces, se han portado a NetBSD, pero finalmente se eliminaron las actualizaciones suaves (llamadas dependencias suaves en NetBSD) de NetBSD 6.0 a favor del mecanismo de registro en diario del sistema de archivos menos complejo llamado WAPBL (también conocido como registro), que se agregó a FFS en NetBSD. 5.0. OpenBSD admite actualizaciones de software desde la versión 2.9 y tiene compatibilidad con UFS2 (FFS2) (sin ACL) desde la versión 4.2. OpenBSD ahora ha convertido a UFS2 en la versión UFS predeterminada y se incluirá con la versión 6.7. Desde FreeBSD 7.0, UFS también admite el registro en diario del sistema de archivos utilizando el proveedor gjournal GEOM. FreeBSD 9.0 agrega compatibilidad con el registro en diario ligero además de actualizaciones suaves (SU+J), lo que reduce en gran medida la necesidad de fsck en segundo plano y ACL 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 alivia una serie de problemas de rendimiento asociados con directorios grandes en UFS.

Linux incluye una implementación de UFS para la compatibilidad binaria en el nivel de lectura con otros Unixes, pero dado que no existe una implementación estándar para las extensiones del proveedor de UFS, Linux no tiene soporte completo para escribir en UFS. El sistema de archivos nativo de Linux ext2 se inspiró en UFS1 pero no admite fragmentos y no hay planes para implementar actualizaciones suaves. (En algunos sistemas derivados de 4.4BSD, la capa UFS puede usar una capa ext2 como capa contenedora, al igual que puede usar FFS y LFS).

NeXTStep, que se derivó de BSD, también usó una versión de UFS. En Mac OS X de Apple, estaba disponible como una alternativa a HFS+, su sistema de archivos patentado. 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 volver a formatear el volumen de inicio. Había un límite de archivos de 4 GB para discos formateados como UFS en Mac OS X. A partir de Mac OS X Lion, la compatibilidad con UFS se eliminó por completo.