Sesión 12

Conceptos Fundamentales de Sistemas de Archivos

Ingeniería Interna: Archivos, Metadatos y Estructuras

Unidad 2 · Almacenamiento Primario y Secundario

Un archivo no es simplemente un ícono en una interfaz gráfica. En esta sesión exploraremos la abstracción técnica del Kernel, analizando atributos reales, números mágicos (Magic Numbers), y la diferencia radical entre el identificador lógico del disco y el nombre que vemos como usuarios.

Usa ← → para navegar · F para alternar pantalla completa.

El problema del hardware vs El modelo Lógico

Los dispositivos de almacenamiento masivo (Discos Duros, SSDs) no entienden qué es un PDF o una foto. Solo "ven" sectores y bloques crudos (ej. sector 0 al sector 1000000) llenos de 0s y 1s.

La Visión Lógica (El Archivo)

Un espacio lógico de direcciones contiguas.
Posee un nombre humano entendible y límites definidos.
Brinda un método estándar estructurado para Persistencia.

La Visión Física (El Disco)

Miles de bloques dispersos y desordenados por todo el almacenamiento magnético o de estado sólido.
Es el Sistema de Archivos (File System) el que enmascara esta fragmentación al usuario.

Principio clave: El SO aísla a los programas de la complejidad del hardware ruteando las llamadas al disco mediante llamadas al API de archivos (Sistema de Entrada/Salida).

Metadatos y Atributos de Control

Para gestionar un archivo, el sistema operativo necesita guardar información "sobre" la información. Esta metadata determina cada regla de interacción.

Nombre: Referencia humana (único dato guardado en la carpeta, no en el archivo per se).
Identificador Interno: El ID o "I-node", el verdadero nombre para el sistema.
Tipo: Para SO que soportan diferentes formatos estructurales.
Ubicación Lógica: Puntero hacia el dispositivo y ubicación en el disco.
Tamaño Real vs Bloques: Cantidad exacta en bytes frente a los bloques ocupados físicamente.
Protección: Roles y permisos (`rwx`) para lectura/escritura/ejecución.
Marcas Temporales: Creación, último acceso, última modificación (Vital en análisis forense).

Estructura de Datos: I-Nodes y Bloques

Un archivo no es monolítico. Internamente (en sistemas tipo UNIX como Linux/macOS), el kernel separa tajantemente el contenido de la información técnica.

1. Bloques de Datos (Data Blocks)

Cajas fuertes en el disco donde caen los bytes reales. Curiosamente, un bloque de datos no tiene ni idea a qué archivo pertenece. Solo contiene ceros y unos puros.

2. Nodo de Índice (I-Node / MFT)

Un registro de tamaño fijo que almacena todos los atributos previamente vistos y mantiene la lista de punteros hacia dónde están escondidos los Bloques de Datos.

Dato Contraintuitivo: El I-node contiene casi todo sobre el archivo... excepto el Nombre del Archivo. El nombre es gestionado estrictamente por el Directorio (carpeta).

Ejemplo Práctico 1: Inspección de I-Nodes con `stat`

En nuestra terminal local/WSL procedemos a ver el "alma" técnica de un archivo recién creado, obviando la interfaz gráfica de explorador de archivos.

# 1. Creamos un archivo corto de apenas 13 caracteres de texto (13 bytes). $ echo "Hola Sistemas" > demo.txt # 2. Invocamos la llamada al sistema que lee las propiedades directas del i-node. $ stat demo.txt File: demo.txt Size: 14 Blocks: 8 IO Block: 4096 regular file Device: 802h/2050d Inode: 4791023 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ user) Gid: ( 1000/ user) Access: 2026-03-24 10:15:00.120000000 -0500 Modify: 2026-03-24 10:15:00.120000000 -0500 Change: 2026-03-24 10:15:00.120000000 -0500

Pregunta de análisis: El texto pesa 14 bytes (letras + salto de línea), pero el SO asignó 8 Bloques físicos. Esto se debe a que el disco duro se maneja en sectores indivisibles de 512 Bytes o 4096 Bytes (aquí 4096). Este fenómeno genera Fragmentación Interna.

Comportamiento del SO frente a Tipos de Archivos

¿Cómo sabe la computadora diferenciar entre una canción en MP3, un texto y un virus binario ejecutable? Aquí las filosofías tecnológicas se bifurcan agresivamente.

Windows (Por Extensión)

Mecanismo rígido y amigable con el usuario.
Depende 100% del sufijo post-último punto (ej. .docx, .exe, .dll).
El registro de Windows lanza programas según esta lista. Si engañas la extensión, el SO falla abriéndolo.

UNIX / Linux (Magic Numbers)

Mecanismo técnico profundo.
Total ignorancia de las extensiones de archivo (son puramente estéticas).
El Kernel lee los primeros bytes hexadecimales reales del archivo para saber qué es (Firma Técnica).

Ejemplo Práctico 2: Evadiendo Extensiones con Magic Numbers

¿Qué pasa si un atacante sube a un servidor Web un virus_oculto.png que por dentro no es una imagen, sino código ejecutable? ¿Cómo lo detecta el SO Unix de forma forense?

# 1. Tenemos una auténtica foto PNG renombrada maliciosamente a .txt para confundir. $ mv mi_imagen.png documento_falso.txt # 2. Usamos el comando "file" que lee la cabecera real ignorando el nombre: $ file documento_falso.txt documento_falso.txt: PNG image data, 1920 x 1080, 8-bit/color RGB # 3. Inspeccionamos a nivel de bits con un editor hexadecimal (xxd) $ xxd documento_falso.txt | head -n 1 00000000: 8950 4e47 0d0a 1a0a 0000 000d 4948 4452 .PNG........IHDR

Análisis Técnico: Independiente de lo que diga el nombre, Unix lee el código hexadecimal `89 50 4e 47` (P N G) como el Número Mágico. En servidores en producción, jamás se confía de la extensión para validar archivos seguros.

Syscalls: Operaciones Básicas sobre Archivos

A nivel de programación (ej. C, C++, Python), no tocamos el I-Node. Lanzamos interrupciones de software conocidas como System Calls al SO.

Create(): Busca bloque libre, reserva un I-Node nuevo y actualiza el catálogo del directorio.
Open(): El SO mapea los permisos y trae la estructura a memoria principal (crea un File Descriptor). Importantísimo para rendimiento.
Read() / Write(): Flujo de bytes en la posición que indica el puntero lógico del buffer.
Reposition / Seek(): Mueve el puntero internamente sin alterar los datos, para saltar a áreas precisas del disco físico.
Close(): Destruye el FD en la memoria, vacía buffers pendientes al disco y libera bloqueos para otros procesos.

El costo del `Open` y la Tabla de Archivos Abiertos

Las búsquedas en directorios toman mucho tiempo porque consultan el disco. La función `Open()` alivia el procesador cargando el archivo en la Tabla de Archivos Abiertos del sistema (Open File Table), viviendo enteramente en RAM.

Por cada archivo abierto, el SO mantiene vivo:

Puntero del archivo: Ubicación del último byte escrito o leído para un proceso específico que lo consumió.
Conteo de aperturas: Si 5 programas tienen abierto un `.log`, el SO incrementa el contador. Al llegar a cero (Close), se baja de memoria.

¿Por qué es vital el `Close()`?

Si tu código en C# o Python entra en bucles `Open` y olvida el `Close()`, se agotan los File Descriptors, provocando un Memory Leak a nivel del SO, congelando o tumbando el servidor.

Directorios: ¿Qué es "una Carpeta"?

Como hemos dicho, los bloques de datos no tienen nombre. Para esto existe el Directorio: un archivo logístico especializado cuyo único trabajo es mantener el "Directorio Telefónico" en formato lista.

El contenido bruto de un directorio es apenas esto:

Contenido de "MisDocumentos": "tarea.pdf" -> I-node 58129 "tesis_final.docx" -> I-node 58200 "Carpeta_Memes" -> I-node 59001 # Esto es otro catálogo interno!

Aterrizando el concepto: Renombrar un archivo de 100 GB. ¿Por qué mv archivo1 archivo2 es instantáneo? Porque el SO no mueve 100 GB. ¡Sencillamente agarra la tablita del directorio, cambia la cadena "archivo1" por "archivo2" dejando exactamente el mismo número de I-Node atado!

Estructura Jerárquica e Indexación Lógica

Los sistemas comerciales operan usando Grafos Acíclicos Dirigidos o en formaciones de Árbol Extendido. Cada usuario y sub-usuario recibe un nodo de control donde ramificar sus datos.

Rutas Absolutas

Inician obligatoriamente desde la Raíz Suprema.
Windows: C:\Usuarios\Juan\foto.png
Linux/Mac: /home/juan/foto.png

Rutas Relativas

Inician desde nuestro estado actual (Directorio de Trabajo / Working Directory).
./foto.png (aquí mismo)
../pepe/foto.png (sube un nivel al padre, baja a pepe)

Enlaces Duros (Hard Links) vs Simbólicos (Soft Links)

Al separar el Nombre (Directorio) del Identificador (I-node), el SO nos otorga el poder de tener múltiples nombres apuntando hacia los mismos datos en el disco.

Hard Links

Un nuevo nombre que está amarrado al Mismo `I-Node` fundamental.

Son "iguales" frente a los ojos del núcleo en todo nivel.
Si borras el archivo original, los datos no se borran. El sistema mantiene vivos los datos hasta que todos los hard-links bajen a 0.

Soft Links (Accesos Directos)

Es un I-Node distinto, diminuto, que cuyo único bloque de datos posee texto que dice: "Por favor dirígete a X ruta".

Si borras el archivo original, el link simbólico queda roto / huérfano apuntando a la nada.

Ejemplo Práctico 3: Creación y Destrucción de Enlaces

Simularemos crear respaldos lógicos. La clave aquí es leer la primera columna del comando ls -li, la cual nos delata el I-node de la máquina real en vivo.

# 1. Creamos Data importante y miramos su i-node (-i) $ echo "Clave123" > db.txt $ ls -li db.txt 551020 -rw-r--r-- 1 user 9 db.txt # 2. Creamos un Hard Link (ln), y un Accesos Simbólico (ln -s) $ ln db.txt hard_bd.txt $ ln -s db.txt soft_bd.txt $ ls -li *.txt 551020 -rw-r--r-- 2 user 9 db.txt <- Original (Links saltó a 2) 551020 -rw-r--r-- 2 user 9 hard_bd.txt <- Hard Link (¡Mismo Inode!) 623315 lrwxrwxrwx 1 user 6 soft_bd.txt -> db.txt <- Soft Link (Inode distinto 623315) # 3. Borramos (Delete) el archivo principal! $ rm db.txt $ cat hard_bd.txt Clave123 <- Los datos sobreviven intactos en el Hard Link! $ cat soft_bd.txt cat: soft_bd.txt: No such file or directory <- El puntero simbólico ha "muerto".

Resumen y Proyección del Conocimiento

El manejo de la persistencia de datos oculta asombrosas capas de ingeniería algorítmica. Entender las verdaderas limitantes y comportamientos forenses distingue a un instalador de software de un verdadero Arquitecto e Ingeniero de Sistemas.

Para la Práctica Semanal:

El uso inapropiado de múltiples Open Files en tus desarrollos puede destruir la memoria del servidor.
Las búsquedas profundas de archivos son costosas, porque cada carpeta escaneada recorre decenas de MFT/inodes en disco físico, matando el I/O.

La Siguiente Sesión (S13)

Ya vimos el comportamiento "Lógico" y el File System. Pero... ¿Y cómo metemos esos gigantescos de Bloques a la fuerza a zonas físicas rotas e incompletas en un disco duro magnético que gira ruidosamente? Lo abordaremos en las Estrategias de Asignación Enlazada, Contigua e Indexada.