Sistema de archivos de mil millones de archivos

Artículo original ↗ Discusión en Hacker News ↗

Llevar un sistema de archivos Linux al límite para contener mil millones de archivos vacíos se convierte en una prueba de esfuerzo de la sobrecarga de metadatos, la indexación de directorios y los límites de las herramientas, más que de la capacidad de almacenamiento bruta. Los comentaristas comparan ext4, XFS, btrfs, ReiserFS, ZFS y NTFS bajo cargas intensas de archivos pequeños, y señalan problemas como el bloat de inodes, las operaciones lentas sobre directorios y los tiempos de borrado patológicos. Muchos sostienen que las bases de datos o formatos como SQLite, los sistemas de archivos especializados o diseños alternativos (por ejemplo, directorios fragmentados o sistemas de archivos FUSE/virtuales) suelen ser más adecuados que los sistemas de archivos de propósito general para cargas de trabajo con millones o miles de millones de objetos diminutos.

Rust frente a shell/Python para esta tarea

  • Varios comentarios señalan que el programa en Rust es conceptualmente simple (unos pocos execs y un bucle) y podría reproducirse en un script corto de shell.
  • Otros argumentan que las ventajas de Rust aparecen en el rendimiento, el paralelismo y la mantenibilidad cuando los conjuntos de datos son grandes (por ejemplo, millones de URLs), aunque un prototipo rápido en bash/Python sea más corto.
  • Algunos sugieren separar mkfs/mount de la lógica en Rust para ajustarse a “hacer una sola cosa y hacerla bien”.

Comportamiento del sistema de archivos con directorios enormes

  • Crear mil millones de archivos en un solo directorio se considera un caso de estrés distinto; la búsqueda y el listado del directorio se convierten en cuellos de botella clave.
  • Se comparten pruebas de referencia para ls sobre 1M–10M archivos; el listado sin ordenar (ls -U) y la salida en una sola columna (-1) son drásticamente más rápidos que el ls predeterminado.
  • La indexación htree de ext4 reduce los problemas de escalado del lado del kernel, pero las herramientas de usuario que cargan directorios enteros en memoria siguen comportándose mal.

Espacio y sobrecarga de metadatos

  • La sobrecarga por archivo en ext4 (~296 bytes para un archivo vacío aquí) se relaciona principalmente con el tamaño del inode (256 bytes por defecto) más el directorio y otros metadatos.
  • Inodes más pequeños (por ejemplo, 128 bytes) pueden reducir esto a la mitad, pero reintroducen límites de marcas de tiempo de 32 bits/Y2038.
  • Algunos sistemas especializados (por ejemplo, SeaweedFS) afirman tener metadatos por archivo mucho más bajos.

Experiencias reales con muchos archivos pequeños

  • Varias anécdotas: simulaciones que producen más de 100k archivos pequeños, directorios NTFS con millones de archivos que se vuelven dolorosamente lentos de borrar o copiar, y sistemas Linux que se comportan de forma extraña con decenas de miles de archivos por directorio.
  • Un caso describe cómo las estructuras hash de directorios de ext4 crecen tanto tras miles de millones de ciclos de creación y borrado de archivos que aparece ENOSPC pese a haber mucho espacio libre, lo que motiva el cambio a XFS.

Mejor enfoque de almacenamiento: FS vs DB vs FS especializado

  • El consenso: los sistemas de archivos de propósito general no son “geniales” para cantidades enormes de archivos diminutos.
  • Las bases de datos (SQLite/Postgres) a menudo superan a los sistemas de archivos para muchos objetos pequeños; mover un archivo de base de datos es mucho más fácil que mover millones de archivos.
  • Se sugieren almacenes de objetos o formatos de solo lectura (SquashFS) cuando son apropiados.
  • ReiserFS históricamente destacó con archivos pequeños; Btrfs y otros tienen optimizaciones, pero siguen existiendo compromisos.

Enfoques y सुझावes alternativos

  • Entre las sugerencias figura un sistema de archivos FUSE que exponga virtualmente mil millones de archivos sin crearlos realmente.
  • Se comparten varios patrones de línea de comandos (ls -U1 | wc -l, find ... -printf) y referencias a getdents() para manejar directorios grandes de forma más eficiente.
  • Parte de la discusión aborda ZFS, Hammer2 y los compromisos semánticos y de rendimiento más amplios entre “sistema de archivos vs base de datos”.