Escrevi um ratarmount alternativo mais rápido , que "funciona para mim", porque esse problema continuava me incomodando.
Você pode usá-lo assim:
pip3 install --user ratarmount
ratarmount my-huge-tar.tar mount-folder
ls -la mount-folder # will show the contents of the tar top-level
Quando terminar, desmonte-o como qualquer montagem do FUSE:
fusermount -u mount-folder
Por que é mais rápido que o valor do arquivo?
Depende do que você mede.
Aqui está uma referência do espaço ocupado pela memória e do tempo necessário para a primeira montagem, bem como dos tempos de acesso para um cat <file-in-tar>comando simples e um findcomando simples .
Pastas contendo cada arquivo de 1k foram criadas e o número de pastas é variado.
O gráfico inferior esquerdo mostra as barras de erro indicando os tempos mínimo e máximo medidos cat <file>para 10 arquivos escolhidos aleatoriamente.
Tempo de busca do arquivo
A comparação matadora é o tempo que leva para cat <file>terminar. Por alguma razão, isso é escalonado linearmente com o tamanho do arquivo TAR (aproximadamente bytes por arquivo x número de arquivos) para o valor do arquivo enquanto permanece em tempo constante no valor do número de arquivo. Isso faz com que pareça que o arquivo nem sequer suporta a busca.
Para arquivos TAR compactados, isso é especialmente perceptível.
cat <file>leva mais que o dobro do tempo para montar o arquivo .tar.bz2 inteiro! Por exemplo, o TAR com 10k arquivos vazios (!) Leva 2,9s para montar com o arquivo morto, mas, dependendo do arquivo acessado, o acesso catleva entre 3ms e 5s. O tempo que leva parece depender da posição do arquivo dentro do TAR. Os arquivos no final do TAR levam mais tempo para procurar; indicando que a "busca" é emulada e todo o conteúdo do TAR antes da leitura do arquivo.
A obtenção do conteúdo do arquivo pode levar mais que o dobro do tempo, pois a montagem de todo o TAR é inesperada. Pelo menos, deve terminar na mesma quantidade de tempo que a montagem. Uma explicação seria que o arquivo está sendo procurado emularmente mais de uma vez, talvez até três vezes.
Parece que o Ratarmount sempre leva a mesma quantidade de tempo para obter um arquivo, pois suporta a busca verdadeira. Para TARs compactados bzip2, ele ainda procura o bloco bzip2, cujos endereços também são armazenados no arquivo de índice. Teoricamente, a única parte que deve ser dimensionada com o número de arquivos é a pesquisa no índice e que deve ser dimensionada com O (log (n)), porque é classificada por nome e caminho do arquivo.
Pegada na memória
Em geral, se você tiver mais de 20k arquivos dentro do TAR, o espaço de memória do ratarmount será menor porque o índice é gravado no disco à medida que é criado e, portanto, possui um espaço de memória constante de aproximadamente 30 MB no meu sistema.
Uma pequena exceção é o back-end do decodificador gzip, que por algum motivo exige mais memórias à medida que o gzip aumenta. Essa sobrecarga de memória pode ser o índice necessário para procurar dentro do TAR, mas é necessária uma investigação mais aprofundada, pois não escrevi esse back-end.
Por outro lado, o archivemount mantém todo o índice, por exemplo, 4 GB para arquivos de 2M, completamente na memória enquanto o TAR estiver montado.
Tempo de montagem
Meu recurso favorito é o ratarmount, capaz de montar o TAR sem demora perceptível em qualquer tentativa subsequente. Isso ocorre porque o índice, que mapeia nomes de arquivos para metadados e a posição dentro do TAR, é gravado em um arquivo de índice criado próximo ao arquivo TAR.
O tempo necessário para a montagem se comporta de maneira meio estranha no arquivo. A partir de aproximadamente 20k arquivos, ele começa a ser dimensionado quadraticamente em vez de linearmente em relação ao número de arquivos. Isso significa que, a partir de aproximadamente 4 milhões de arquivos, o ratarmount começa a ser muito mais rápido que o arquivemount, embora para arquivos TAR menores seja 10 vezes mais lento! Por outro lado, para arquivos menores, não importa muito se são necessários 1s ou 0,1s para montar o alcatrão (na primeira vez).
Os tempos de montagem dos arquivos compactados bz2 são os mais comparáveis em todos os momentos. Isso é muito provável porque está limitado pela velocidade do decodificador bz2. Ratarmount é aproximadamente 2x mais lento aqui. Espero fazer do ratarmount o vencedor claro, paralelizando o decodificador bz2 em um futuro próximo, que mesmo para o meu sistema de 8 anos de idade, poderia gerar uma aceleração de 4x.
Hora de obter metadados
Ao simplesmente listar todos os arquivos finddentro do TAR (a localização também parece chamar stat para cada arquivo !?), o ratarmount é 10x mais lento que o archivemount para todos os casos testados. Espero melhorar isso no futuro. Atualmente, porém, parece um problema de design devido ao uso de Python e SQLite em vez de um programa C puro.