No momento, estou usando ArchiveMountpara montar um arquivo de 123.000 kb que contém mais de 3 milhões de arquivos. Até agora, ele está montado há mais de 5 horas e ainda não está concluído.

Existe uma maneira melhor de montar um .tar.gzarquivo? Estou tentando montar em uma pasta e descompactado leva alguns shows. Eu nem preciso do modo de gravação, apenas a leitura é suficiente.

Você também pode criar uma imagem de squashfs compactada

mksquashfs /etc squashfs.img -comp xz
mkdir img
mount -o squashfs,ro squashfs.img img

Para fazer isso, você precisará extrair seu arquivo tar.gz.

A vantagem também é que a imagem tem melhor tolerância a falhas do que gz.

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.

O problema aqui é com o formato, o formato TAR (Tape ARchive) foi projetado para acesso seqüencial, e não aleatório. E o gzip é um bom complemento para o tar, pois é um formato de compactação baseado em fluxo, também não para acesso aleatório.

Portanto, uma ferramenta de alto nível que não interage diretamente com os blocos compactados terá que analisar todo o arquivo toda vez que precisar ler algo, primeiro para obter a lista de arquivos, talvez o cache seja invalidado e o leia novamente. e, para cada arquivo copiado, ele poderá ser lido novamente. Você pode criar uma ferramenta que se lembre da posição de cada arquivo e de quais blocos ela precisa descompactar para obtê-lo, mas parece que poucos se importaram com isso.

Se você quiser que isso aconteça mais rapidamente, tar tzf file.tar.gz > filelistabra a lista de arquivos no vim , gedit ou qualquer outra coisa, remova as linhas de arquivos que você não precisa, salve e depois as extraia tar xzf file.tar.gz -T filelist -C extracted/.

Para obter acesso aleatório a um arquivo compactado, você deve usar talvez zip com extensões posix, rar ou, como sugerido pelo dru8274, squashfs ou mesmo ZFS com a compactação ativada, ou btrfs se o btrfs tiver conseguido que a compactação funcione no momento da leitura.

Isso não cobrirá todos os casos de uso, pois restringe o uso a um editor de texto. Mas, se você se importa apenas com acesso de leitura, pode ser útil para algumas situações. vim, quando executado em um tarball, mostrará a hierarquia de conteúdo do arquivo morto (semelhante à maneira como ele exibirá uma hierarquia de arquivos se executado em um diretório). Ao selecionar um dos arquivos na lista, ele abrirá o arquivo selecionado em um buffer somente leitura.

Novamente, isso não oferece necessariamente acesso a imagens ou outras mídias, mas se tudo o que você precisa é ver o conteúdo ou acessar apenas arquivos baseados em texto, isso deve ser útil.

Nota : isso não funcionará em todos os formatos de arquivo.

Minha abordagem. Se você tiver espaço livre em disco suficiente em uma unidade USB externa ou unidade de disco rígido externa / secundária com espaço suficiente, considere apenas extrair o arquivo .tar.gz. Pensando que você provavelmente não quer 3 milhões de arquivos no disco principal do sistema, pois isso pode atrasar as coisas. Eu recomendo que o disco externo, neste caso, tenha um sistema de arquivos que lide com um grande número de arquivos facilmente: pensando em ReiserFS, ext4 (com opção dir_index), XFS, talvez BtrFS. Pode levar de uma a duas horas para fazer o extrato, mas você pode almoçar enquanto isso ou deixá-lo funcionar durante a noite; quando você voltar, o acesso aos arquivos extraídos deve ter bom desempenho.