Uso del Comando `mkfs` en Linux: Una Guía Completa para Formatear Discos y Particiones

El comando `mkfs` (make filesystem) es la utilidad principal de Linux para escribir una estructura de sistema de archivos en un dispositivo de bloque, ya sea un disco sin procesar, una partición o un volumen lógico. Inicializa el superbloque, las tablas de inodos, los grupos de bloques y las estructuras de journal necesarias antes de que se pueda escribir cualquier dato en ese dispositivo.

Antes de tocar cualquier disco, comprenda esto: `mkfs` es una operación destructiva e irreversible. No simplemente borra una entrada de tabla de particiones: sobrescribe metadatos críticos en disco. Ejecutarlo contra el dispositivo equivocado, aunque sea brevemente, hace que los datos existentes sean irrecuperables sin herramientas forenses. Verifique su dispositivo de destino con `lsblk` o `blkid` antes de cada invocación.

Lo que `mkfs` hace realmente bajo el capó

Cuando ejecuta `mkfs -t ext4 /dev/sdb1`, el kernel no simplemente “formatea” la partición en el sentido de Windows. El comando llama al binario específico del sistema de archivos correspondiente (en este caso `mkfs.ext4`, que en realidad es `mke2fs` con valores predeterminados de ext4) y realiza lo siguiente:

• Escribe el superbloque y copias de superbloque de respaldo en desplazamientos fijos de grupos de bloques
• Asigna e inicializa la tabla de inodos en todos los grupos de bloques
• Crea la tabla de descriptores de grupos de bloques
• Inicializa el journal (para sistemas de archivos con journaling como ext4 y XFS)
• Escribe el inodo del directorio raíz (inodo 2 para ext4)
• Estampa un UUID en el sistema de archivos para identificación persistente

Esta distinción importa en discos grandes. Formatear una partición ext4 de 4 TB con inicialización completa de la tabla de inodos puede tardar varios minutos. XFS, por el contrario, difiere la mayor parte de este trabajo al tiempo de ejecución, haciendo que su `mkfs.xfs` sea casi instantáneo independientemente del tamaño del volumen.

Identificar el dispositivo correcto antes de formatear

Nunca adivine un nombre de dispositivo. Use las siguientes herramientas para mapear el hardware físico a los nodos de dispositivo del kernel.

Usando `lsblk`

“`bash

lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINT

“`

Salida de ejemplo:

“`

NAME SIZE FSTYPE LABEL UUID MOUNTPOINT

sda 100G

├─sda1 20G ext4 a1b2c3d4-… /

└─sda2 80G ext4 e5f6a7b8-… /home

sdb 500G

└─sdb1 500G

“`

Un campo `FSTYPE` vacío confirma que `/dev/sdb1` no tiene un sistema de archivos existente: es seguro formatearlo.

Usando `blkid`

“`bash

sudo blkid /dev/sdb1

“`

Si el comando no devuelve ninguna salida, la partición no tiene ninguna firma de sistema de archivos reconocida. Si devuelve un tipo, está a punto de sobrescribir datos existentes.

Usando `fdisk -l`

“`bash

sudo fdisk -l /dev/sdb

“`

Esto revela los límites de las particiones, los tipos de particiones y si el disco usa MBR o GPT. Si `/dev/sdb` no muestra ninguna tabla de particiones, es posible que necesite particionarlo primero con `fdisk`, `gdisk` o `parted` antes de ejecutar `mkfs`.

Sintaxis principal de `mkfs` y patrones de invocación

La sintaxis canónica es:

“`bash

mkfs -t <filesystem_type> [options] <device>

“`

Sin embargo, `mkfs` en sí mismo es un envoltorio ligero. Cada tipo de sistema de archivos incluye su propio binario dedicado:

Llamar a `mkfs -t ext4` y llamar a `mkfs.ext4` directamente son funcionalmente idénticos: el primero simplemente se resuelve al segundo. En scripts de producción, prefiera el alias explícito (`mkfs.ext4`) para que la intención sea inequívoca.

Selección del tipo de sistema de archivos: comparación técnica

Elegir el sistema de archivos incorrecto para una carga de trabajo es un error común y costoso. La siguiente tabla mapea las características del sistema de archivos a casos de uso del mundo real.

Caso límite crítico: la Partición del Sistema EFI: La ESP debe formatearse como `vfat` (específicamente FAT32). Usar cualquier otro sistema de archivos aquí impedirá que el firmware UEFI localice el cargador de arranque. Siempre formatee la ESP con:

“`bash

sudo mkfs.vfat -F 32 /dev/sda1

“`

El indicador `-F 32` fuerza explícitamente FAT32 en lugar de FAT16, lo que importa para particiones ESP de más de 32 MiB.

Ejemplos prácticos de `mkfs` con opciones de nivel de producción

Ejemplo 1: Crear un sistema de archivos ext4 con parámetros ajustados

“`bash

sudo mkfs.ext4 -L "data_vol" -m 1 -E lazy_itable_init=0,lazy_journal_init=0 /dev/sdb1

“`

Lo que hace cada indicador:

• `-L "data_vol"` — asigna una etiqueta persistente, permitiendo que las entradas de `/etc/fstab` usen `LABEL=data_vol` en lugar de una ruta de dispositivo sin procesar (más seguro en sistemas donde el orden de enumeración de dispositivos puede cambiar)
• `-m 1` — reduce el porcentaje de bloques reservados del 5% predeterminado al 1%; en un volumen de datos de 2 TB, el valor predeterminado desperdicia ~100 GB que solo puede usar root
• `-E lazy_itable_init=0,lazy_journal_init=0` — fuerza la inicialización completa de la tabla de inodos en el momento del formateo en lugar de diferirla a E/S en segundo plano; crítico para servidores de producción donde la inicialización en segundo plano puede causar picos de E/S inesperados horas después de la implementación

Ejemplo 2: Crear un sistema de archivos XFS para un servidor de base de datos

“`bash

sudo mkfs.xfs -L "pg_data" -f /dev/sdb1

“`

• `-f` — fuerza la creación incluso si se detecta una firma de sistema de archivos existente; úselo solo cuando haya confirmado que el dispositivo es prescindible
• XFS no admite reducción; planifique cuidadosamente el tamaño de su volumen antes de formatear

Para cargas de trabajo de PostgreSQL o MySQL en XFS, también establezca la opción de montaje `noatime` en `/etc/fstab` para eliminar la sobrecarga de escritura de tiempo de acceso a inodos en cada operación de lectura.

Ejemplo 3: Crear un sistema de archivos Btrfs con RAID-1 en dos dispositivos

“`bash

sudo mkfs.btrfs -L "btrfs_mirror" -d raid1 -m raid1 /dev/sdb /dev/sdc

“`

Btrfs puede abarcar múltiples dispositivos de bloque de forma nativa. `-d raid1` refleja datos; `-m raid1` refleja metadatos. Esta es una alternativa legítima al RAID por software mdadm para entornos donde también se necesita funcionalidad de snapshot y subvolumen.

Ejemplo 4: Crear un sistema de archivos vFAT para una unidad USB

“`bash

sudo mkfs.vfat -F 32 -n "BACKUP_USB" /dev/sdc1

“`

• `-n "BACKUP_USB"` — establece la etiqueta del volumen (las etiquetas FAT32 están limitadas a 11 caracteres, en mayúsculas)
• `-F 32` — selecciona explícitamente FAT32 sobre FAT16

Ejemplo 5: Crear un sistema de archivos F2FS en un SSD

“`bash

sudo mkfs.f2fs -l "ssd_cache" /dev/sdb1

“`

F2FS está diseñado específicamente para almacenamiento flash NAND. Reduce la amplificación de escritura y gestiona el nivelado de desgaste a nivel del sistema de archivos. En instancias de Hosting VPS respaldadas por almacenamiento NVMe, F2FS puede superar a ext4 para volúmenes de caché efímeros con alta rotación de escritura.

Formatear un disco completo sin tabla de particiones

En escenarios específicos —volúmenes físicos LVM, OSDs de Ceph o dispositivos de almacenamiento de propósito único— puede escribir un sistema de archivos directamente en un disco completo en lugar de en una partición:

“`bash

sudo mkfs.ext4 /dev/sdb

“`

Cuándo es apropiado:

• El disco está dedicado a un único propósito y no se necesita flexibilidad de particiones
• Está preparando un disco para LVM (`pvcreate` maneja esto de manera diferente, pero el concepto es similar)
• Está creando una imagen de sistema de archivos loopback

Cuándo no es apropiado:

• Cualquier disco que necesite arrancar (requiere una tabla de particiones con un indicador de arranque)
• Cualquier disco compartido entre múltiples sistemas de archivos o sistemas operativos
• Discos en sistemas donde las reglas udev o las herramientas de infraestructura en la nube esperan una tabla de particiones

Montar la partición formateada y hacerla persistente

Formatear crea el sistema de archivos; montarlo lo hace accesible. Siempre use referencias basadas en UUID en `/etc/fstab` en lugar de nombres de dispositivo, porque los nombres de dispositivo (`/dev/sdb1`) no están garantizados como estables entre reinicios en sistemas con múltiples discos o almacenamiento de conexión en caliente.

“`bash

Create the mount point

sudo mkdir -p /mnt/data_vol

Mount temporarily to verify

sudo mount /dev/sdb1 /mnt/data_vol

Retrieve the UUID

sudo blkid /dev/sdb1

Output: /dev/sdb1: LABEL="data_vol" UUID="a1b2c3d4-e5f6-7890-abcd-ef1234567890" TYPE="ext4"

Add a persistent, UUID-based fstab entry

echo 'UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890 /mnt/data_vol ext4 defaults,noatime 0 2' | sudo tee -a /etc/fstab

Validate the fstab entry without rebooting

sudo mount -a

“`

Los `0 2` al final de la entrada de fstab controlan `dump` (utilidad de respaldo, establecer en 0 para deshabilitar) y el orden de paso de `fsck` (2 significa verificar después del sistema de archivos raíz; root debe ser 1).

Verificar la integridad del sistema de archivos después de formatear

No asuma que un formateo fue exitoso sin verificación.

“`bash

Check filesystem type, label, and UUID

lsblk -f /dev/sdb1

For ext4: run e2fsck in read-only check mode

sudo e2fsck -n /dev/sdb1

For XFS: verify the filesystem structure

sudo xfs_repair -n /dev/sdb1

Check available space after mounting

df -hT /mnt/data_vol

“`

El indicador `-n` tanto en `e2fsck` como en `xfs_repair` realiza una verificación en seco sin modificar el sistema de archivos. Es seguro ejecutarlo en un sistema de archivos montado con fines de diagnóstico, aunque una reparación completa requiere desmontarlo primero.

Referencia de opciones avanzadas

Errores comunes y cómo evitarlos

Formatear un sistema de archivos montado: Linux no siempre lo impedirá. Ejecutar `mkfs` en una partición montada corrompe el sistema de archivos inmediatamente y puede causar pánico del kernel. Siempre verifique el estado de montaje con `mount | grep /dev/sdb1` antes de continuar.

Agotamiento de inodos en ext4: Si establece un tamaño de bloque grande (p. ej., 4096 bytes) en un volumen que almacenará millones de archivos diminutos (colas de correo, cachés de sesión), agotará los inodos mucho antes que el espacio en disco. Use `-i 4096` o `-i 2048` para aumentar la densidad de inodos. Este es un problema particularmente común en servidores de Hosting de Correo Electrónico y servidores web de alto tráfico que almacenan archivos por sesión.

XFS y la reducción: Los volúmenes XFS no pueden reducirse después de su creación. Si formatea un volumen XFS de 2 TB y luego necesita recuperar espacio, su única opción es hacer una copia de seguridad, reformatear y restaurar. Planifique los tamaños de volumen XFS de forma conservadora o use el aprovisionamiento delgado de LVM por debajo.

Alineación de franjas para RAID y SSD: Formatear sin especificar la alineación de franjas en una matriz RAID o SSD causa E/S desalineada, degradando significativamente el rendimiento. Para una matriz RAID-5 con una franja de 512 KB y 4 discos:

“`bash

sudo mkfs.ext4 -E stride=128,stripe-width=384 /dev/md0

“`

Donde `stride = stripe_size / block_size` y `stripe-width = stride * (data_disks)`.

Colisiones de UUID después de clonar discos: Clonar un disco con `dd` duplica el UUID del sistema de archivos. Dos dispositivos con UUID idénticos causan fallos de montaje y corrupción de datos. Después de clonar, regenere el UUID:

“`bash

sudo tune2fs -U random /dev/sdb1 # ext4

sudo xfs_admin -U generate /dev/sdb1 # XFS

“`

Esta es una consideración crítica al implementar Servidores Dedicados desde imágenes de disco o aprovisionar múltiples nodos desde una única plantilla.

Consideraciones del sistema de archivos para entornos VPS y en la nube

En máquinas virtuales e instancias en la nube, el almacenamiento subyacente suele ser un disco virtual de aprovisionamiento delgado respaldado por un sistema de almacenamiento distribuido. Varias decisiones de `mkfs` se vuelven más impactantes en este contexto:

• Soporte de Discard/TRIM: Formatee ext4 con `-E discard` o agregue la opción de montaje `discard` para habilitar TRIM en línea, que devuelve los bloques liberados al grupo de almacenamiento subyacente y mantiene el rendimiento a lo largo del tiempo en instancias de VPS con cPanel respaldadas por SSD.
• Modo de journal: Para aplicaciones sensibles a la latencia, considere el modo de journal `data=writeback` en `/etc/fstab` para ext4. Esto intercambia el orden estricto de datos por menor latencia de escritura, aceptable para bases de datos que gestionan sus propios registros de escritura anticipada.
• Evite formatear swap como sistema de archivos: Las particiones swap usan `mkswap`, no `mkfs`. Ejecutar `mkfs` en una partición swap destruye la firma de swap sin crear un sistema de archivos utilizable.

Al gestionar almacenamiento en Paneles de Control VPS, los volúmenes de disco adicionales suelen aparecer como dispositivos de bloque sin formatear. El flujo de trabajo es siempre: identificar con `lsblk`, particionar si es necesario con `fdisk`/`gdisk`, formatear con `mkfs`, montar y persistir en `/etc/fstab`.

Matriz de decisión: elegir el sistema de archivos correcto

Use esta matriz para seleccionar un sistema de archivos según su restricción principal:

Lista de verificación técnica de puntos clave

Antes de ejecutar `mkfs` en cualquier entorno, trabaje con esta lista de verificación:

• Confirme el dispositivo de destino con `lsblk -f` y `blkid` — nunca confíe en la memoria o suposiciones
• Desmonte el destino con `umount /dev/sdXN` y verifique con `mount | grep sdX`
• Haga una copia de seguridad de cualquier dato en el dispositivo; `mkfs` no es reversible
• Seleccione el tipo de sistema de archivos según la carga de trabajo (consulte la matriz de decisión anterior), no por hábito
• Establezca una etiqueta de sistema de archivos con `-L` para identificación legible por humanos en registros y `fstab`
• Reduzca los bloques reservados en volúmenes de datos grandes (`-m 1` para ext4) para recuperar espacio utilizable
• Deshabilite la inicialización diferida (`-E lazy_itable_init=0`) en servidores de producción para prevenir picos de E/S después de la implementación
• Use UUID en `/etc/fstab`, no nombres de dispositivo, para persistencia de montaje
• Valide con `mount -a` después de editar `/etc/fstab` para detectar errores antes de reiniciar
• Ejecute `e2fsck -n` o `xfs_repair -n` después de formatear para confirmar la integridad del sistema de archivos
• Regenere los UUID en cualquier disco clonado desde una imagen de plantilla

Preguntas frecuentes

P: ¿Puedo ejecutar `mkfs` en una partición que está actualmente montada?

R: Técnicamente el kernel puede permitirlo, pero hacerlo corrompe inmediatamente el sistema de archivos y puede desencadenar pánico del kernel o pérdida de datos. Siempre desmonte la partición primero y confirme con `mount | grep <device>` antes de ejecutar `mkfs`.

P: ¿Cuál es la diferencia entre `mkfs.ext4` y `mke2fs`?

R: `mkfs.ext4` es un enlace simbólico o envoltorio que llama a `mke2fs` con valores predeterminados de `-t ext4`. Son funcionalmente idénticos. `mke2fs` es la herramienta canónica y acepta la gama completa de opciones de creación de ext2/ext3/ext4.

P: ¿Por qué formatear una partición ext4 grande tarda tanto en comparación con XFS?

R: ext4 inicializa la tabla de inodos para cada grupo de bloques en el momento del formateo (a menos que se establezca `lazy_itable_init=1`). En un volumen de 4 TB, esto implica escribir gigabytes de datos de tabla de inodos puestos a cero. XFS difiere la inicialización de estructuras al tiempo de ejecución, haciendo que `mkfs.xfs` se complete en segundos independientemente del tamaño del volumen.

P: ¿Cómo cambio una etiqueta de sistema de archivos después de formatear sin reformatear?

R: Para ext4, use `sudo tune2fs -L "NewLabel" /dev/sdb1`. Para XFS, use `sudo xfs_admin -L "NewLabel" /dev/sdb1`. Para FAT32, use `sudo fatlabel /dev/sdb1 NEWLABEL`. El reetiquetado no afecta ningún dato.

P: ¿Es seguro usar `mkfs` en un volumen lógico LVM?

R: Sí. Los volúmenes lógicos LVM aparecen como dispositivos de bloque (p. ej., `/dev/mapper/vg0-lv_data` o `/dev/vg0/lv_data`) y son tratados de manera idéntica a las particiones físicas por `mkfs`. Este es el flujo de trabajo estándar para almacenamiento Linux en producción: crear el LV con `lvcreate`, formatear con `mkfs`, montar y persistir en `/etc/fstab`.