Devo colocar projetos antigos em tarballs

Question

Eu nunca usei muito tarballs / arquivou muito, exceto para uploads (com compressão). Agora eu acumulei uma lista enorme de projetos de software codificando experimentos - basicamente diretórios com muitos e pequenos arquivos (principalmente arquivos de código-fonte e objetos git), e parece que eles parecem retardar as coisas quando eu estou fazendo o backup minha casa ou sincronizando com outro dispositivo (eu principalmente sincronizo através de um cabo USB, com rsync).

Eu me pergunto, isso é um fenômeno documentado (benchmarks?) e tarballing diretórios de projetos longos e intocados acelera as coisas? Isso seria aconselhável?

Estou usando sistemas de arquivos ext4.

    

Answer 1

Arquivar diretórios antigos que você raramente acessa como tarballs pode definitivamente melhorar o desempenho de um sistema de backup baseado em arquivos.

I wonder, is this a documented phenomenon (benchmarks?)

Não é realmente um "fenômeno documentado", mas uma consequência natural de ter que varrer o sistema de arquivos e examinar cada arquivo, um por um, para determinar se é necessário fazer o backup.

Você pode reduzir a frequência de backups, conforme Faheem Mitha sugere. , mas você pode achar problemático manter vários backups em freqüências diferentes (para coisas frequentemente atualizadas e coisas antigas arquivadas) ou para manter listas de exclusões de arquivos e coisas do tipo. Se você realmente não planeja precisar de acesso a esses diretórios tão cedo, eu acho que é uma ótima idéia atualizá-los. Eu fiz isso muitas vezes exatamente pela mesma razão.

    

Answer 2

O Rsync precisa verificar todos esses arquivos e pastas a cada vez. Isso leva tempo, desempenho e carga de rede. Se você colocar cada projeto em um tarball, isso significa uma verificação de arquivo em vez de milhares de verificações. Também economiza espaço.

    

Answer 3

Eu executei um pequeno benchmark em um diretório de repositórios clonados - muitos arquivos pequenos.

Aqui estão os parâmetros:

17002 files
4.9G
46 root directories 
tar command: tar cf (no compression)
rsync command: rsync -aH --delete --stats 

E os resultados:

Rsync local para um diretório vazio (arquivos descompactados):

real    5m36.447s
user    0m34.692s
sys     0m56.390s

Second local rsync (unpacked files):
real    0m6.810s
user    0m2.257s
sys     0m3.363s

Tempo de captura:

real    1m14.648s
user    0m14.278s
sys     0m2.175s

Rsync local para um diretório vazio (arquivos descompactados):

real    2m6.355s
user    0m20.799s
sys     0m21.122s

Rsync local para um diretório vazio (arquivos compactados):

real    0m0.125s
user    0m0.005s
sys     0m0.011s

Assim, parece que o asfalto melhora significativamente o desempenho. O que é surpreendente é que o tarring + o segundo rsync local reúne menos tempo que o primeiro rsync local.

O

Tarring também aumenta significativamente a velocidade de execuções de rsync sem operação.

Eu também tentei tarring com compressão. Tarring com gzip demorou cerca de 10 minutos, lzop não fez muito melhor (parei em cerca de 7 minutos). De acordo com o bom gráfico no link , a compactação não melhorará minha largura de banda se o link mais lento Eu vou estar usando é um cabo USB (aprox. 20MBps).