Unix File System
Es el acronimo para denominar al sistema de archivos UNIX file system (UFS) el cual es un sistema de archivos utilizado por varios sistemas operativos UNIX y tipo-UNIX. Es un derivado del Berkeley Fast File System (FFS), el cual es desarollado desde FS UNIX desarollado en los laboratorios Bell.
Casi todos los derivativos de BSD incluyendo a FreeBSD, NetBSD, OpenBSD, NeXTStep, y Solaris utilizan una variante de UFS. En Mac OS X esta disponible como una alternativa al HFS. En Linux, existe soporte parcial al sistema de archivos UFS, de solo lectura, y utiliza sistema de archivos nativo de tipo ext2 el cual es inspirado en UFS.
Diseño
Un sistema de archivos UFS se compone de las siguientes partes:
- unos pocos bloques al inicio de la particion reservados para bootstrap (el cual debe ser inicializado separadamente del sistema de archivos)
- un superbloque que contine un magic number identificando esto como un UFS, y algunos otros numeros vitales describiendo la geometria y parametros de puesta a punto del comportamiento
- una coleccion de grupos de cilindros; Cada grupo de cilindros tiene estos componentes:
- un respaldo del superbloque
- una cabezera de cilindro, con estadisticas, lista de espacio libre, etc. acerca de este bloque de cilindros, similar a los que se encuentran en el superbloque.
- un numero de inodos, cada cual conteniendo los atributos del archivo
- un numero de bloques de datos
Los inodos son numerados sequencialmente, Los primeros inodos estan reservados por razones historicas, seguidos por los inodos del directorio raiz.
Los archivos de directorio contienen solo la lista de archivos en el directorio y el inodo asociado para cada archivo. Toda la metadata es mantenida en el inodo.
Historia y evolución
Las mas tempranas versiones de UNIX utilizaban un sistema de archivos al que se referian simplemente como FS. FS solo incluia el bloque de booteo, superbloque, un puñado de inodos y los bloques de datos. Esto funcionaba bien para los pequeños discos que los UNIX de aquel tiempo estaban diseñados, pero la tecnologia avanzo y los discos comenzaron a crecer, moviendo la cabeza hacia atras y adelante entre el grupo de inodos y los bloques de datos a los que ellos se referian, causando thrash(sistema de archivos). BSD optimizo esto en el FFS invirtiendo los grupos de cilindros, dividiendo el disco en grupos mas pequeños, cada uno con su propio grupo de inodos y bloques de datos.
Lo que realiza el BSD FFS es tratar de localizar los bloques de datos asociados y los metadatos en el mismo grupo de cilindros, y idealmente, todos el contenido de un directorio (datos y metadatos para todo el archivo) en el mismo o cercano por el grupo de cilindros, esto logrando reducir la fragmentacion causada por la dispercion del contenido de los directorios por todo el disco.
Algunos de los parametros de rendimiento en el superbloque inclyen un numero de pistas y sectores, velocidad de rotacion del disco, y alineamiento de los sectores entre pistas. En un sistema completamente optimizado, la cabeza puede ser movida entre pistas cercanas para leer los sectores fragmentados de alternarse las pistas mientras espera que el disco gire.
Mientras los discos se hicieron grandes, y mas grandes, las optimizaciones del sector de nivel pasaron a ser obsoletas (Especialmente con discos que usaban numeracion de lineal y sectores variables por pista). Con discos mas grandes, y archivos mas grandes, lecturas fragmentadas se transformaron en un problema más grande. Para combatir esto, BSD incremento el tamaño de los bloques del sistema de archivos de un sector a 8k. Esto tuvo efectos varios. La oportunidad de que los sectores de archivos estubieran contiguos es mucho mas alta. La cantidad de gastos indirectos para enumerar los bloques del archivo se reduce. El numero de bloques representable en el ancho de un bit fijo fue incrementado (permitiendo discos mas grandes).
Con bloques de tamaño mas grande, los discos con muchos archivos pequeños podrian perder mucho espacio, asi que BSD añadio "block level fragmentation", donde el ultimo bloque parcial de datos de muchos archivos podria ser guardado en un solo bloque de "fragmento" en vez de en muchos bloques vacios.
Implementaciones
La mayoria de los vendedores adapto UFS a sus propias necesidades, añadiendo extensiones propietarias que podrian no ser reconocidas por versiones de UNIX de otros desarolladores. Sorpresivamente, muchos han continuado usando el tamaño original de bloques y campos de datos con de la misma amplitud que el UFS original, asi que algun grado de compatibilidad (lectura) se mantiene entre plataformas.
FreeBSD 5.0 introdujo UFS2, el cual añade soporte para volumenes sobre un 1TB (TeraByte) y para imagenes del sistema de archivos. Ha sido portado a NetBSD.
El sistema de archivos ext2 de Linux fue escrito desde cero (scratch) basado en conceptos de UFS. ext2 Permite configurar tamaños de bloques en el momento de la creación del sistema de archivos para soportar discos mas grandes. Ademas tiene campos de datos de 64 bits en el inodo para aceptar archivos mas grandes. Ext3 añade journaling. ReiserFS fue el primer sistema de archivos con journaling incluido en el Kernel de Linux y es mas rapido trabajando con archivos pequeños. Linux incluye una implementacion de UFS para compatibilidad binaria al nivel de lectura con otros unices, pero como no existe una implementacion estandar para las extensiones de los vendedores, Linux no tiene soporte de escritura para UFS.
Desde Solaris 7, Sun Microsystems incluyo UFS Logging en el Entorno Operativo Solaris, el cual brinda sistemas de archivos con journaling (jornalizados) a UFS. El UFS de Solaris tambien tiene extensiones para archivos grandes, discos grandes y otras caracteristicas.