Concatena vários arquivos tar em um comando

Question

Eu recebo de 4 a 100 arquivos compactados de tar (~ 20GB) muito grandes todos os dias. Eu tenho concatenado-los no passado por looping através de cada um dos arquivos que vejo no sistema de arquivos e fazendo algo parecido com isto

/bin/tar -concatenate --file=allTars.tar receivedTar.tar

O problema com isso, no entanto, é que ao concatenar mais e mais arquivos tar, ele deve ler até o final de allTars.tar para começar a concatenar novamente. Às vezes, leva mais de 20 minutos para começar a adicionar outro arquivo tar. É muito lento e estou perdendo um prazo de entrega acordado de todo o allTars.tar .

Eu também tentei entregar ao meu comando tar uma lista de arquivos assim:

/bin/tar --concatenate --file=alltars.tar receiverTar1.tar receivedTar2.tar receivedTar3.tar...etc

Isso deu resultados muito estranhos. allTars.tar seria o tamanho esperado (ou seja, perto de todos os tamanhos dos arquivos receivedTar.tar somados), mas parecia sobrescrever os arquivos quando allTars.tar foi descompactado.

Existe alguma maneira de concatenar todos esses arquivos tar em um comando ou então ele não precisa ler até o final do arquivo sendo concatenado a cada vez e tê-los descompactado corretamente e com todos arquivos / dados?

    

Answer 1

Isso pode não ajudar, mas se você estiver disposto a usar a opção -i ao extrair do arquivo final, poderá simplesmente cat os tars juntos. Um arquivo tar termina com um cabeçalho cheio de nulos e mais preenchimento nulo até o final do registro. Com --concatenate tar deve passar por todos os cabeçalhos para encontrar a posição exata do cabeçalho final, para começar a sobrescrever lá.

Se você apenas cat os tars, você só terá nulos extras entre os cabeçalhos. A opção -i pede ao tar para ignorar esses nulos entre os cabeçalhos. Então você pode

cat  receiverTar1.tar receivedTar2.tar ... >>alltars.tar
tar -itvf alltars.tar

Além disso, o seu exemplo tar --concatenate deve estar funcionando. No entanto, se você tiver o mesmo arquivo nomeado em vários arquivos tar você irá reescrever esse arquivo várias vezes quando extrair todos do tar resultante.

    

Answer 2

Essa pergunta é bem antiga, mas eu gostaria que tivesse sido mais fácil encontrar as informações a seguir mais cedo. Então, se alguém mais se deparar com isso, aproveite:

O que Jeff descreve acima é um bug conhecido no gnu tar (reportado em agosto de 2008). Apenas o primeiro arquivo (aquele após a opção -f ) obtém seu marcador EOF removido. Se você tentar concatenar mais de dois arquivos, o (s) último (s) arquivo (s) será (ão) ocultado (s) por trás dos marcadores de fim de arquivo.

It is a bug in tar. It concatenates entire archives, including trailing zero blocks, so by default reading the resulting archive stops after the first concatenation.

Source: https://lists.gnu.org/archive/html/bug-tar/2008-08/msg00002.html (and following messages)

Considerando a idade do bug, eu me pergunto se ele será consertado. Eu duvido que haja uma massa crítica afetada.

A melhor maneira de contornar este bug pode ser usar a opção -i , pelo menos para arquivos .tar no seu sistema de arquivos.

Como Jeff aponta, tar --concatenate pode levar muito tempo para alcançar o EOF antes de concatenar o próximo arquivo. Então, se você estiver preso a um arquivo "quebrado" que precisa da opção tar -i para descompactar, sugiro o seguinte:

Em vez de usar %código% provavelmente será melhor executar tar --concatenate -f archive1.tar archive2.tar archive3.tar ou redirecionar para cat archive2.tar archive3.tar >> archive1.tar se você pretende gravar em um dispositivo de fita. Note também que isso pode levar a um comportamento inesperado se as fitas não forem zeradas antes de escrever novos dados nelas. Por essa razão, a abordagem que vou tomar na minha aplicação é o tars aninhado, como sugerido nos comentários abaixo da pergunta.

A sugestão acima é baseada no seguinte exemplo de referência muito pequeno:

time tar --concatenate -vf buffer.100025.tar buffer.100026.tar
  real  65m33.524s
  user  0m7.324s
  sys   2m50.399s

time cat buffer.100027.tar >> buffer.100028.tar
  real  46m34.101s
  user  0m0.853s
  sys   1m46.133s

Os arquivos buffer. *. tar são todos de tamanho de 100 GB, o sistema estava praticamente inativo, exceto para cada uma das chamadas. A diferença de tempo é significativa o suficiente para que eu pessoalmente considere este benchmark válido apesar do pequeno tamanho da amostra, mas você está livre para seu próprio julgamento sobre isso e provavelmente melhor para executar um benchmark como este em seu próprio hardware.

    

Answer 3

Como você afirmou, o arquivo de destino deve ser lido até o final antes que o segundo arquivo de origem seja anexado a ele. O tar GNU tem uma opção -n que instrui para assumir que um arquivo é procurado (lembre-se que o tar era um design para arquivos de fita e fluxo que não são procurados). O padrão GNU tar supostamente detecta automaticamente se um arquivo é procurado, porém muitos usuários como você podem garantir que o tar pule a leitura de cada conteúdo completo dos registros, adicionando a opção -n :

tar -n --concatenate --file=target_file.tar  other_file.tar

Não é possível verificar (no momento da gravação) quais versões do tar, se houver, serão executadas conforme o esperado para esse comando. Se outros usuários tiverem a capacidade de provar essa solução, comente abaixo e atualizarei a resposta de acordo.

    

Answer 4

Como a concatenação é intensiva em I / O, recomendo que 3 SSD (1tb) em um RAID 0 seja necessário. Um único SSD no sata 3 fornecerá 500MB / s como leitura e similar para gravação. Caro, sim, mas rápido x3.