FFS - Système de fichiers F*

Ceci est un outil en ligne de commande pour rechercher des fichiers (comme grep) qui n'utilise pas le noyau du système d'exploitation pour lire les fichiers, mais lit directement vos disques. Il est pratiquement inutile, mais incroyablement cool.

ce ne sont que ~1,5k lignes de code C qui :

• nécessite sudo uniquement lors de la lecture d'un nœud de périphérique brut (ex. /dev/rdisk*) ; la recherche dans un fichier image ne nécessite pas de permissions élevées
• nécessite la désactivation de la protection SIP pour s'exécuter sur le disque principal macOS
• peut manquer certaines écritures récentes de fichiers (nécessitera un appel sync manuel)
• peut ne pas être capable de parcourir des arborescences sur un système de fichiers très volatil pendant que d'autres composants système écrivent des fichiers dans l'OS
• fonctionne uniquement pour les systèmes de fichiers implémentés manuellement dans ce projet

mais en même temps

• lit directement les blocs de vos disques
• contourne le chemin VFS / lecture read() bufferisée, à la place il exécute pread directement sur le périphérique bloc
• progressivement plus rapide que ripgrep (plus vous avez de fichiers à rechercher - plus il est rapide que ripgrep)
• peut rechercher des volumes non montés - il analyse simplement des blobs binaires
• détecte et ignore les fichiers binaires
• répartit la charge sur tous les cœurs via openmp

Pour une recherche de fichiers vraiment rapide, consultez mon projet fff - il surpasse significativement ripgrep sans avoir besoin de sudo.

Systèmes de fichiers pris en charge

sous linux, la plupart des systèmes de fichiers sont faciles à implémenter

Ext4

./fs/ext4.c

C'est le système de fichiers le plus simple à prendre en charge : c'est un système de fichiers journalisé qui écrit sur place (pas de copie à l'écriture), donc la plupart du temps c'est le meilleur système de fichiers pour ffs. Parfois, vous pouvez constater que ffs ne voit pas certaines mises à jour récentes des fichiers, cela peut arriver si le noyau conserve les mises à jour récentes dans le cache et retarde l'écriture sur le disque. Vous pouvez forcer la synchronisation en utilisant

sync

Btrfs

./fs/btrfs.c

Le système de fichiers B-tree est significativement plus compliqué, est un stockage de fichiers plus efficace et comporte une limitation supplémentaire :

Lorsqu'un fichier sur votre système de fichiers est mis à jour, tout le superbloc nécessite également une mise à jour, ce qui signifie que si ffs lit le superbloc (l'arbre B de haut niveau) et qu'ensuite le noyau met à jour l'arbre - toute la lecture devient invalide.

Il est possible de contourner cela en utilisant fsfreeze ou en créant un volume détaché séparé

Apfs (MacOS)

./fs/apfs.c

APFS est un système de fichiers propriétaire implémenté par Apple qui a été rétro-ingénieré et est également pris en charge ici, mais Apple a considérablement renforcé ses politiques de sécurité.

Vous ne pourrez pas exécuter ffs sur votre disque principal sans désactiver SIP

SIP - protection d'intégrité du système est une fonctionnalité de sécurité spéciale qui interdit tout accès au superbloc du disque principal même en tant qu'utilisateur root. Vous ne pouvez pas le contourner même avec sudo ; vous devez désactiver cette fonctionnalité (vous l'avez peut-être déjà désactivée si vous utilisez des projets comme yabai).

Il existe un moyen de tester ffs sur le système de fichiers Apple sans toucher à votre disque principal - vous pouvez rechercher des fichiers .dmg bruts sans aucune permission élevée (oui, les installateurs d'applications sont simplement des volumes détachés). Avec ffs, vous n'avez pas besoin de monter quoi que ce soit, vous pouvez simplement lui donner un chemin vers les octets bruts d'un volume avec le type de système de fichiers :

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

Recherche dans des volumes détachés

Parce que ffs lit les octets directement, vous pouvez l'utiliser pour rechercher n'importe quel volume détaché sans le monter sur le système de fichiers. Ex. lire des fichiers .iso ou .dmg.

Vitesse

C'est la partie la plus amusante - ffs n'a pas accès au cache du système de fichiers VFS / noyau. C'est pourquoi il sera plus lent sur les répertoires plus petits (ou déjà mis en cache), mais progressivement plus rapide une fois que le cache est épuisé et que votre noyau doit aller lire l'état réel du disque.

Pourquoi ? Exactement pour prouver qu'à un certain point, le VFS du noyau devient une surcharge.

Voici le résultat de la comparaison entre ffs et ripgrep sur un système de fichiers btrfs monté. Notez que ripgrep utilise un moteur de correspondance et un parcours de fichiers basés sur SIMD bien plus avancés, alors que ffs n'est que ~1,8k lignes de code 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

Les indicateurs utilisés pour ripgrep sont -F --no-heading -H -n --no-ignore --hidden --one-file-system --no-messages - ce qui lui permet d'émettre les mêmes résultats que ffs.

Construire le projet

Tout ce dont vous avez besoin pour compiler le projet est libzstd pour btrfs, openmp dans votre pkg-config puis simplement

make ffs
ffs --help