dmtrkovalenko/ffsF*ck file system - ferramenta de busca de arquivos em CLI que contorna o kernel do SO e lê seu disco diretamente
Esta é uma ferramenta de linha de comando para pesquisar arquivos (como o grep) que não usa o kernel do SO para ler arquivos, mas lê seus discos diretamente. É praticamente inútil, mas incrivelmente legal.
são apenas ~1.5k linhas de código C que:
/dev/rdisk*); pesquisar um arquivo de imagem não precisa de permissões elevadassync manual)mas ao mesmo tempo
read(), em vez disso usa pread diretamente no dispositivo de blocoPara a pesquisa rápida de arquivos que realmente funciona, confira meu projeto fff - ele supera significativamente o ripgrep sem precisar de sudo.
no linux, quase qualquer sistema de arquivos é fácil de implementar
Este é o sistema de arquivos mais fácil de suportar: é um sistema de arquivos com journaling que grava no lugar (sem copy-on-write), então na maioria das vezes este é o melhor sistema de arquivos para o ffs. Às vezes você pode perceber que o ffs não consegue ver algumas atualizações recentes nos arquivos; isso pode acontecer se o kernel estiver mantendo atualizações recentes no cache e adiando gravações para o disco. Você pode forçar a sincronização usando
sync
O sistema de arquivos B-tree é significativamente mais complicado, é um armazenamento de arquivos mais eficiente e vem com uma limitação adicional:
Quando qualquer arquivo no seu sistema de arquivos é atualizado, todo o superbloco também precisa de uma atualização, o que significa que, se o ffs ler o superbloco (a árvore B de alto nível) e depois o kernel atualizar a árvore - toda a leitura se torna inválida.
Isso pode ser contornado usando fsfreeze ou criando um volume separado e desmontado.
APFS é um sistema de arquivos proprietário implementado pela Apple que foi engenharia reversa e também é suportado aqui, mas a Apple aumentou significativamente suas políticas de segurança.
Você não conseguirá executar o ffs no seu disco principal sem desabilitar o SIP
SIP - Proteção de Integridade do Sistema é um recurso de segurança especial que proíbe qualquer acesso ao superbloco do disco principal, mesmo como usuário root. Você não pode contorná-lo mesmo com sudo; você precisa desabilitar este recurso (você pode já tê-lo desabilitado se usar projetos como yabai).
Há uma maneira de testar o ffs no sistema de arquivos da Apple sem tocar no disco principal - você pode pesquisar arquivos .dmg brutos sem nenhuma permissão elevada (sim, os instaladores de aplicativos são apenas volumes desmontados). Com o ffs você não precisa montar nada, basta fornecer o caminho para os bytes brutos de um volume junto com o tipo de sistema de arquivos:
ffs "<QUERY>" /path/to/volume.dmg apfs
Como o ffs lê bytes diretamente, você pode usá-lo para pesquisar qualquer volume desmontado sem montá-lo no sistema de arquivos. Ex.: lendo arquivos .iso ou .dmg.
Esta é a parte mais engraçada - o ffs não tem acesso ao cache do sistema de arquivos VFS/kernel. É por isso que será mais lento em diretórios menores (ou já em cache), mas progressivamente mais rápido quando o cache se esgota e seu kernel tem que ir e ler o estado real do disco.
Por quê? Exatamente para provar que em algum momento o VFS do kernel se torna uma sobrecarga.
Este é o resultado da pesquisa comparando ffs com ripgrep em uma unidade montada como btrfs. Observe que ripgrep usa um correspondente e caminhador de arquivos baseado em SIMD muito mais avançado, enquanto ffs tem apenas ~1.8k linhas 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
As flags usadas para ripgrep são -F --no-heading -H -n --no-ignore --hidden --one-file-system --no-messages - que o fazem emitir os mesmos resultados que ffs.
Tudo que você precisa para compilar o projeto é libzstd para btrfs, openmp no seu pkg-config, então simplesmente
make ffs
ffs --help