Sistema de ficheiros com mil milhões de ficheiros
Levar um sistema de ficheiros Linux a conter mil milhões de ficheiros vazios torna-se um teste de stress à sobrecarga de metadados, à indexação de diretórios e aos limites das ferramentas, em vez de à capacidade de armazenamento bruta. Os comentadores comparam ext4, XFS, btrfs, ReiserFS, ZFS e NTFS sob cargas intensas de ficheiros pequenos, apontando problemas como inodes inchados, operações de diretório lentas e tempos de eliminação patológicos. Muitos defendem que bases de dados ou formatos como SQLite, sistemas de ficheiros especializados ou esquemas alternativos (por exemplo, diretórios fragmentados ou sistemas FUSE/virtuais) são frequentemente mais adequados do que sistemas de ficheiros de uso geral para cargas de trabalho com milhões ou milhares de milhões de objetos pequenos.
Rust vs shell/Python para esta tarefa
- Vários comentários observam que o programa em Rust é conceitualmente simples (alguns
execs e um ciclo) e poderia ser reproduzido num pequeno script de shell. - Outros argumentam que as vantagens do Rust aparecem em desempenho, paralelismo e manutenção quando os conjuntos de dados são grandes (por exemplo, milhões de URLs), mesmo que um protótipo rápido em bash/Python seja mais curto.
- Alguns sugerem separar o “mkfs/mount” da lógica em Rust para se alinhar com “fazer uma coisa bem feita”.
Comportamento do sistema de ficheiros com diretórios enormes
- Criar mil milhões de ficheiros num único diretório é visto como um caso distinto de stress; a pesquisa e a listagem do diretório tornam-se os principais estrangulamentos.
- São partilhados benchmarks de
lsem 1M–10M ficheiros; a listagem não ordenada (ls -U) e a saída numa única coluna (-1) são dramaticamente mais rápidas do que olspor omissão. - A indexação htree do ext4 reduz problemas de escalabilidade do lado do kernel, mas ferramentas de espaço de utilizador que carregam diretórios inteiros para a memória continuam a comportar-se mal.
Sobrecarga de espaço e metadados
- A sobrecarga por ficheiro do ext4 (~296 bytes para um ficheiro vazio aqui) está ligada principalmente ao tamanho do inode (256 bytes por omissão) mais o diretório e outros metadados.
- Inodes menores (por exemplo, 128 bytes) podem reduzir isto para metade, mas reintroduzem limites de timestamp de 32 bits/Y2038.
- Alguns sistemas especializados (por exemplo, SeaweedFS) afirmam ter metadados por ficheiro muito mais baixos.
Experiências do mundo real com muitos ficheiros pequenos
- Várias anedotas: simulações que produzem mais de 100k ficheiros pequenos, diretórios NTFS com milhões de ficheiros a tornarem-se dolorosamente lentos para apagar ou copiar, e sistemas Linux a comportarem-se de forma estranha com dezenas de milhares de ficheiros por diretório.
- Um caso descreve estruturas de hash de diretório do ext4 a crescerem tanto ao longo de milhares de milhões de churns de ficheiros que aparece ENOSPC apesar de haver muito espaço livre, o que motivou a mudança para XFS.
Melhor abordagem de armazenamento: FS vs DB vs FS especializado
- O consenso: sistemas de ficheiros de uso geral não são “ótimos” para enormes quantidades de ficheiros minúsculos.
- Bases de dados (SQLite/Postgres) muitas vezes superam sistemas de ficheiros para muitos objetos pequenos; mover um ficheiro de BD é muito mais fácil do que mover milhões de ficheiros.
- Armazenamentos de objetos ou formatos só de leitura (SquashFS) são sugeridos quando apropriado.
- O ReiserFS historicamente destacava-se com ficheiros pequenos; Btrfs e outros têm otimizações, mas continuam a existir trade-offs.
Abordagens e dicas alternativas
- As sugestões incluem um sistema de ficheiros FUSE que expõe virtualmente mil milhões de ficheiros sem os criar de facto.
- São partilhados vários padrões de linha de comandos (
ls -U1 | wc -l,find ... -printf) e referências a getdents() para tratar diretórios grandes de forma mais eficiente. - Parte da discussão aborda ZFS, Hammer2 e os trade-offs semânticos e de desempenho mais amplos entre “sistema de ficheiros vs base de dados”.