FFS - S* Sistema de Archivos

Esta es una herramienta CLI para buscar archivos (como grep) que no usa el kernel del sistema operativo para leer archivos, sino que lee tus discos directamente. Es prácticamente inútil, pero increíblemente genial.

esto es solo ~1.5k líneas de código C que:

• requiere sudo solo al leer un nodo de dispositivo raw (por ejemplo, /dev/rdisk*); buscar un archivo de imagen no necesita permisos elevados
• requiere deshabilitar la protección SIP para ejecutarse en el disco principal de macOS
• puede omitir algunas escrituras recientes de archivos (requerirá una llamada manual a sync)
• podría no ser capaz de buscar árboles en un sistema de archivos altamente volátil mientras otros componentes del sistema escriben archivos en el SO
• funciona solo para sistemas de archivos implementados manualmente en este proyecto

pero al mismo tiempo

• lee bloques directamente de tus discos
• omite la VFS / la ruta read() con búfer, en su lugar hace pread al dispositivo de bloque directamente
• progresivamente más rápido que ripgrep (cuantos más archivos necesites buscar, más rápido es en comparación con ripgrep)
• puede buscar volúmenes no montados - simplemente analiza blobs binarios
• detecta y omite archivos binarios
• distribuye la carga entre todos los núcleos mediante openmp

Para una búsqueda rápida de archivos que realmente funcione, echa un vistazo a mi proyecto fff - supera significativamente a ripgrep sin necesidad de sudo.

Sistemas de archivos compatibles

en linux, casi cualquier sistema de archivos es fácil de implementar

Ext4

./fs/ext4.c

Este es el sistema de archivos más fácil de soportar: es un sistema de archivos con diario que escribe en el lugar (sin copia en escritura), por lo que la mayoría del tiempo es el mejor sistema de archivos para ffs. A veces puedes ver que ffs no puede ver algunas actualizaciones recientes de los archivos, esto puede suceder si el kernel mantiene las actualizaciones recientes en la caché y difiere las escrituras al disco. Puedes forzar la sincronización usando

sync

Btrfs

./fs/btrfs.c

El sistema de archivos B-tree es significativamente más complicado, es un almacenamiento de archivos más eficiente y viene con una limitación adicional:

Cuando se actualiza cualquier archivo en tu sistema de archivos, todo el superbloque también requiere una actualización, lo que significa que si ffs lee el superbloque (el b-tree de alto nivel) y después el kernel actualiza el árbol, toda la lectura se vuelve inválida.

Esto se puede evitar usando fsfreeze o creando un volumen separado y desmontado

Apfs (MacOS)

./fs/apfs.c

APFS es un sistema de archivos propietario implementado por Apple que ha sido sometido a ingeniería inversa y también es compatible aquí, pero Apple ha aumentado significativamente sus políticas de seguridad.

No podrás ejecutar ffs en tu disco principal sin deshabilitar SIP

SIP - la protección de integridad del sistema es una característica de seguridad especial que prohíbe cualquier acceso al superbloque del disco principal incluso como usuario root. No puedes evitarla ni con sudo; tienes que deshabilitar esta característica (puede que ya la tengas deshabilitada si usas proyectos como yabai).

Hay una forma de probar ffs en el sistema de archivos de Apple sin tocar tu disco principal: puedes buscar archivos .dmg raw sin permisos elevados (sí, los instaladores de aplicaciones son solo volúmenes desmontados). Con ffs no necesitas montar nada, solo puedes darle una ruta a los bytes raw de un volumen junto con el tipo de sistema de archivos:

ffs "<QUERY>" /path/to/volume.dmg apfs

Búsqueda en volúmenes desmontados

Debido a que ffs lee bytes directamente, puedes usarlo para buscar cualquier volumen desmontado sin montarlos en el sistema de archivos. Por ejemplo, leyendo archivos .iso o .dmg.

Velocidad

Esta es la parte más divertida: ffs no tiene acceso a la caché del sistema de archivos VFS/kernel. Por eso será más lento en directorios pequeños (o ya almacenados en caché), pero progresivamente más rápido una vez que la caché se agota y tu kernel tiene que ir a leer el estado real del disco.

¿Por qué? Exactamente para demostrar que en algún momento la VFS del kernel se convierte en una sobrecarga.

Este es el resultado de la comparación entre ffs y ripgrep en una unidad montada con btrfs. Ten en cuenta que ripgrep usa un comparador y caminante de archivos basado en SIMD mucho más avanzado, mientras que ffs es solo ~1.8k líneas de código C.

[repos — 631k files]
  ffs |####                                              | 5.505s
  rg  |###                                               | 4.813s

[dev — 1.50M files]
  ffs |############                                      | 18.413s
  rg  |#################                                 | 25.673s

[home — 3.25M files]
  ffs |########################                          | 36.205s
  rg  |##################################################| 74.690s

Las banderas usadas para ripgrep son -F --no-heading -H -n --no-ignore --hidden --one-file-system --no-messages - lo que hace que emita los mismos resultados que ffs.

Construir el proyecto

Todo lo que necesitas para compilar el proyecto es libzstd para btrfs, openmp en tu pkg-config, luego simplemente

make ffs
ffs --help