ffs: una herramienta CLI que busca archivos leyendo el disco directamente, sin pasar por el kernel

Fuentes: ffs: a CLI file search tool that reads your disk directly, bypassing the OS kernel

ffs es una herramienta de línea de comandos escrita en aproximadamente 1.500 líneas de C que permite buscar archivos en un disco obviando la capa del sistema de archivos del kernel: lee los bloques del dispositivo directamente mediante pread sobre el block device, sin recurrir a la caché VFS ni a la ruta de read() con búfer. Su autor la describe como «prácticamente inútil, pero increíblemente curiosa», y su objetivo declarado es demostrar que, llegado cierto volumen de datos, la VFS del kernel se convierte en una sobrecarga.

En la práctica, ffs implementa a mano los sistemas de archivos que sabe leer. En Linux, la mayoría son sencillos de soportar: el más fácil es un sistema de journaling que escribe en el sitio, donde el principal inconveniente es que puede no ver escrituras recientes si el kernel las retiene en caché; basta con ejecutar sync para forzar la persistencia. El B-tree (btrfs) es más complejo y arrastra una limitación adicional: cualquier actualización de un archivo obliga a reescribir el superbloque, por lo que una lectura larga puede quedar invalidada a mitad de proceso; se puede mitigar con fsfreeze o usando un volumen separado.

En macOS, ffs es compatible con APFS, cuyo código propietario ha sido ingeniería inversa. Para ejecutarlo sobre el disco principal es imprescindible desactivar la protección SIP, ya que ni siquiera root puede saltarla; en cambio, se puede probar sin permisos elevados sobre imágenes .dmg o .iso, pasándole la ruta del fichero como volumen desmontado. La herramienta detecta y omite binarios, se compila con make ffs (necesita libzstd y OpenMP) y reparte la carga entre núcleos con OpenMP. En las pruebas del autor, ffs es más lento que ripgrep en directorios pequeños, pero claramente más rápido a medida que crece el número de archivos: en un volumen con 3,25 millones de archivos tarda 36,2 segundos frente a los 74,7 segundos de ripgrep, ejecutado con -F --no-heading -H -n --no-ignore --hidden --one-file-system --no-messages.