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:
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 por el 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 archivos en el directorio y el inodo asociado con cada archivo. Todos los metadatos del archivo se guardan 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 funcionó bien para los discos pequeños para los cuales se diseñaron los primeros Unix, pero a medida que la tecnología avanzó y los discos crecieron, mover la cabeza hacia adelante y hacia atrás entre el grupo de inodos y los bloques de datos a los que se referían causaba golpes . Marshall Kirk McKusick , entonces estudiante de posgrado de Berkeley , optimizó el diseño de V7 FS para crear el FFS (Fast File System) de BSD 4.2 inventando grupos de cilindros, que dividen el disco en trozos más pequeños, y cada grupo tiene sus propios inodos y datos. bloques. [2] [3]
La intención de BSD FFS es intentar 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 grupo de cilindros o en uno cercano, de esta manera reducir 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 totalmente optimizado, el cabezal podría moverse entre pistas cercanas para leer sectores dispersos de pistas alternas mientras se espera que el plato gire.
A medida que los discos crecían cada vez más, la optimización a nivel de sector se volvió obsoleta (especialmente con discos que usaban numeración de sectores lineales 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 de 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 se aumenta el número de bytes representables por cualquier número determinado 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 bloques de mayor tamaño, 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 bloques, fusión de cola o empaquetado de cola , donde el último bloque parcial de datos de varios archivos se puede almacenar en un solo bloque de "fragmento" en lugar de múltiples bloques en su mayoría vacíos. [4]
El trabajo 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 illusmos , han adoptado UFS. La mayoría de ellos adaptaron UFS a sus propios usos, agregando extensiones propietarias que pueden no ser reconocidas por las versiones de Unix de otros proveedores. Muchos [ ¿cuáles? ] han seguido utilizando el tamaño de bloque y los anchos de campo de datos originales como el UFS original, por lo que se mantiene cierto grado de compatibilidad de lectura entre plataformas. [ ¿cual? ] [ cita necesaria ] [ ¿ según quién? ] La compatibilidad entre implementaciones en su conjunto es, en el mejor de los casos, irregular. [¿ según quién? ]
A partir de Solaris 7 , Sun Microsystems incluyó UFS Logging, que llevó el registro del sistema de archivos a UFS, que todavía está disponible en las versiones actuales de Solaris e illusmos. [5] Solaris UFS también tiene extensiones para archivos y discos grandes y otras características.
En los sistemas Unix 4.4BSD y BSD derivados de él, 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 del directorio 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 estructurado de registros FFS tradicional como el 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.
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 coherencia 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 la necesidad de comprobar el sistema de archivos después de un fallo o un corte 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 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 bandera extendidos, Sellos de 'nacimiento', 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 de software y la capacidad de crear instantáneas del sistema de archivos tanto para UFS1 como para UFS2. Desde entonces, se han portado a NetBSD, pero finalmente se eliminaron las actualizaciones suaves (llamadas dependencias suaves en NetBSD) de NetBSD 6.0 en 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 ha soportado actualizaciones suaves desde la versión 2.9 [6] y ha tenido soporte para UFS2 (FFS2) (sin ACL) desde la versión 4.2. [7] OpenBSD ahora ha convertido a UFS2 en la versión UFS predeterminada y se incluirá en la versión 6.7. [8] 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 soporte para registro 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 de directorios. Dirhash alivia una serie de problemas de rendimiento asociados con directorios grandes en UFS.
Linux incluye una implementación UFS para compatibilidad binaria a nivel de lectura con otros Unix, pero como no existe una implementación estándar para las extensiones de UFS del proveedor, Linux no tiene soporte completo para escribir en UFS. El sistema de archivos nativo Linux ext2 se inspiró en UFS1 pero no admite fragmentos y no hay planes para implementar actualizaciones suaves. [ cita necesaria ] (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 fue derivado de BSD, también usó 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 formateados en UFS a Leopard; la actualización requiere reformatear el volumen de inicio. [9] 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. [10]
{{cite tech report}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace ){{cite journal}}: CS1 maint: multiple names: authors list (link)