Sistema de archivos Unix - Unix File System

UFS
Desarrollador (es) CSRG
Nombre completo Sistema de archivos UNIX
Introducido con 4.2BSD
Estructuras
Contenidos del directorio mesas
Limites
Max. tamaño del volumen 2 73 bytes (8 ZiB )
Max. tamaño del archivo 2 73 bytes (8 ZiB )
Max. longitud del nombre de archivo 255 bytes
Características
Fechas registradas UFS1 y UFS2: última hora de acceso (atime), última hora de modificación (mtime), última hora de cambio de inodo (ctime), UFS2: hora de creación de inode (hora de nacimiento)
Rango de fechas UFS1: 14 de diciembre de 1901 a 18 de enero de 2038, UFS2: desplazamiento de entero de 64 bits con signo desde la época
Resolución de fecha UFS1 y UFS2: nanosegundos
Otro
Apoyados sistemas operativos A / UX , DragonFly BSD , FreeBSD , FreeNAS , NAS4Free , HP-UX , NetBSD , NeXTSTEP , Linux , OpenBSD , illumos , Solaris , SunOS , Tru64 UNIX , UNIX System V y otros

El sistema de archivos UNIX ( UFS ) es un sistema de archivos con el apoyo de muchos Unix y Unix-como sistemas operativos. Es un descendiente lejano del sistema de archivos original utilizado por la versión 7 de Unix .

Más tarde, se utilizó Berkeley Fast File System (también llamado BSD Fast File System - FFS ) en Unixes, que no es lo mismo que UFS.

Diseño

Un volumen UFS se compone de las siguientes partes:

  • Algunos bloques al comienzo de la partición reservada 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 algunos otros números vitales que describen la geometría y las estadísticas de este sistema de archivos y los parámetros de ajuste de comportamiento.
  • Una colección 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, similares a los del superbloque
    • Varios inodos , cada uno de los cuales contiene atributos de archivo.
    • Varios 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 guardan en el inodo.

Historia y evolución

Las primeras versiones de los 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 pequeños discos principios de Unix fue diseñada para, pero a medida que avanza la tecnología y los discos se hizo más grande, moviendo la cabeza hacia atrás y hacia adelante entre el grupo de nodos y los bloques de datos que se referían causado golear . Marshall Kirk McKusick , entonces un estudiante graduado de Berkeley , optimizó el FFS (Fast File System) del 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.

La intención de BSD FFS es intentar localizar los bloques de datos asociados y los metadatos 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, por lo tanto 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 las pistas. En un sistema totalmente 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 cada vez 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 se aumenta el número de bytes representables por cualquier número dado 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 bit 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 puede almacenarse en un solo bloque de "fragmentos" en lugar de varios bloques en su mayoría vacíos ( Allen 2005 ).

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 las versiones de Unix de otros proveedores. Muchos han seguido usando el tamaño de bloque original y los anchos de campo de datos como el UFS original, por lo que queda cierto grado de compatibilidad de lectura en todas las 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, que llevó el registro 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 y discos grandes y otras funciones.

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 inodo y capas inferiores que proporcionan contenedores de datos implementados como inodos. Esto se hizo para admitir tanto el sistema de archivos estructurado de registros LFS como el FFS tradicional 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 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 extendieron las capas FreeBSD FFS y UFS 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 extensiones ), campos de marca extendidos, adicionales Sellos de 'hora de nacimiento', compatibilidad con atributos extendidos y ACL POSIX1.e. UFS2 se convirtió en la versión UFS predeterminada 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, estos han sido portados a NetBSD, pero eventualmente las actualizaciones suaves (llamadas dependencias suaves en NetBSD) se eliminaron de NetBSD 6.0 a favor del mecanismo de registro por 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 admitido actualizaciones suaves desde la versión 2.9 y ha tenido soporte UFS2 (FFS2) (sin ACL) desde la versión 4.2. OpenBSD ha convertido a UFS2 en la versión predeterminada de UFS 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 soporte para un 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 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 en el nivel de lectura con otros Unix, pero como no existe una implementación estándar para las extensiones de proveedores para 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 fue derivado de BSD, también usó una versión de UFS. En Manzana 's Mac OS X , que 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. 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.

Ver también

Referencias

Citas

Bibliografía

enlaces externos