Sistemas de archivos

📐 Fundamento

En Unix, un archivo es una secuencia de bytes con nombre. Sin más estructura impuesta. Si vos querés que sea un CSV, JPG, mp3, EXE — el SO no sabe ni le importa. Es tu programa el que interpreta los bytes.

Otros SO (mainframes IBM antiguos) imponían registros estructurados — el SO te daba "el registro 5 del archivo de empleados". Era poderoso pero rígido. Unix eligió flexibilidad: bytes crudos, estructura por convención (extensiones, magic bytes).

API estándar (POSIX):

int fd = open("archivo.txt", O_RDONLY);
char buf[256];
ssize_t n = read(fd, buf, 256);
close(fd);

open te da un file descriptor (fd) — un entero pequeño que el kernel usa para identificar tu archivo abierto.

Operaciones básicas:

File descriptors especiales:

• 0 = stdin.
• 1 = stdout.
• 2 = stderr.

Por eso printf (que escribe a stdout) realmente es un wrapper alrededor de write(1, ...).

📐 Fundamento

Un directorio es un archivo especial que contiene una tabla de entradas: nombre + referencia a otro inodo (archivo o subdirectorio).

/
├── home/
│   ├── ana/
│   │   ├── docs/
│   │   │   └── tesis.pdf
│   │   └── fotos/
│   └── beto/
├── etc/
│   └── passwd
└── usr/
    └── bin/
        └── ls

Paths absolutos empiezan con /: /home/ana/docs/tesis.pdf. Paths relativos son respecto al directorio actual (pwd): docs/tesis.pdf.

Especiales:

• . = directorio actual.
• .. = directorio padre.
• ~ = home del usuario (es del shell, no del FS).

Path resolution. Cuando hacés open("/home/ana/docs/tesis.pdf"), el kernel:

1. Empieza en / (root, inodo conocido).
2. Busca home en root → encuentra inodo de /home.
3. Busca ana en /home → inodo de /home/ana.
4. Busca docs → inodo de /home/ana/docs.
5. Busca tesis.pdf → inodo del archivo.

Si en cualquier paso no encuentra, error (ENOENT, "no such file"). Si no tenés permisos para entrar a un directorio, error (EACCES).

Todo eso es caro — un acceso por nivel. Por eso el SO mantiene una dentry cache que recuerda traducciones de path → inodo recientes.

📐 Fundamento

En Unix, cada archivo tiene un inodo (index node) — una estructura del FS que guarda toda la metadata del archivo, menos el nombre.

El nombre vive en el directorio que lo contiene. El inodo vive aparte. Esa separación permite:

• Hard links: dos nombres distintos apuntando al mismo inodo.
• Renombrar = cambiar el nombre en el directorio sin tocar el inodo.

Contenido típico de un inodo:

Comando ls -li muestra el número de inodo:

$ ls -li
total 4
12345 -rw-r--r-- 1 ana users 1234 may  5 10:00 archivo.txt

12345 es el inodo. 1 es el conteo de hard links.

Hard link:

$ ln archivo.txt copia.txt
$ ls -li
12345 -rw-r--r-- 2 ana users 1234 may  5 10:00 archivo.txt
12345 -rw-r--r-- 2 ana users 1234 may  5 10:00 copia.txt

Mismo inodo (12345), dos nombres, conteo de enlaces = 2. Si borrás archivo.txt, copia.txt sigue accediendo al mismo dato. El inodo solo se libera cuando el conteo llega a cero.

Symbolic link (soft link):

$ ln -s archivo.txt simbolico.txt
$ ls -li
12345 -rw-r--r-- 1 ana users 1234 may  5 archivo.txt
12346 lrwxrwxrwx 1 ana users   12 may  5 simbolico.txt -> archivo.txt

simbolico.txt es otro archivo, con su propio inodo, cuyo contenido es la cadena "archivo.txt". Si borrás archivo.txt, el simbólico queda roto (apunta a algo inexistente).

Diferencia clave:

📐 Fundamento

Un disco lo dividimos en bloques (típicamente 4 KB). El sistema de archivos asigna bloques a archivos. Hay varios esquemas:

Asignación contigua

Archivo en bloques consecutivos. Rapidísimo de leer (un solo movimiento de cabezal en HDD), pero fragmenta terrible — al borrar archivos quedan agujeros.

Solo se usa en CD-ROM (escritura única).

Lista enlazada

Cada bloque apunta al siguiente. Sin fragmentación, pero lectura aleatoria es lentísima — para llegar al bloque 100 hay que recorrer los 99 anteriores.

FAT (File Allocation Table)

Como lista enlazada, pero la tabla de "siguiente bloque" está concentrada en una zona del disco. Lectura aleatoria es manejable. Limitación: la tabla entera tiene que estar en RAM, lo cual restringe el tamaño máximo del FS.

FAT32: archivos máx 4 GB, FS máx 2 TB.

Inodos con punteros multinivel (Unix clásico, ext2)

El inodo guarda directamente los primeros bloques (típicamente 12). Si el archivo es más grande, usa bloques indirectos (un bloque que es un array de punteros), doble indirecto (un bloque que apunta a bloques indirectos), triple indirecto.

Inodo:
  bloques directos:    [b0, b1, ..., b11]
  indirecto simple:    [→ bloque que apunta a b12..bN]
  indirecto doble:     [→ bloque → bloques con punteros]
  indirecto triple:    [→ → → bloques de datos]

Resultado: archivos chicos son rapidísimos (solo el inodo), grandes funcionan razonablemente.

Extents (ext4, NTFS, XFS)

En lugar de listar bloque-por-bloque, registrar rangos: "del bloque 1000 al 1999, todo es de este archivo". Mucho más compacto para archivos grandes y contiguos.

ext4, NTFS y XFS usan extents. Es el estándar moderno.

📐 Fundamento

¿Cómo lleva el FS la cuenta de qué bloques están libres?

Bitmap

Un array de bits, uno por bloque. 0 = libre, 1 = ocupado. Eficiente para encontrar libres consecutivos.

Para un disco de 1 TB con bloques de 4 KB → 250 millones de bits = 31 MB de bitmap. Razonable.

Lista enlazada de libres

Bloques libres encadenados. Más simple, peor para asignar contiguos.

ext4, NTFS, FAT — todos usan bitmaps (con variantes).

Comando df:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       457G  234G  201G  54% /

📐 Fundamento

Imaginate que estás escribiendo a un archivo y se corta la luz a medio camino. El estado puede quedar inconsistente:

• Bloques de datos escritos pero el inodo no actualizado.
• Inodo apunta a bloques basura.
• Espacio en el bitmap marcado como libre cuando no lo está.

Eso era pesadilla en sistemas viejos. Ext2 y FAT eran vulnerables; al reiniciar tras corte, había que correr fsck (file system check) que escaneaba el disco entero — minutos u horas en discos grandes.

Journaling lo soluciona. Idea: antes de hacer cualquier cambio, escribir en un log (journal) lo que vas a hacer. Si la operación se interrumpe, al reiniciar el SO rehace o deshace desde el journal.

Pasos típicos para una escritura:

1. Escribir en journal: "voy a hacer X, Y, Z".
2. Marcar journal como commit (esta entrada es válida).
3. Escribir los cambios reales al disco.
4. Marcar journal como completado.

Si se corta entre 1 y 2: nada cambió, ignorar el journal. Si se corta entre 2 y 3: rehacer desde el journal. Si se corta entre 3 y 4: lo mismo.

ext3, ext4, NTFS, XFS, Btrfs — todos hacen journaling.

Modos en ext4:

• journal: journaling de datos y metadata. Más seguro, más lento.
• ordered (default): metadata en journal, datos directo. Buen balance.
• writeback: solo metadata, ni siquiera ordenado. Más rápido, riesgoso.

Reemplazo moderno: filesystems copy-on-write como ZFS y Btrfs. Nunca sobreescriben — nuevas versiones a otro lado, atómicamente cambian "qué versión está activa". Más robustos pero más complejos.

📐 Fundamento

Linux soporta decenas de FS distintos. Tu read() no sabe qué FS estás usando — el kernel lo abstrae con la VFS (Virtual File System).

                     read(fd, buf, n)
                            ↓
                +-----------------------+
                |        VFS            |  ← capa común
                +---+--------+----------+
                    |        |        |
                  ext4      NTFS     XFS    ...
                    ↓        ↓        ↓
                Hardware (disk drivers)

Cada FS implementa una interfaz común (file_operations, inode_operations). VFS dispatcha a la implementación correcta según donde esté el archivo.

Resultado: tu programa funciona igual en ext4 que en NTFS-3g montado vía FUSE. Los detalles del disco están encapsulados.

Mount. Asociar un FS a un punto del árbol:

# mount /dev/sdb1 /mnt
$ ls /mnt   # ahora ves los archivos del segundo disco

/proc y /sys son pseudo-FS: no están en disco, los genera el kernel al vuelo. Por eso cat /proc/cpuinfo es realmente "preguntar al kernel".

📐 Fundamento

Cada archivo tiene tres clases de usuarios y tres permisos:

permisos:    r w x   r w x   r w x
             dueño   grupo   otros

• r = read.
• w = write.
• x = execute (ejecutar archivo o entrar a directorio).

Notación octal: rwx = 7, rw- = 6, r-- = 4. Por eso ves cosas como chmod 755 archivo:

• 7 (dueño): rwx.
• 5 (grupo): r-x.
• 5 (otros): r-x.

Comando para verlo:

$ ls -l
-rwxr-xr-x 1 ana users 8192 may  5 script.sh
drwxr-xr-x 3 ana users 4096 may  5 docs

- al inicio = archivo regular. d = directorio. l = symlink.

Cambiar:

$ chmod 644 archivo       # rw-r--r--
$ chmod u+x archivo       # agrega execute al dueño
$ chown beto:devs archivo # cambia dueño y grupo (root)

Bit setuid. Si un archivo ejecutable tiene bit s en el dueño, se ejecuta con los permisos del dueño, no del que lo lanza. Eso es lo que permite que passwd (un programa común) modifique /etc/shadow (que solo root puede tocar). Es poderoso y peligroso — bug clásico de seguridad cuando está mal usado.

Permisos en directorios:

• r = listar contenido.
• w = crear/borrar archivos dentro.
• x = entrar (acceder a archivos por nombre).

x sin r = "podés acceder a archivos si sabés el nombre, pero no podés listar". Patrón legítimo para directorios "privados pero accesibles".