Discos y arranque

Un sistema de ficheros es la forma de organizar los bloques de un dispositivo para que existan carpetas, nombres, tamaños y fechas. No todos guardan lo mismo, y esa es la diferencia que se pregunta: los sencillos son universales pero no saben nada de seguridad, y los completos guardan permisos, cuotas y registro de transacciones.

Conviene deshacer dos ideas equivocadas que circulan. ReFS no es un NTFS recortado, sino un sistema distinto orientado a integridad y a volúmenes muy grandes que, a cambio, renuncia a algunas funciones de NTFS. Y HPFS no es una opción actual: era el sistema de ficheros de OS/2 y las versiones modernas de Windows no lo admiten.

FAT no guarda permisos. Esa es la razón por la que un pendrive formateado en FAT deja leer cualquier fichero en cualquier equipo.

En un sistema de ficheros de la familia Unix, el nombre de un fichero y el fichero en sí están separados. Los metadatos, es decir el tamaño, el propietario, el grupo, los permisos y las fechas, viven en una estructura llamada i-nodo, y el i-nodo se identifica por un número, no por un nombre.

El nombre está en el directorio. Un directorio no es más que un fichero cuyo contenido es una tabla de entradas, y cada entrada, la estructura interna que se llama dirent, empareja un nombre con el número de i-nodo al que corresponde. Cuando se abre un fichero por su ruta, el sistema recorre esa tabla hasta encontrar el nombre, se queda con el número de i-nodo y a partir de ahí trabaja con él.

El nombre vive en el directorio; los permisos y los metadatos viven en el i-nodo. Un directorio es una tabla de nombres y números de i-nodo.

Windows da una letra a cada volumen y cada letra tiene su propio árbol. Linux hace lo contrario: hay un único árbol que empieza en la raíz, y cualquier disco, partición o recurso de red se incorpora colgándolo de un directorio. El estándar que fija qué va en cada sitio es el Filesystem Hierarchy Standard, y saberlo evita buscar a ciegas en una máquina desconocida.

Dos aclaraciones que se preguntan. /proc no existe en el disco: se construye en memoria cada vez que arranca la máquina y es la ventana desde la que se consulta el estado del núcleo. Y /media y /mnt no son sinónimos, aunque los dos sean puntos de montaje.

/media es para lo que se monta solo, como un pendrive. /mnt es para lo que monta el administrador a mano.

Un disco recién conectado no sirve de nada tal cual. Hacen falta tres pasos, y siempre en este orden, porque cada uno necesita que el anterior esté hecho.

1. 1Particionar: dividir el disco en trozos. fdisk trabaja con tablas de particiones MBR y gdisk con GPT.
2. 2Formatear: crear el sistema de ficheros dentro de la partición, con mkfs y el tipo que se quiera.
3. 3Montar: colgar esa partición ya formateada de un directorio del árbol, con mount, para poder acceder a ella.

fdisk /dev/sdb              # crear la partición
mkfs -t ext4 /dev/sdb1      # crear el sistema de ficheros
mkdir /datos
mount /dev/sdb1 /datos      # dejarlo accesible en /datos

Particionar, formatear y montar. Saltarse el orden o confundir fdisk con mkfs es el fallo típico de esta pregunta.

Al pulsar el botón de encendido no hay todavía sistema operativo: lo que se ejecuta es el firmware de la placa, que comprueba el hardware y busca desde dónde arrancar. Ese firmware tiene dos generaciones, y cada una va emparejada con un formato de tabla de particiones.

Los cuatro de MBR son cuatro particiones primarias. Si hacen falta más, una de ellas se convierte en extendida y dentro de ella se crean particiones lógicas, así que en la práctica el reparto es de tres primarias más una extendida. MBR arrastra además otro límite que fue el que lo condenó: no direcciona discos de más de 2 TiB.

De GPT se dice a veces que admite particiones infinitas pero limitadas a 128. Conviene precisarlo: la especificación no fija un máximo, y el 128 sale del tamaño de tabla que reservan las implementaciones habituales, que es de 128 entradas.

El firmware moderno es UEFI y su tabla de particiones es GPT. El clásico es BIOS con MBR y cuatro particiones primarias.

El recorrido desde el encendido hasta que el núcleo toma el mando tiene dos variantes, según la generación de firmware. Son dos secuencias cortas y es muy habitual que se pregunten tal cual.

• Con firmware clásico: BIOS, MBR, gestor de arranque (LILO o GRUB) y sector de arranque.
• Con firmware moderno: UEFI, GPT, GRUB y carga del núcleo.

Hay un matiz que conviene tener claro, porque el esquema abreviado induce a error. Con UEFI ya no hay sector de arranque: el firmware sabe leer un sistema de ficheros y busca una partición especial, la partición de sistema EFI, formateada en FAT32, de la que carga directamente un ejecutable con extensión .efi. El sector de arranque, esos primeros bytes del disco donde cabe muy poco código, es cosa exclusiva de BIOS y MBR.

BIOS lee un sector de arranque; UEFI lee un fichero .efi de la partición EFI. Es la diferencia de fondo entre las dos cadenas.

Windows cambió su gestor de arranque hace ya varias versiones y el examen sigue preguntando la pareja antiguo y actual. El sistema clásico lo llevaba NTLDR, que leía la configuración de un fichero de texto llamado boot.ini. El actual lo lleva bootmgr, y la configuración ya no es un fichero de texto sino un almacén binario, el BCD.

La distinción entre winload.exe y winresume.exe es la que más se pregunta: el primero carga el sistema desde cero y el segundo no carga nada, restaura la imagen de memoria que se guardó al hibernar.

bootmgr lee el BCD. Después toma el relevo winload.exe en un arranque normal, o winresume.exe cuando se vuelve de la hibernación.