Introducción a 3FS, el sistema de archivos distribuido de DeepSeek

• 3FS es un sistema de archivos distribuido, open source y de alto rendimiento desarrollado por DeepSeek, con soporte para procesamiento de datos a gran escala y alto throughput
• Funciona como un sistema de archivos común, pero en realidad almacena los datos de forma distribuida en varias máquinas y ofrece una capa de abstracción para que el usuario no tenga que preocuparse por ello
• Opera separando 4 componentes principales (Meta, Mgmtd, Storage, Client) para manejar por separado los metadatos, la administración de nodos, el almacenamiento real de datos y el procesamiento de solicitudes de usuario
• Logra consistencia fuerte y tolerancia a fallas mediante el algoritmo CRAQ, propagando de forma segura las solicitudes de escritura a través de una estructura en cadena
• 3FS se diferencia de otros sistemas de archivos distribuidos por su viabilidad de uso real y su escalabilidad de rendimiento

---

¿Qué es 3FS?

• 3FS significa Fire-Flyer File System y es un sistema de archivos distribuido publicado por DeepSeek
• Fue lanzado durante la semana de publicación open source de DeepSeek
• Aunque parece una ruta de archivo normal, en realidad ofrece una abstracción sobre datos almacenados de forma distribuida en varias máquinas

¿Qué es un sistema de archivos distribuido?

• Para el usuario parece un sistema de archivos local, pero en realidad almacena los datos de forma distribuida en varios servidores
• Ejemplo: la ruta /3fs/stage/notes.txt parece un solo archivo, pero en realidad está dividida y almacenada en varios servidores
• El usuario puede manejarlo como un archivo normal con comandos como mkdir y cat

¿Por qué usar un sistema de archivos distribuido?

• Soporta grandes volúmenes de datos (a nivel de petabytes) y alto throughput
• Garantiza estabilidad mediante tolerancia a fallas (fault tolerance) y redundancia (redundancy)
• Ejemplos de uso real:
  • Frameworks de procesamiento paralelo como HDFS + Spark
  • Checkpointing en pipelines de entrenamiento de ML
  • Colossus de Google
  • Haystack, el repositorio de fotos de Meta
  • Ejemplos de almacenamiento para IA: JuiceFS vs CephFS

Componentes de 3FS

• Está compuesto por 4 tipos principales de nodos

Meta

• Gestiona metadatos como rutas de archivos, atributos y ubicación
• Procesa solicitudes del cliente por RPC (open, stat, close, etc.)
• La información de metadatos se almacena en FoundationDB
• Inode guarda información como el tamaño del archivo y el propietario
• DirEntry conecta la ruta con el inode (pueden existir varias rutas para un mismo archivo, como con los enlaces simbólicos)

Mgmtd

• Se encarga del registro de nodos y verificación de estado del clúster
• Los nodos se registran al arrancar y envían heartbeats periódicamente
• Cumple el papel de router central, por lo que no hace falta mantener conexiones directas entre nodos
• También administra la información de configuración para construir la cadena CRAQ

Storage

• Se encarga del almacenamiento real de los datos
• Administra bloques de disco mediante ChunkEngine basado en Rust
  • Rastrea tamaño, offset, checksum, versión y otros datos de los bloques de disco
  • El usuario no interactúa directamente con los bloques; se le ofrece una interfaz
  • La información de metadatos se almacena en LevelDB
• Existen varios workers
  • AllocateWorker asigna bloques nuevos
  • PunchHoleWorker recupera bloques sin uso
  • AioReadWorker procesa lecturas asíncronas a través de la cola de io_uring
• Durante las escrituras, los datos se reenvían al siguiente nodo siguiendo la cadena CRAQ

Client

• Procesa las solicitudes del usuario y se comunica con los demás nodos
• Flujo de trabajo:
  • Consulta a Mgmtd la ubicación de los nodos
  • Solicita operaciones de archivo a Meta
  • Transfiere datos con Storage

Algoritmo CRAQ

• Significa Chain Replication with Apportioned Queries y ofrece consistencia fuerte (linearizability)
• Flujo de escritura:
  • La escritura se propaga en orden Head → Middle → Tail
  • En las etapas intermedias, los datos se marcan como dirty (no se pueden leer)
  • Tras el commit en Tail, el estado clean se propaga hacia atrás
• Flujo de lectura:
  • Si está clean, se devuelve de inmediato
  • Si está dirty, se consulta al tail para obtener los datos más recientes

CRAQ desde el punto de vista del rendimiento

• La velocidad de escritura queda limitada por el nodo más lento
• Cuando se accede con frecuencia a datos dirty, las lecturas pueden concentrarse en el tail y provocar un cuello de botella de lectura
• Ejemplo: degradación de rendimiento con una carga de trabajo Zipfian
• En un clúster de 5 nodos, se replica en 3 para minimizar la pérdida de rendimiento en caso de falla

Diferencias frente a otros sistemas de archivos distribuidos

• La estructura es similar, pero hay diferencias en la aplicabilidad real y en la forma de implementación
• Elementos de comparación:
  • En qué tipos de workload destaca
  • Flexibilidad para ajustar el rendimiento
  • Facilidad de despliegue
  • Escalabilidad del throughput
  • Gestión de latencia dentro del SLO
  • Confiabilidad
• Elementos técnicos en detalle:
  • Causas de los cuellos de botella y cómo se manejan
  • Presencia o ausencia de locks
  • Estructuras de datos utilizadas
  • Hardware objetivo
  • Algoritmos de tolerancia a fallas o métodos de corrección de errores utilizados

Próximo tema de la serie del blog

• Se planea verificar las afirmaciones de DeepSeek mediante un análisis de rendimiento real
• Puntos de revisión:
  • La afirmación de DeepSeek sobre el cuello de botella de FUSE
  • Posibilidad de reproducir las gráficas de rendimiento
  • Análisis de escenarios de degradación de rendimiento
  • Factores de cuello de botella (CPU, memoria, disco, red)
  • En qué workloads ofrece mejor rendimiento
  • Comparación con sistemas existentes
  • Diferencias frente a cómo los sistemas existentes resuelven esos problemas
  • Revisión de posibles mejoras directas

Material adicional

• En la nota oficial de diseño se puede consultar la forma de implementación
• Documentación en chino:
  • Guía de inicio
  • IO asíncrono
  • Lectura por RDMA
  • Enrutamiento de red
  • Distribución de carga de lectura
• Artículo académico: Arquitectura Fire-Flyer AI-HPC

[softer]

Era un problema sobre el que también estaba pensando, pero esto...

[GN⁺]

Comentarios en Hacker News

• S3FS es un sistema de archivos de metadatos escalable, comparado con varios sistemas de archivos distribuidos

  • Entre ellos están Collosus, Tectonic (Meta), ADLSv2 (Microsoft), HopsFS (Hopsworks) y PolarFS (Alibaba)
  • S3FS usa FoundationDB, Collosus usa BigTable, Tectonic usa un almacén KV y HopsFS usa RonDB
  • Lo importante de S3FS es que (1) soporta clientes FUSE, lo que facilita su uso, y (2) soporta almacenamiento NVMe, por lo que no queda limitado por el I/O de disco
  • HopsFS agrega almacenamiento por niveles, guardando los datos recientes en NVMe y los datos archivados en S3

• Al evaluar estos sistemas hay que considerar los límites teóricos, la eficiencia y las limitaciones prácticas

  • En teoría, los sistemas de archivos distribuidos paralelos como Lustre pueden escalar indefinidamente
  • Para evaluar la eficiencia, se calcula cuánto almacenamiento y throughput se puede obtener con nodos que tienen discos de X TiB
  • En comparación con FSx for Lustre, 3FS puede operar en AWS entre 12% y 30% más barato
  • Sigue quedando la pregunta de si realmente se puede construir el sistema de archivos al tamaño de despliegue que la gente quiere
  • Se entiende que DeepSeek construya este tipo de sistemas para obtener internamente las propiedades que necesita
  • En Archil esperan encontrar una mejor configuración predeterminada que la mayoría de la gente pueda usar sin tener que administrar clústeres enormes

• Hay interés en compararlo con SeaweedFS

  • SeaweedFS se usa para almacenar datos meteorológicos, y unos 3 PB de datos se usan para entrenamiento de ML

• Pregunta sobre por qué no usar CephFS

  • CephFS ha sido probado a fondo en escenarios del mundo real y ha demostrado confiabilidad incluso a escala de petabytes
  • Como solución de código abierto, puede ejecutarse sobre el almacenamiento NVMe más rápido y lograr IOPS muy altos con interconexiones de más de 10 gigabits

• Pregunta sobre la comparación con JuiceFS

  • Hay planes de ejecutar JuiceFS sobre S3 Garage en una configuración personal de homelab
  • Garage solo soporta replicación, y no soporta erasure coding ni sharding
  • Se eligió porque parece sencillo de configurar

• Como operador pequeño y usuario de homelab, parece poco probable que alguna vez use un sistema de archivos distribuido a gran escala

  • Hay curiosidad sobre cómo se manejan el respaldo y la recuperación cuando se trabaja con datos a escala de petabytes

• Aunque es una configuración compleja, no está claro qué funciones son esenciales para cargas de trabajo de deep learning

  • Las funciones necesarias son almacenamiento a escala de petabytes, paralelismo de lectura/escritura y redundancia
  • La consistencia es difícil de lograr y aquí no parece necesaria

• Pregunta sobre qué tan fácil es desactivar el sistema de archivos distribuido de DeepSeek

  • Por ejemplo, una universidad en Estados Unidos podría recibir aprobación para usar DeepSeek en investigación, pero necesitaría asegurarse de que los datos no salgan del sistema de archivos del clúster de investigación local

• Pregunta sobre si esto podría replicarse con unidades ZFS distribuidas en varios dispositivos