Análisis de Journaling (Registros)

En esta práctica del módulo de Sistemas Operativos Monopuesto, profundizaremos en el funcionamiento de los sistemas de registro o Journaling en sistemas de archivos avanzados. Investigaremos cómo actúan el USN Journal (Update Sequence Number) de NTFS en Windows y el Journal de ext4 en GNU/Linux ante un apagón o corte abrupto de corriente eléctrica, y de qué forma aceleran los procesos de recuperación e integridad.

Objetivo:

Analizar mediante herramientas de consola la actividad y configuración de los registros transaccionales (journaling) en ambos sistemas operativos, comprendiendo cómo evitan la corrupción masiva de datos tras un fallo eléctrico.

Escenario:

  • Un equipo con sistema operativo Windows o GNU/Linux.
  • Acceso a la consola de comandos con privilegios de administrador o superusuario (sudo).

Instrucciones:

Opción A: Entorno Windows (Consulta del USN Journal de NTFS)

  1. Consulta del estado del diario de actualización (USN Journal):
    • Abre el Símbolo del sistema o PowerShell con privilegios de administrador.
    • Ejecuta el comando nativo para consultar la información del diario USN de la unidad principal (C:):
      fsutil usn queryjournal C:
    • Observa los parámetros devueltos por la consola, tales como el ID del diario, el tamaño de asignación actual, el tamaño de asignación delta y los límites de registro de cambios en los metadatos.
  2. Gestión y control de cambios en NTFS:
    • Para comprobar cómo el sistema operativo registra de forma transaccional cada cambio en los metadatos y previene inconsistencias ante un fallo inesperado, puedes consultar los detalles de la infraestructura transaccional con:
      fsutil transaction list

Opción B: Entorno GNU/Linux (Inspección del Journal de ext4)

  1. Identificación de la partición y el superbloque con tune2fs:
    • Abre una terminal con privilegios de superusuario.
    • Ejecuta el comando para inspeccionar las características del sistema de archivos ext4 en una partición específica (ej. /dev/sda1 o el disco de trabajo):
      sudo tune2fs -l /dev/sda1 | grep -i "journal"
    • Verifica los campos relacionados con el journal, como el UUID del diario, la presencia de la característica has_journal y el tamaño del registro.
  2. Análisis del comportamiento ante fallos con dumpe2fs:
    • Para consultar de forma avanzada el estado de la traza transaccional del sistema de archivos, ejecuta:
      sudo dumpe2fs /dev/sda1

Verificación

  1. Comprueba que has ejecutado con éxito los comandos de consulta de registros (fsutil usn o tune2fs -l) en tu sistema operativo.
  2. Verifica que la característica de registro transaccional se encuentra activa en las unidades analizadas.
  3. Confirma que entiendes cómo el sistema de archivos utiliza este diario para aplicar o descartar cambios inconclusos tras un apagón, evitando la necesidad de un escaneo completo (como el antiguo fsck o chkdsk prolongado).

Preguntas de reflexión:

  1. ¿Cómo actúa exactamente el mecanismo de Journaling (registro por diario) antes de escribir datos o metadatos en los bloques del disco, y qué ocurre en el momento de un corte abrupto de corriente?
  2. ¿Por qué el uso del Journal de ext4 o el USN Journal de NTFS evita tener que realizar un escaneo completo y lento de todo el disco duro (consistencia completa bloque a bloque) tras reiniciar el equipo después de un apagón?
  3. ¿Qué diferencias conceptuales existen entre los modos de journaling habituales (como journal, ordered y writeback en ext4) en cuanto al equilibrio entre seguridad estricta de los datos y velocidad de rendimiento del disco?
Haz clic aquí para ver la solución orientativa

1. ¿Cómo actúa exactamente el mecanismo de Journaling antes de escribir datos o metadatos... y qué ocurre en un corte abrupto?

El sistema de journaling funciona registrando primero en una zona reservada del disco (el diario o log) las operaciones de metadatos que va a realizar antes de ejecutarlas físicamente en el sistema de archivos principal (transacción previa).

Si se produce un corte abrupto de corriente a mitad de una operación de escritura, el sistema operativo se reiniciará de manera inesperada. Al volver a arrancar, el controlador del sistema de archivos leerá el diario para comprobar qué transacciones quedaron a medias: las operaciones completadas se confirman y las incompletas se limpian o descartan automáticamente (recuperación por replay del journal).

2. ¿Por qué el uso del Journal evita tener que realizar un escaneo completo y lento de todo el disco duro tras un apagón?

En los sistemas de archivos antiguos sin diario (como FAT32), un apagón inesperado dejaba la tabla de asignación en un estado totalmente ambiguo, obligando al sistema a realizar un escaneo masivo bloque a bloque de toda la superficie del disco para comprobar la consistencia de los archivos (lo que en Linux requería horas de ejecución de fsck en particiones grandes).

Gracias al journaling, el sistema operativo no necesita revisar todo el disco; le basta con consultar el diario transaccional para saber exactamente qué metadatos estaban siendo modificados en el microsegundo del fallo, reduciendo el tiempo de comprobación y arranque a unos pocos segundos.

3. ¿Qué diferencias conceptuales existen entre los modos de journaling en ext4 (journal, ordered y writeback)?

En ext4 existen tres modos principales de gestión del diario:

  • Journal: Cifra/registra tanto los metadatos como los datos en el diario antes de escribirlos en su ubicación final (máxima seguridad, pero menor rendimiento por duplicar escrituras).
  • Ordered (Predeterminado): Solo registra los metadatos en el diario, pero asegura que los datos reales se escriban en el disco antes de que el cambio de metadatos sea marcado como completado en el journal (equilibrio perfecto entre rendimiento e integridad).
  • Writeback: Registra únicamente los metadatos en el diario sin garantizar el orden de los datos (máximo rendimiento, pero existe riesgo de que aparezcan "archivos basura" con datos antiguos si ocurre un fallo eléctrico).