Ferramenta de arquivamento mais rápida (não compactada) do que tar?

Question

Estou usando o tar para arquivar um monte de arquivos na fita LTO-7. Geralmente, cada arquivo tem cerca de 1 a 2 GB, e pode haver várias centenas deles em cada arquivo (até ~ 1 TB por arquivo).

No momento, estou arquivando usando:

tar -cvf /dev/nst0 --totals --warning=no-file-changed $OLDEST_DIR

Isso está me levando a cerca de 90 MBps de um disco que deve ser capaz de aproximadamente três vezes (e a fita deve ter capacidade de 2-3 vezes isso). Olhando de perto, parece que estou ligado à CPU, pois o tar está recebendo 100% de uma CPU.

Isso é particularmente irritante, já que estou tentando verificar se o arquivo tem o tamanho certo primeiro fazendo isso

tar -cP --warning=no-file-changed $OLDEST_DIR | wc -c

... e depois comparando os tamanhos dos arquivos produzidos.

Então, existe alguma maneira mais rápida?

    

Answer 1

A taxa de transferência de dados da CPU x86-64 é da ordem de 64GB / s, então não acho que seja esse o seu problema. Isso é mesmo x86-64 Linux ou outra coisa? Muito provavelmente o problema é que algum trabalho da CPU é feito por transação, e está usando blocos muito pequenos. Experimente:

strace -fo /tmp/tar.rw.txt -eread,write tar -cvf /dev/nst0 --totals --warning=no-file-changed $OLDEST_DIR

Para ver o que o tar deseja fazer com o bloqueio na E / S no arquivo /tmp/tar.rw.txt resultante. Muito provavelmente você vai encontrá-lo lendo e escrevendo blocos de 10KB. Você pode consertar isso com o -b flag, que supostamente é 20. Eu aposto que seu hardware pode manipular E / S nos megabytes, e seu SO irá dividi-lo novamente se não puder, então tente -b $[1024*2*32] para Transações de 32 MB.

Em seguida, você deve verificar o que o sistema operacional deseja fazer com as transações. Experimente o tar com o novo valor -b , verifique se você tem sysstat instalado e, enquanto ele estiver em execução, verifique iostat -xm 4 e assista aos contadores. A principal coisa a prestar atenção é a coluna 'avgrq-sz'. Se não houver divisões, isso deve ser cerca de 64.000. Se estiver dividindo, seu sistema operacional pensa que não pode ler ou gravar tantos bytes em uma transação. Esse é um tópico em si, mas você pode rapidamente aumentar os limites marcando a unidade (acho que nst0 deve estar lá), e

cd /sys/block/nst0/queue
cat max_hw_sectors_kb > max_sectors_kb'

e o mesmo com todas as camadas do disco que você está lendo (incluindo camadas lvm e dm). É crítico que você aumenta max_sectors_kb do nível mais baixo (sda) primeiro e o nível mais alto (ex. Dm23) por último. Verifique recursivamente por /sys/block/<dm>/holders/*/holders/*/.... .

Agora, com essas novas configurações, você precisa ter cuidado com duas coisas. Uma é md5sum os arquivos originais, tar e untar da fita, e verifique os md5sums para ter certeza de que os arquivos ainda estão sendo gravados corretamente. -b não deveria causar um problema como esse, mas eu não testei o seu hardware de fita, etc. O segundo é ter certeza de que você não está com pouca memória RAM por causa dos maiores tamanhos de transação. Você pode precisar fazer com certeza o sysctl vm.min_free_kbytes é muito grande, porque se ele acabar durante uma transação de disco, coisas realmente ruins acontecem.