Particiones y sistemas de archivos

a. Introducción a los discos duros y a las particiones

Tipos de disco duro

En este capítulo, se explican los distintos pasos, desde la elección del disco duro hasta la organización de los datos, pasando por la partición, la elección de un sistema de archivos y el formateo.

Existen varias tecnologías de discos duros, algunas más orientadas a las empresas que otras:

Elección del disco duro

Los discos duros SCSI han reinado durante mucho tiempo en la empresa gracias a su rendimiento.

Por ejemplo, los discos SCSI giran a velocidades de entre 10 000 y 15 000 rpm, lo que reduce los tiempos de acceso y transferencia. Sin embargo, los discos duros SATA están ya muy consolidados en el mercado empresarial, a pesar de que sus velocidades de rotación son inferiores (de 7 200 a 10 000 rpm). Se necesitan comparar otros criterios además de la velocidad de rotación, como el precio, la velocidad de transferencia y el tipo de uso, que pueden adaptarse a sus necesidades. Además, las unidades SATA de clase empresarial son cada vez más fiables: su MTBF (Mean Time Between Failure, tiempo medio entre fallos) es cada vez mayor.

SAS ha resuelto este dilema. Esta tecnología es el resultado del deseo de los principales fabricantes de combinar las ventajas de SCSI y SATA. Se considera la sucesora de SCSI. Con SAS, obtendrá discos duros fiables y de alto rendimiento.

En resumen, SAS es la solución fiable y de alto rendimiento, que compite con SATA, que es menos cara....

a. ¿Qué es RAID?

RAID es el acrónimo de Redundant Array of Independent Disks (o matriz redundante de discos independientes), que intenta describir mejor la técnica de distribución de datos entre varios discos para aumentar la fiabilidad, la tolerancia a fallos o el rendimiento.

b. Niveles de RAID

RAID 0: volumen dividido

El objetivo del RAID 0 no es proporcionar fiabilidad, sino rendimiento. Esta configuración permite que varios discos trabajen en paralelo.

Los datos se distribuyen en bandas entre todos los discos. Esto permite acceder a varios datos al mismo tiempo, lo que reduce significativamente los tiempos de acceso.

Sin embargo, si uno de los discos falla, se pierde todo el volumen.

RAID 1: en espejo

Esta configuración está diseñada para proporcionar la máxima fiabilidad, escribiendo los mismos datos en dos o más discos al mismo tiempo. Los discos son réplicas unos de otros.

Dependiendo de la configuración, aunque fallen varios discos, los datos seguirán estando presentes y accesibles mientras haya un disco válido.

Por supuesto, el espacio disponible se reduce. Para un RAID 1 de dos discos, solo se utiliza el 50% del espacio total del disco.

Esta configuración no ofrece ninguna mejora de rendimiento.

RAID 5: distribuido con paridad

El RAID 5 pretende una solución intermedia entre el RAID 1 y una mayor eficiencia del espacio en disco, utilizando las matemáticas.

Esta tecnología utiliza la paridad para reconstruir los bloques de datos perdidos. Los bloques de datos y los de paridad se distribuyen entre todos los discos (3 como mínimo).

Si uno de los discos falla, los otros discos (que contienen los bloques de paridad y los demás bloques de datos) pueden utilizarse para reconstruir los datos que faltan.

El espacio total es, por tanto, más rentable que con el RAID 1, para una solución relativamente fiable. Por ejemplo, para un volumen RAID 5 con tres discos (es el mínimo), se puede utilizar el 66% del espacio total.

La desventaja de esta solución es el tiempo que se tarda en reconstruir los datos perdidos, que puede ser bastante largo, de hasta varias horas, una vez sustituida la unidad averiada. Esto puede ser un inconveniente si otra unidad falla al mismo tiempo.

Es más, RAID 5 puede ser una fuente de problemas...

a. Extended File System (Sistema de archivos extendido)

Extended File System, más comúnmente conocido como ext, fue el primer sistema de archivos creado específicamente para Linux. De hecho, los principales conceptos que aún se utilizan hoy en día se implementaron completamente en la versión 2 de ext (ext2), que es el antepasado de las versiones ext3 y ext4 utilizadas en los servidores Red Hat Enterprise Linux. Con el tiempo, aparecieron otros tipos de sistemas de archivos, como XFS, que también utiliza Red Hat.

Virtual File System (Sistema de archivos virtual)

La demanda de unificación de los tipos de sistemas de archivos llevó a la creación del Virtual File System, que es una capa intermedia entre los sistemas de archivos heterogéneos y la estructura de la arborescencia. Proporciona al usuario una visión unificada, aunque se utilicen diferentes sistemas de archivos. De este modo, permite generalizar conceptos específicos de los sistemas de archivos ext a sistemas de archivos que no los implementan, como NTFS. En este caso, VFS realiza una conversión.

Los conceptos específicos de Linux que vamos a explorar ahora se implementan físicamente en el sistema de archivos o virtualmente mediante VFS.

En el corazón de la familia de sistemas de archivos ext utilizada en Linux, se encuentra la noción de inodo, que es uno de los conceptos fundamentales que se debe comprender para entender la estructura de los sistemas de archivos Linux.

b. El superbloque

El superbloque (superbloc) contiene información general sobre el sistema de archivos. La información relevante incluye:

Como el superbloque contiene información vital para el sistema de archivos, se sitúa al principio del sistema de archivos y se repite a intervalos regulares.

c. Inodos

Los inodos son estructuras de datos, o «cajas», que almacenan los metadatos de los archivos. Sin embargo, no contienen los nombres de los archivos.

Cuando un usuario quiere acceder a un archivo, el sistema accede primero a su inodo y lee sus metadatos. Entre otras cosas, comprueba los permisos para determinar si el usuario tiene derecho a leer, modificar o ejecutar los datos.

En función de los permisos, el sistema también determina la dirección de los datos (su ubicación en el sistema de archivos). Por último, puede acceder a los datos propiamente dichos, que se encuentran en la dirección indicada en el disco duro.

Los directorios también son archivos referenciados por inodos. Listar su contenido significa, por tanto, seguir el mismo procedimiento: consultar el inodo del directorio y, a continuación, acceder a sus datos, que son de hecho la lista de archivos contenidos en el directorio con su correspondiente número de inodo.

d. Tabla de inodos

La tabla de inodos de un sistema de archivos contiene los inodos asignados al sistema de archivos.

En general, el número de inodos se define cuando se crea el sistema de archivos (excepto en ciertos casos, como con XFS), cuando formatea la partición. Dado que un archivo corresponde generalmente a un inodo, esto significa que el número de archivos es limitado en un sistema de archivos ext2/3/4.

Para conocer el número total de inodos de un sistema de archivos montado en la arborescencia, así como el número de inodos disponibles, utilice el comando:

df -i 

Por ejemplo:

[root@cobb ~]# df -i 
S.archivos     Nodos-i   Nusados  NLibres      NUso% Montado en 
/dev/sda1      1150560   96204    1054356      9%    / 

Podemos ver que para la partición /dev/sda1, se asignaron 1 150 560 inodos cuando se creó el sistema de archivos.

Para un sistema de archivos formateado, pero no montado aún, el comando tune2fs también proporciona el número total y disponible de inodos, así como otra información muy interesante (opción -l de list, listar):

tune2fs -l /dev/<partición> 

Por ejemplo, la partición /dev/sde1 no se ha montado aún:

[root@cobb ~]# tune2fs -l /dev/sde1 
tune2fs 1.41.12 (17-May-2010) 
Filesystem volume name:   <none> 
Last mounted on:          <not available> 
Filesystem UUID:          f390de17-7655-4990-b768-a5fba7b5e170 
Filesystem magic number:  0xEF53 
Filesystem revision #:    1 (dynamic) 
Filesystem features:      has_journal ext_attr resize_inode 
dir_index filetype sparse_super 
Filesystem flags:         signed_directory_hash 
Default mount options:   (none) 
Filesystem state:        clean 
Errors behavior:         Continue 
Filesystem OS type:      Linux  
Inode count:             28112 
Block count:             112420 
Reserved block count:    5621 
Free blocks:             103202  
Free inodes:             28101 
First block:             1 
Block size:              1024 
(...) 

Esta partición contiene un total de 28 112 inodos, 28 101 de los cuales están disponibles.

e. Tabla de bloques

La tabla de bloques contiene los bloques de datos de los archivos, es decir, el contenido real de los archivos.

También en este caso, el número de bloques disponibles se define cuando se crea el sistema de archivos (cuando se formatea la partición). Cada bloque tiene un tamaño fijo.

En el ejemplo anterior, podemos ver que la partición /dev/sde1 tiene un total de 112 420 bloques de datos. Cada bloque tiene un tamaño de 1 024 bytes. Cuando se formatea, algunos bloques de datos son utilizados por el sistema, dejando 103 202 bloques de datos que proporcionan alrededor de 105 678 KB de espacio disponible (103 202 bloques x 1 024 bytes/bloque), es decir, alrededor de 105 MB.

f. Ilustración de la estructura del sistema de archivos

Ilustremos cómo funciona el sistema de archivos ext trazando los diferentes pasos de acceso a un archivo.

Estructura del sistema de archivos

Cuando el usuario jdoe teclea el comando:

cat /home/jdoe/hola 

1. El sistema operativo comienza leyendo el número del primer inodo correspondiente a la raíz / en el superbloque. Aquí, el primer inodo tiene el número 11.

[root@cobb jdoe]# debugfs /dev/sda2 
debugfs:  stats 
Filesystem volume name:   <none> 
Last mounted on:          / 
(...)  
First inode:              11 

2. El sistema accede entonces al inodo 11, comprueba los permisos de acceso para este directorio y busca la dirección del bloque de datos, aquí: 9217

debugfs:  show_inode_info / 
Inode: 2   Type: directory    Mode:  0555   Flags: 0x0 
(...) 
BLOCKS: 
(0):9217 

3. El sistema abre el bloque de datos 9217 que contiene las listas de directorios y archivos contenidos en /. Encuentra una coincidencia entre los nombres y los números de inodo:

783361 dev      261121 proc         391681 sys 
913921 var      652801 tmp          652803 etc 
783362 root     130562 selinux      391685 srv 
130618 misc     261122 usr          391682 bin  
130563 home     783365 lib          391683 media 
130564 mnt      391684 opt          130565 sbin 

4. El sistema accede al inodo 130563 correspondiente al directorio /home, comprueba los permisos de acceso a este directorio y busca la dirección del bloque de datos: 532482.

debugfs:  show_inode_info /home 
Inode: 130563   Type: directory    Mode:  0755   Flags: 0x80000 
(...) 
BLOCKS: 
(0): 532482 

5. El sistema abre el bloque de datos 532482 que contiene las listas de directorios y archivos contenidos en /home. Encuentra la correspondencia entre el nombre jdoe y su número de inodo:

debugfs:  ls /home 
130563 .        2      ..           130831 jdoe 
130996 michel   130994 admin        131009 ITprojets 

6. El sistema accede al inodo 130831 correspondiente al directorio jdoe, comprueba los permisos de acceso a este directorio y busca la dirección del bloque de datos: 532492.

debugfs:  show_inode_info /home/jdoe 
Inode: 130831   Type: directory    Mode:  0700   Flags: 0x80000 
(...) 
BLOCKS: 
(0): 532492 

7. El sistema abre el bloque de datos 532492 que contiene las listas de directorios y archivos contenidos en jdoe. Encuentra una correspondencia entre los nombres y los números de inodos:

debugfs:  ls /home/jdoe 
130831 .        130563 ..        130832 .bashrc 
(...) 130826 hola 

8. El sistema accede al inodo 130826 correspondiente al archivo hola, comprueba los permisos de acceso a este archivo y busca la dirección del bloque de datos. Los permisos son los siguientes: el usuario propietario tiene UID 500, el grupo propietario tiene GID 500 y los derechos de acceso son 0664. Los datos de este archivo se almacenan en el bloque 3707450.

debugfs:  show_inode_info /home/jdoe/hola 
Inode: 130826   Type: regular    Mode:  0664   Flags: 0x80000 
Generation: 4191462316    Version: 0x00000000:00000001 
User:   500   Group:   500   Size: 19 
(...) 
BLOCKS: 
(0): 3707450 

9. Finalmente, como el sistema se da cuenta de que el tipo de archivo es regular, accede a los datos del bloque 3707450 y los pasa al comando cat, que muestra su contenido:

[jdoe@cobb ~]$ cat /home/jdoe/hola 
¡Hola, amigos! 

g. Vínculos simbólicos y físicos

Hemos optado por explicar aquí los vínculos, ya que utilizan conceptos directamente relacionados con la estructura del sistema de archivos.

Los vínculos (también llamados enlaces) son archivos utilizados como accesos directos a otros archivos (o directorios).

Existen dos tipos de vínculos: físicos y simbólicos.

Vínculos simbólicos

Los vínculos simbólicos (o symlinks) son los más sencillos de entender. Son entradas en directorios, como los archivos regulares. Sin embargo, a diferencia de los archivos regulares, en lugar de apuntar a un número de inodo, un vínculo simbólico apunta al nombre de otro archivo. Se puede pensar en ellos como alias de archivos, no muy diferentes de los accesos directos utilizados en Windows.

Diagrama explicativo del vínculo simbólico

Por ejemplo, en /etc/rc5.d/, encontramos vínculos simbólicos:

[root@cobb rc5.d]# ls -l 
lrwxrwxrwx. 1 root root K01certmonger -> ../init.d/certmonger 
lrwxrwxrwx. 1 root root K01smartd -> ../init.d/smartd 
lrwxrwxrwx. 1 root root K02oddjobd -> ../init.d/oddjobd 
lrwxrwxrwx. 1 root root K10psacct -> ../init.d/psacct 

Aquí vemos que el archivo K01smartd apunta al archivo normal smartd en el directorio init.d.

Así, cuando se llama a /etc/rc5.d/K01smartd, se abre /etc/init.d/smartd.

Lo que necesita saber sobre los vínculos simbólicos

Vínculos físicos

Los vínculos físicos (hardlinks) aputan a los datos físicos de otro archivo. En concreto, un enlace físico apunta al mismo inodo que el archivo original.

Diagrama explicativo del vínculo físico

Sabemos por las explicaciones anteriores que un archivo se compone de tres elementos:

Cuando crea un vínculo físico, en realidad está creando una nueva entrada en un directorio, apuntando al mismo inodo. Así que cualquier archivo normal es en sí mismo un vínculo físico. Otro enlace físico se encuentra en el mismo nivel que el primer vínculo físico.

Lo que necesita saber sobre los vínculos físicos

Por ejemplo, el comando ls -il muestra los detalles de los archivos con su número de inodo (opción -i).

[root@cobb ~]# ls -il  
799111 -rw-r--r--. 2 root root    19 12 ene 12:54 archivo  
799111 -rw-r--r--. 2 root root    19 12 ene 12:54 mismoarchivo 

Los dos archivos tienen el mismo número de inodo (799111). Son vínculos físicos, que apuntan a los mismos datos (concretamente, al mismo inodo).

Observe el número 2 para cada nombre de archivo, en la tercera columna. Este es el número de enlaces físicos de un archivo.

Eliminemos uno de los vínculos físicos y volvamos a observar esta cifra: ha disminuido a 1.

[root@cobb ~]# rm -f archivo 
[root@cobb ~]# ls -il 
799111 -rw-r--r--. 1 root 19 12 ene 12:54 mismoarchivo 

Diferencia entre vínculos simbólicos y físicos

La diferencia entre un vínculo simbólico y uno físico radica principalmente en que un vínculo simbólico depende del archivo al que apunta.

Si ya no existe, el vínculo simbólico está roto e inutilizable.

El vínculo físico no depende del archivo al que se apunta. De hecho, está al mismo nivel que el archivo original: accede directamente a los datos. De hecho, cada archivo es un enlace físico, que accede a los datos.

En el caso en que dos vínculos físicos hagan referencia a los mismos datos, si el primero de ellos, el «primer» archivo, desaparece, el segundo enlace físico sigue accediendo a los datos.

Creación de vínculos físicos o simbólicos

Para crear un vínculo (simbólico o físico), utilice el comando ln.

Vínculo físico:

ln <archivo_original> <nuevo_archivo> 

Vínculo simbólico (opción -s):

ln -s <archivo_apuntado> <nuevo_archivo> 

En el caso de un vínculo simbólico, tenga en cuenta los siguientes puntos a la hora de especificar la ruta (relativa o absoluta) del archivo al que se apunta:

Los vínculos simbólicos no siempre son fáciles de manejar. Experimente para familiarizarse con el concepto.

Copy-on-Write o almacenamiento optimizado (XFS)

Copy-on-Write (COW o CoW copiar al escribir) optimiza la forma en que se almacenan los datos redundantes en el sistema de archivos. Cuando dos archivos comparten datos, en lugar de escribirlos dos veces, es posible compartirlos. Los archivos acceden entonces a los mismos bloques de datos, que solo se escriben una vez.

Copy-on-Write: dos archivos comparten los mismos bloques de datos

Solo cuando se añaden datos a uno de los dos archivos comienza a consumirse espacio en disco. Los bloques de datos comunes siguen compartiéndose siempre que sea posible.

Copy-on-Write: añadir datos a uno de los dos archivos

El COW tiene las tres siguientes ventajas:

La función COW solo está disponible en el sistema de archivos XFS (y BTRFS, descontinuado a partir de RHEL 8), donde se denomina reflink.

Por defecto, COW no se utiliza al copiar archivos.

Para realizar una copia de archivo con COW, utilice la opción --reflink:

cp --reflink <fuente> <destino> 

En nuestro ejemplo, tenemos un archivo de 2 GB llamado test2G (que contiene datos aleatorios generados con el comando dd):

[root@scott democow]# dd if=/dev/urandom of=test2G bs=1M count=2048 
2048+0 registros leídos 
2048+0 registros escritos 
2147483648 bytes (2,1 GB, 2,0 GiB) copiados, 98,0044 s, 21,9 MB/s 
[root@scott democow]# ls -lh 
total 4,0G 
-rw-r--r--. 1 root root 2,0G  17 sep 05:13 test2G 
[root@scott democow]# df -hP / 
S.archivos             Tamaño  Usados   Disp  Uso%  Montado en 
/dev/mapper/rhel-root     17G    6,0G  11,1G   47%  / 

Hagamos una copia clásica del archivo test2G a test2G_cp_classique (cronometrada con el comando time). Vemos que la copia lleva cierto tiempo: se necesitan 58 segundos para duplicar los bloques de datos en este nuevo archivo, que ahora ocupa 2 GB más de espacio en disco (comando df):

[root@scott democow]# time cp test2G test2G_cp_clasico 
 
real    0m58,731s 
user    0m0,020s 
sys     0m7,293s 
[root@scott democow]# ls -lh 
total 4,0G 
-rw-r--r--. 1 root root 2,0G  17 sep 05:13 test2G 
-rw-r--r--. 1 root root 2,0G  17 sep 05:15 test2G_cp_clasico 
[root@scott democow]# df -hP / 
S.archivos              Tamaño   Usados    Disp   Uso%   Montado en 
/dev/mapper/rhel-root      17G     8,0G    9,1G    47%   / 

Hagamos ahora una copia COW utilizando la opción --reflink, a un nuevo archivo llamado test2G_cp_reflink_CoW. ¿Cuánto tarda la copia? Podemos ver que es casi instantánea:

[root@scott democow]# time cp --reflink test2G test2G_cp_reflink_CoW 
 
real    0m0,006s 
user    0m0,001s 
sys     0m0,004s 
 
 
[root@scott democow]# ls -lh 
total 6,0G 
-rw-r--r--. 1 root root 2,0G  17 sep 05:13 test2G 
-rw-r--r--. 1 root root 2,0G  17 sep 05:15 test2G_cp_classique 
-rw-r--r--. 1 root root 2,0G  17 sep 05:17 test2G_cp_reflink_CoW 

También podemos ver que esta copia en COW no utiliza ningún espacio extra en disco; el espacio utilizado es el mismo que antes de la copia:

[root@scott democow]# df -hP / 
S.archivos              Tamaño   Usados    Disp   Uso%   Montado en 
/dev/mapper/rhel-root      17G     8,0G    9,1G    47%   / 

¿Cómo se hace esto? El comando xfs_bmap nos permite ver las direcciones de los bloques de datos utilizados por los archivos:

[root@scott democow]# xfs_bmap -v test2G test2G_cp_reflink_CoW 
test2G_cp_classique  
test2G: 
EXT: FILE-OFFSET      BLOCK-RANGE        AG AG-OFFSET            TOTAL 
  0: [0..4194303]:    20562136..24756439  3 (1687768..5882071) 4194304 
100000  
test2G_cp_reflink_CoW: 
EXT: FILE-OFFSET      BLOCK-RANGE        AG AG-OFFSET            TOTAL 
  0: [0..4194303]:    20562136..24756439  3 (1687768..5882071) 4194304 
100000  
test2G_cp_classique: 
EXT: FILE-OFFSET         BLOCK-RANGE        AG AG-OFFSET        TOTAL 
  0: [0..130943]:       24756440..24887383  3 (5882072..6013015) 
130944 
  1: [130944..2097023]:  2775224..4741303    0 (2775224..4741303) 
1966080 
  2: [2097024..4194303]: 7997128..10094407   1 (1705672..3802951) 
2097280 

Podemos ver aquí que el archivo copiado en COW utiliza exactamente los mismos bloques de datos que el archivo original, lo que no ocurre con el archivo copiado de forma convencional, que utiliza sus propios bloques.

h. Fragmentación

La gestión de la fragmentación en los sistemas de archivos ext es bastante elegante. En lugar de colocarlos de extremo a extremo en un intento de «apretarlos al principio» como ocurre con otros sistemas de archivos, ext reparte los archivos por toda la partición.

Los archivos están «aireados», con espacio entre ellos. De este modo, un archivo puede crecer libremente ocupando los siguientes bloques de datos libres. Esto limita enormemente la fragmentación, siempre que su sistema de archivos tenga una tasa de ocupación bastante baja: hay que mantener espacio entre los archivos.

i. Descriptores de archivos (File...

a. Conocer el tipo de sistema de archivos de una partición

Para montar una partición, necesita...