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 del directorio raíz , que siempre es el inodo 2 y el inodo del directorio perdido+encontrado, que es el inodo 3.
Los archivos de directorio contienen únicamente la lista de nombres de archivos del directorio y el inodo asociado a cada archivo. Todos los metadatos de los archivos 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 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, mover el cabezal de un lado a otro entre el grupo de inodos y los bloques de datos a los que se referían causaba problemas de movimiento . Marshall Kirk McKusick , entonces estudiante de posgrado en Berkeley , optimizó el diseño de FS V7 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 bloques de datos. [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 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 un disco.
Algunos de los parámetros de rendimiento del superbloque incluían la cantidad 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, 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 se hicieron cada vez más grandes, la optimización a nivel de sectores se volvió obsoleta (especialmente con discos que usaban numeración de sectores 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 de bloque del sistema de archivos de un sector a 1 K en 4.0 BSD; y, en FFS, aumentó el tamaño de bloque del sistema de archivos de 1 K a 8 K. Esto tiene varios efectos. La probabilidad de que los sectores de un archivo sean contiguos es mucho mayor. La cantidad de sobrecarga para enumerar los bloques del archivo se reduce, mientras que la cantidad de bytes representables por cualquier número dado de bloques aumenta.
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 bloques, fusión de cola o empaquetamiento de cola , donde el último bloque parcial de datos de varios archivos puede almacenarse en un solo bloque "fragmentado" en lugar de múltiples bloques casi 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 illumos , han adoptado UFS. La mayoría de ellos adaptaron UFS a sus propios usos, añadiendo 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. [ ¿cuáles? ] [ cita requerida ] [ ¿según quién? ] La compatibilidad entre implementaciones en su conjunto es irregular en el mejor de los casos. [ ¿según quién? ]
A partir de Solaris 7 , Sun Microsystems incluyó UFS Logging, que incorporó el registro del sistema de archivos a UFS, que todavía está disponible en las versiones actuales de Solaris e illumos. [5] Solaris UFS también tiene extensiones para archivos grandes 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 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 estructurado en 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 consistencia del sistema de archivos sin limitar el rendimiento de la forma en que 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 una falla 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 añadir punteros de bloque de 64 bits (permitiendo que los volúmenes crecieran hasta 8 zebibytes ), bloques de tamaño variable (similares a las extensiones ), campos de indicadores ampliados, marcas de "fecha de nacimiento" adicionales, compatibilidad con atributos ampliados y listas de control de acceso (ACL) POSIX1.e. UFS2 se convirtió en la versión de UFS compatible a partir de FreeBSD 5.0. FreeBSD también introdujo actualizaciones suaves y la capacidad de realizar instantáneas del sistema de archivos tanto para UFS1 como para UFS2. Desde entonces, estas se han trasladado a NetBSD, pero finalmente las actualizaciones suaves (llamadas dependencias suaves en NetBSD) se eliminaron de NetBSD 6.0 a favor del mecanismo de registro del sistema de archivos menos complejo llamado WAPBL (también conocido como registro), que se añadió 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 ha hecho que UFS2 sea la versión UFS predeterminada y se incluirá con la versión 6.7. [8] Desde FreeBSD 7.0, UFS también soporta el registro en diario del sistema de archivos usando el proveedor GEOM gjournal . FreeBSD 9.0 agrega soporte para el registro en diario liviano sobre las 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 de UFS para compatibilidad binaria a nivel de lectura con otros sistemas Unix, pero como no hay una implementación estándar para las extensiones de los proveedores para UFS, Linux no tiene soporte completo para escribir en UFS. El sistema de archivos ext2 nativo de Linux se inspiró en UFS1 pero no admite fragmentos y no hay planes para implementar actualizaciones suaves. [ cita requerida ] (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 era un derivado de BSD, también usaba una versión de UFS. En Mac OS X de Apple , estaba disponible como una 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 inicio. [9] Había un límite de archivo 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}}: CS1 maint: varios nombres: lista de autores ( enlace ){{cite journal}}: CS1 maint: multiple names: authors list (link)