Un sistema de archivos son los métodos y estructuras de datos que un sistema operativo utiliza para seguir la pista de los archivos de un disco o partición; es decir, es la manera en la que se organizan los archivos en el disco. El término también es utilizado para referirse a una partición o disco que se está utilizando para almacenamiento, o el tipo del sistema de archivos que utiliza. Así uno puede decir “tengo dos sistemas de archivo” refiriéndose a que tiene dos particiones en las que almacenar archivos, o que uno utiliza el sistema de “archivos extendido”, refiriéndose al tipo del sistema de archivos.

La diferencia entre un disco o partición y el sistema de archivos que contiene es importante. Unos pocos programas (incluyendo, razonablemente, aquellos que crean sistemas de archivos) trabajan directamente en los sectores crudos del disco o partición; si hay un archivo de sistema existente allí será destruido o corrompido severamente. La mayoría de programas trabajan sobre un sistema de archivos, y por lo tanto no utilizarán una partición que no contenga uno (o que contenga uno del tipo equivocado).

Antes de que una partición o disco sea utilizada como un sistema de archivos, necesita ser iniciada, y las estructura de datos necesitan escribirse al disco. Este proceso se denomina construir un sistema de archivos.

La mayoría de los sistema de archivos UNIX tienen una estructura general parecida, aunque los detalles exactos pueden variar un poco. Los conceptos centrales son superbloque, nodo-i, bloque de datos, bloque de directorio, y bloque de indirección. El superbloque tiene información del sistema de archivos en conjunto, como su tamaño (la información precisa aquí depende del sistema de archivos). Un nodo-i tiene toda la información de un archivo, salvo su nombre. El nombre se almacena en el directorio, junto con el número de nodo-i. Una entrada de directorio consiste en un nombre de archivo y el número de nodo-i que representa al archivo. El nodo-i contiene los números de varios bloques de datos, que se utilizan para almacenar los datos en el archivo. Sólo hay espacio para unos pocos números de bloques de datos en el nodo-i; en cualquier caso, si se necesitan más, más espacio para punteros a los bloques de datos son colocados de forma dinámica. Estos bloques colocados dinámicamente son bloques indirectos; el nombre indica que para encontrar el bloque de datos, primero hay que encontrar su número en un bloque indirecto.

Los sistemas de archivos UNIX generalmente nos permiten crear un agujero en un archivo (esto se realiza con la llamada al sistema lseek(); compruebe su página de manual), lo que significa que el sistema de archivos simplemente intenta que en un lugar determinado en el archivo haya justamente cero bytes, pero no existan sectores del disco reservados para ese lugar en el archivo (esto significa que el archivo utilizará un poco menos de espacio en disco). Esto ocurre frecuentemente en especial para pequeños binarios, librerías compartidas de Linux, algunas bases de datos, y algunos pocos casos especiales. (los agujeros se implementan almacenando un valor especial en la dirección del bloque de datos en el bloque indirecto o en el nodo-i. Esta dirección especial indica que ningún bloque de datos está localizado para esa parte del archivo, y por lo tanto, existe un agujero en el archivo).

Linux soporta una gran cantidad de tipos diferentes de sistemas de archivos. Para nuestros propósitos los más importantes son:

Adicionalmente, existe soporte para sistemas de archivos adicionales ajenos, para facilitar el intercambio de archivos con otros sistemas operativos. Estos sistemas de archivos ajenos funcionan exactamente como los propios, excepto que pueden carecer de características usuales UNIX , o tienen curiosas limitaciones, u otros inconvenientes.

La elección del sistema de archivos a utilizar depende de la situación. Si la compatibilidad o alguna otra razón hace necesario uno de los sistemas de archivos no nativos, entonces hay que utilizar ése. Si se puede elegir libremente, entonces lo más inteligente sería utilizar ext3, puesto que tiene todas las características de ext2, y es un sistema de archivos con bitácora.

Existe también el sistema de archivos proc, generalmente accesible desde el directorio /proc, que en realidad no es un sistema de archivos, aún cuando lo parece. El sistema de archivos proc facilita acceder a ciertas estructura de datos del núcleo, como la lista de procesos (de ahí el nombre). Hace que estas estructuras de datos parezcan un sistema de archivos, y que el sistema de archivos pueda ser manipulado con las herramientas de archivos habituales. Por ejemplo, para obtener una lista de todos los procesos se puede utilizar el comando

$ ls -l /proc
total 0
dr-xr-xr-x   4 root     root            0 Jan 31 20:37 1
dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 63
dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 94
dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 95
dr-xr-xr-x   4 root     users           0 Jan 31 20:37 98
dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 99
-r--r--r--   1 root     root            0 Jan 31 20:37 devices
-r--r--r--   1 root     root            0 Jan 31 20:37 dma
-r--r--r--   1 root     root            0 Jan 31 20:37 filesystems
-r--r--r--   1 root     root            0 Jan 31 20:37 interrupts
-r--------   1 root     root      8654848 Jan 31 20:37 kcore
-r--r--r--   1 root     root            0 Jan 31 11:50 kmsg
-r--r--r--   1 root     root            0 Jan 31 20:37 ksyms
-r--r--r--   1 root     root            0 Jan 31 11:51 loadavg
-r--r--r--   1 root     root            0 Jan 31 20:37 meminfo
-r--r--r--   1 root     root            0 Jan 31 20:37 modules
dr-xr-xr-x   2 root     root            0 Jan 31 20:37 net
dr-xr-xr-x   4 root     root            0 Jan 31 20:37 self
-r--r--r--   1 root     root            0 Jan 31 20:37 stat
-r--r--r--   1 root     root            0 Jan 31 20:37 uptime
-r--r--r--   1 root     root            0 Jan 31 20:37 
version
$

(Puede haber no obstante algunos archivos adicionales que no correspondan con ningún proceso. El ejemplo anterior se ha recortado.)

Tenga en cuenta que aunque se llame sistema de archivos, ninguna parte del sistema de archivos proc toca el disco. Existe tan sólo en la imaginación del núcleo. Cuando alguien intenta echar un vistazo a alguna parte del sistema de archivos proc, el núcleo hace que parezca como si esa parte existiera en alguna parte, aunque no lo haga. Así, aunque exista un archivo /proc/kcore de muchos megabytes, no quita espacio del disco.

Existe generalmente poca ventaja en utilizar muchos sistemas de archivos distintos. Actualmente, el más popular sistema de archivos es ext3, debido a que es un sistema de archivos con bitácora. Hoy en día es la opción más inteligente. Reiserfs es otra elección popular porque también posee bitácora. Dependiendo de la sobrecarga del listado de estructuras, velocidad, fiabilidad (percibible), compatibilidad, y otras varias razones, puede ser aconsejable utilizar otro sistema de archivos. Estas necesidades deben decidirse en base a cada caso.

Un sistema de archivos que utiliza bitácora se denomina sistema de archivos con bitácora. Un sistema de archivos con bitácora mantiene un diario, la bitácora, de lo que ha ocurrido en el sistema de archivos. Cuando sobreviene una caída del sistema, o su hijo de dos años pulsa el botón de apagado como el mío adora hacer, un sistema de archivos con bitácora se diseña para utilizar los diarios del sistema de archivos para recuperar datos perdidos o no guardados. Esto reduce la pérdida de datos y se convertirá en una característica estándar en los sistemas de archivos de Linux. De cualquier modo, no extraiga una falsa sensación de seguridad de esto. Como todo en esta vida, puede haber errores. Procure siempre guardar sus datos para prevenir emergencias.

Un sistema de archivos se crea, esto es, se inicia, con el comando mkfs. Existen en realidad programas separados para cada tipo de sistemas de archivos. mkfs es únicamente una careta que ejecuta el programa apropiado dependiendo del tipo de sistemas de archivos deseado. El tipo se selecciona con la opción -t fstype.

Los programas a los que -t fstype llama tienen líneas de comando ligeramente diferentes. Las opciones más comunes e importantes se resumen más abajo; vea las páginas de manual para más información.

Para crear un sistema de archivos ext2 en un disquete, se pueden introducir los siguiente comandos:

$ fdformat -n /dev/fd0H1440
Double-sided, 80 tracks, 18 sec/track. Total capacity 
1440 kB.
Formatting ... done
$ badblocks /dev/fd0H1440 1440 $>$ 
bad-blocks
$ mkfs -t ext2 -l bad-blocks 
/dev/fd0H1440
mke2fs 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10
360 inodes, 1440 blocks
72 blocks (5.00%) reserved for the super user
First data block=1
Block size=1024 (log=0)
Fragment size=1024 (log=0)
1 block group
8192 blocks per group, 8192 fragments per group
360 inodes per group

Writing inode tables: done
Writing superblocks and filesystem accounting information: 
done
$

Primero el disquete es formateado (la opción -n impide la validación, esto es, la comprobación de bloques defectuosos). A continuación se buscan los bloques defectuosos mediante badblocks, con la salida redirigida a un archivo, bad-blocks. Finalmente, se crea el sistema de archivos con la lista de bloques defectuosos iniciada con lo que hubiera encontrado badblocks.

La opción -c podría haberse utilizado con mkfs en lugar de badblocks y un archivo a parte. El ejemplo siguiente hace esto.

$ mkfs -t ext2 -c 
/dev/fd0H1440
mke2fs 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10
360 inodes, 1440 blocks
72 blocks (5.00%) reserved for the super user
First data block=1
Block size=1024 (log=0)
Fragment size=1024 (log=0)
1 block group
8192 blocks per group, 8192 fragments per group
360 inodes per group

Checking for bad blocks (read-only test): done
Writing inode tables: done
Writing superblocks and filesystem accounting information: 
done
$

La opción -c es más conveniente que la utilización a parte de badblocks, pero badblocks se necesita para comprobar el sistema de archivos una vez creado.

El proceso para preparar sistemas de archivos en discos duros o particiones es le mismo que para los disquetes, excepto que no es necesario el formateo.

Antes de que se pueda utilizar un sistema de archivos, debe ser montado. El sistema operativo realiza entonces operaciones de mantenimiento para asegurarse que todo funciona. Como todos los archivos en UNIX están en un mismo árbol de directorios, la operación de montaje provocará que el contenido del nuevo sistema de archivos aparezca como el contenido de un subdirectorio existente en algún sistema de archivos ya montado.

Por ejemplo, la Figura 6.4, “Tres sistemas de archivos independientes.” muestra tres sistemas de archivos independientes, cada uno de ellos con su propio directorio raíz. Cuando se montan los dos últimos sistemas de archivos bajo /home y /usr respectivamente, en el primer sistema de archivos, obtenemos un único árbol de directorios, como se observa en la Figura 6.5, “/home y /usr montados.”.

Figura 6.4. Tres sistemas de archivos independientes.

Figura 6.5. /home y /usr montados.

El montaje puede realizarse como en el siguiente ejemplo:

$ mount /dev/hda2 /home
$ mount /dev/hda3 /usr
$

El comando mount tiene dos argumentos. El primero es el archivo de dispositivo correspondiente al disco o partición que contiene el sistema de archivos. El segundo es el directorio bajo el cual va a ser montado. Tras estos dos comandos el contenido de los dos sistemas de archivos aparecen como los contenidos de los directorios /home y /usr, respectivamente. Se dice que “/dev/hda2 está montado en /home”, e igualmente para /usr. Para ver cualquiera de los sistemas de archivos, se puede mirar el contenido del directorio en el que fue montado, como si fuera cualquier otro directorio. Observe la diferencia entre el archivos de dispositivo, /dev/hda2, y el directorio de montaje, /home. El archivo de dispositivo proporciona acceso al contenido crudo del disco, el directorio de montaje proporciona acceso a los archivos del disco. El directorio de montaje se denomina punto de montaje.

$ mount -t msdos /dev/fd0 /floppy
$

El directorio de montaje necesita estar vacío, aunque debe existir. Cualquier archivo en él, en cualquier caso, será inaccesible por su nombre mientras el sistema de archivos esté montado. (Cualquier archivo que estuviera abierto seguirá estando accesible. Archivos que tengan enlaces duros desde otros directorios podrán accederse utilizando esos nombres.) No hay daño alguno haciendo esto, y puede incluso ser útil. Por ejemplo, a alguna gente le gusta tener a /tmp y /var/tmp como sinónimos, y poner /tmp como enlace simbólico a /var/tmp. Cuando el sistema arranca, antes de montar el sistema de archivos /var, se utiliza un directorio /var/tmp residente en el sistema de archivos raíz en su lugar. Cuando /var se monta, convertirá al directorio /var/tmp del sistema de archivos raíz inaccesible. Si /var/tmp no existe en el el sistema de archivos raíz, será imposible utilizar los archivos temporales antes de montar /var.

Si no tiene intención de escribir nada en el sistema de archivos, utilice el modificador -r de mount para realizar un montaje de sólo-lectura. Esto provocará que el núcleo detenga cualquier intento de escribir en el sistema de archivos, y también impedirá que el núcleo actualice el tiempo de acceso a los nodos-i. Montaje de sólo-lectura son necesarios para medios no grabables, como los CD-ROM.

El lector atento habrá notado un ligero problema lógico. ¿Cómo se monta el primer sistema de archivos (denominado sistema de archivos raíz, ya que contiene al directorio raíz), si obviamente no puede montarse sobre otro sistema de archivos? Bueno, la respuesta es que se realiza un truco de magia. ^[14] El sistema de archivos raíz se monta mágicamente a la hora del arranque, y se puede confiar en que siempre será montado. Si el sistema de archivos no puede montarse, el sistema no arrancará. El nombre del sistema de archivos que mágicamente se monta como root está compilado dentro del núcleo, o se especifica utilizando LILO o rdev.

El sistema de archivos raíz se monta generalmente para sólo-lectura. Los guiones (scripts) de inicio ejecutarán entonces fsck para comprobar su validez, y si no hay problemas, volverá a montarlo para permitir la escritura. fsck no debe ejecutarse en sistemas de archivos montados, puesto que cualquier cambio en el sistema de archivos mientras se ejecuta fsck puede causar problemas. Como el sistema de archivos raíz se monta como sólo-lectura mientras se comprueba, fsck puede corregir cualquier problema sin preocuparse, porque la operación de remontaje vaciará cualquier metadato que el sistema de archivos mantuviera en memoria.

En muchos sistemas existen otros sistemas de archivos que también deben montarse de forma automática durante en el arranque. Estos se especifican en el archivo /etc/fstab ; vea la página de manual de fstab para los detalles en el formato. Los detalles sobre cuándo se montan exactamente los sistemas de archivos adicionales dependen de muchos factores, y pueden ser configurados por cada administrador si lo necesita; vea el Capítulo 8, Encendido y apagado.

Cuando un sistema de archivos no se necesita seguir montado, puede desmontarse con umount. ^[15] umount toma un argumento: o bien el archivo de dispositivo o el punto de montaje. Por ejemplo, para desmontar los directorios del ejemplo anterior, se pueden utilizar los comandos

$ umount /dev/hda2
$ umount /usr
$

Lea la página de manual para más información sobre cómo utilizar el comando. Es obligatorio que siempre se desmonte un disquete montado. ¡No saque únicamente el disquete de la disquetera! Debido al cacheado de disco, los datos no se escriben necesariamente hasta que se desmonta el disquete, así que sacar el disquete de la disquetera demasiado pronto puede provocar que el contenido se vuelva erróneo. Si únicamente lee del disquete, esto no es muy usual, pero si escribe, incluso accidentalmente, el resultado puede ser catastrófico.

Montar y desmontar requieren privilegios de superusuario, esto es, sólo root puede hacerlo. La razón para esto es que si un usuario puede montar un disquete en cualquier directorio, entonces es relativamente fácil crear un disquete con, digamos, un caballo de Troya disfrazado de /bin/sh, o cualquier otro programa frecuentemente utilizado. De cualquier modo, se necesita generalmente permitir a los usuarios utilizar los disquetes, y hay varias maneras de hacerlo:

La última alternativa puede implementarse añadiendo una línea como la siguiente en el archivo /etc/fstab:

/dev/fd0            /floppy      msdos   user,noauto      0     0

Las columnas corresponden a: archivo de dispositivo a montar, directorio de montaje, tipo de sistema de archivos, opciones, frecuencia de copia de seguridad (utilizado por dump), y el número de paso para fsck (especifica el orden en el que los sistemas de archivos son comprobados en el arranque; 0 significa que no se comprueba).

La opción noauto impide que se monte automáticamente al iniciar el sistema (es decir, previene que mount -a la monte). La opción user permite a cualquier usuario montar el sistema de archivos, y, debido a cuestiones de seguridad, deniega la ejecución de programas (normales o con setuid) y la interpretación de sistemas de archivos desde el sistema de archivos montado. Después de eso, cualquier usuario puede montar un disquete con un sistemas de archivos msdos con el comando siguiente:

$ mount /floppy
$

El disquete puede (y necesita de ello, por supuesto) desmontarse con la orden umount correspondiente.

Si desea otorgar acceso para varios tipos de disquetes, necesita proporcionar distintos puntos de montaje. Las opciones pueden ser diferentes para cada punto de montaje. Por ejemplo, para permitir accesos a disquetes MS-DOS o ext2, se pueden tener las siguientes líneas en /etc/fstab:

/dev/fd0    /dosfloppy    msdos   user,noauto  0  0
/dev/fd0    /ext2floppy   ext2    user,noauto  0  0

Para sistemas de archivos MS-DOS (no sólo disquetes), probablemente quiera restringir el acceso utilizando las opciones del sistema de archivos uid, gidy umask, descritas en detalle en la página de manual de mount. Si no es cuidadoso, montar un sistema de archivos MS-DOS proporciona al menos acceso de lectura a los archivos que hay en él, lo que no es una buena idea.

Los sistemas de archivos son criaturas complejas, y como tales, tienden a ser propensos a los errores. La corrección y validación de un sistema de archivos puede ser comprobada utilizando el comando fsck. Puede ser instruido para reparar cualquier problema menor que encuentre, y alertar al usuario si hay errores irreparables. Afortunadamente, el código implementado en los sistemas de archivos puede estudiarse de forma muy efectiva, así que escasamente hay problemas, y normalmente son causados por fallos de alimentación, hardware defectuoso, o errores de operación; por ejemplo, no apagar el sistema adecuadamente.

La mayoría de los sistemas se configuran para ejecutar fsck automáticamente durante el arranque, así que cualquier error se detecta (y esperemos que corregido) antes que el sistema se utilice. Utilizar un sistema de archivos corrupto tiende a empeorar las cosas: si las estructuras de datos se mezclan, utilizar el sistema de archivos probablemente las mezclará aún más, resultando en una mayor pérdida de datos. En cualquier caso, fsck puede tardar un tiempo en ejecutarse en sistemas de archivos grandes, y puesto que los errores casi nunca suceden si el sistema se ha apagado adecuadamente, pueden utilizarse un par de trucos para evitar realizar comprobaciones en esos casos. El primero es que si existe el archivo /etc/fastboot, no se realizan comprobaciones. El segundo es que el sistema de archivos ext2 tiene una marca especial en su superbloque que indica si el sistema de archivos se desmontó adecuadamente después del montaje previo. Esto permite a e2fsck (la versión de fsck para el sistema de archivos ext2) evitar la comprobación del sistema de archivos si la bandera indica que se realizó el desmontaje (la suposición es que un desmontaje adecuado indica que no hay problemas). Que el truco de /etc/fastboot funcione en su sistema depende de sus guiones (scripts) de inicio, pero el truco de ext2 funciona cada vez que utilice e2fsck. Debe ser sobrepasado explícitamente con una opción de e2fsck para ser evitado. (Vea la página de manual de e2fsck para los detalles sobre cómo.).

La comprobación automática sólo funciona para los sistemas de archivos que se montan automáticamente en el arranque. Utilice fsck de forma manual para comprobar otros sistemas de archivos, por ejemplo, disquetes.

Si fsck encuentra problemas irreparables, necesita conocimientos profundos de cómo funciona en general un sistema de archivos, y en particular el tipo del sistema de archivos corrupto, o buenas copias de seguridad. Lo último es fácil (aunque algunas veces tedioso) de arreglar, el precedente puede solucionarse a través de un amigo, los grupos de noticias y listas de correo de Linux, o alguna otra fuente de soporte, si no sabe cómo hacerlo usted mismo. Me gustaría contarle más sobre el tema, pero mi falta de formación y experiencia en este asunto me lo impiden. El programa de Theodore Ts'o debugfs puede ser de ayuda.

fsck debe ser utilizado únicamente en sistemas de archivos desmontados, nunca en sistemas de archivos montados (a excepción del raíz en sólo-lectura en el arranque). Esto es así porque accede al disco directamente, y puede por lo tanto modificar el sistema de archivos sin que el sistema operativo se percate de ello. Habrá problemas, si el sistema operativo se confunde.

Puede ser buena idea comprobar los bloques defectuosos periódicamente. Esto se realiza con el comando badblocks. Saca una lista de los números de todos los bloques malos que puede encontrar. Esta lista puede introducirse en fsck para grabar en el sistema de archivos las estructuras de datos para que el sistema operativo no intente utilizar los bloques malos para almacenar datos. El ejemplo siguiente muestra cómo puede hacerse esto.

$ badblocks /dev/fd0H1440 1440 > 
bad-blocks
$ fsck -t ext2 -l bad-blocks 
/dev/fd0H1440
Parallelizing fsck version 0.5a (5-Apr-94)
e2fsck 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Check reference counts.
Pass 5: Checking group summary information.

/dev/fd0H1440: ***** FILE SYSTEM WAS MODIFIED *****
/dev/fd0H1440: 11/360 files, 63/1440 blocks
$

Si badblocks informa de que un bloque se está utilizando, e2fsck intentará mover el bloque a otro lugar. Si el bloque estaba realmente defectuoso, no tan sólo marginado, el contenido del archivo puede estar corrupto.

Cuando un archivo se escribe en el disco, no puede escribirse siempre en bloques consecutivos. Un archivos que no está almacenado en bloques consecutivos está fragmentado. Leer un archivo fragmentado requiere mayor tiempo, puesto que la cabeza de lectura-escritura del disco debe moverse más. Es deseable evitar la fragmentación, aunque es un problema menor en un sistema con un buen caché buffer con lectura progresiva.

El sistema de archivos ext2 intenta mantener la fragmentación al mínimo, manteniendo todos los bloques de un archivo juntos, incluso cuando no pueden almacenarse en sectores consecutivos. Ext2 efectivamente localiza el bloque libre más cercano a los otros bloques del archivo. Por lo tanto para ext2 hay poca necesidad de preocuparse por la fragmentación. Existe un programa para desfragmentar un sistema de archivos ext2, llamado extrañamente defrag [24].defrag ^[17] .

Existen muchos programas de desfragmentación MS-DOS que mueven los bloques por todo el sistema de archivos para eliminar la fragmentación. Para otros sistemas de archivos, la desfragmentación debe hacerse guardando el sistema de archivos, volverlo a crear, y restaurando los archivos de la copia guardada. Guardar un sistema de archivos antes de desfragmentarlo es una buena idea para cualquier sistema de archivos, puesto que muchas cosas pueden ir mal durante la desfragmentación.

Algunas herramientas adicionales pueden resultar útiles para manejar sistemas de archivos. df muestra el espacio libre en disco de uno o más sistemas de archivos. du muestra cuánto espacio en disco ocupa un directorio y los archivos que contiene. Estos pueden utilizarse para encontrar desperdiciadores de espacio en disco. Ambos tienen páginas de manual que detallan las (muchas) opciones que pueden utilizarse.

sync fuerza que todos los bloques en el buffer caché no escritos (vea la Sección 7.6“ El Buffer Cache”) se escriban al disco. Es raro hacer esto esto a mano; el demonio update hace esto automáticamente. Puede ser útil en caso de catástrofe, por ejemplo si update o su proceso ayudante bdflush muere, o si debe apagar el ordenador ahora y no puede esperar que se ejecute update. De nuevo, están las páginas de manual. El comando man es su mejor amigo en linux. Su sobrino apropos es también muy útil cuando no sabe cuál es el nombre del comando que quiere.

Además del creador (mke2fs) y del comprobador (e2fsck) de sistemas de archivos accesibles directamente o a través de las caretas independientes del tipo del sistema de archivos, ext2 posee herramientas adicionales que pueden resultar útiles.

tune2fs ajusta parámetros del sistema de archivos. Algunos de los parámetros más interesantes son:

Vea la página de manual de tune2fs para más información.

dumpe2fs muestra información acerca de un sistema de archivos ext2, la mayoría referente al superbloque. La Figura 6.6, “ Salida de ejemplo de dumpe2fs ” muestra una salida de ejemplo. Alguna información en la salida es técnica y requiere comprensión acerca de cómo trabaja el sistema de archivos (vea el apéndice XXX ext2fspaper), pero la mayoría es comprensible incluso para aprendices.

debugfs es un debugger para un sistema de archivos. Permite acceso directo al sistema de archivos y a las estructuras de datos almacenadas en el disco y puede utilizarse por tanto para reparar un disco tan estropeado que fsck no puede repararlo automáticamente. También es conocido por recuperar archivos eliminados. De cualquier modo, debugfs requiere mucho que comprenda lo que está haciendo: un fallo puede destruir todos sus datos.

dump y restore pueden utilizarse para guardar un sistema de archivos ext2. Hay versiones específicas para ext2 de las herramientas tradicionales de copias de seguridad UNIX. Vea el Capítulo 12 Capítulo 12, Copias de seguridad (Backups) para más información sobre copias de seguridad.