Comandos de tubulação com saída muito grande

Quando o produtor de dados ( tar) tenta escrever no pipe rápido demais para que o consumidor ( lzip) tenha tempo de ler tudo, ele bloqueia até lzipter tempo de ler o que tarestá escrevendo. Há um pequeno buffer associado ao pipe, mas seu tamanho provavelmente será menor do que o tamanho da maioria dos tararquivos. Não há risco de encher a RAM do seu sistema com seu pipeline.

"Bloquear" significa simplesmente que, quando taruma chamada para a write()função de biblioteca (ou equivalente), a chamada não retornará até que os dados sejam entregues ao buffer do pipe, o que pode levar um pouco de tempo se lzipfor lento para ler a partir desse mesmo tampão. Você deve ser capaz de ver isso em toponde tarficaria mais lento e dormiria muito em comparação com lzip(supondo que tarseja de fato mais rápido que lzip).

Portanto, você não preencheria uma quantidade significativa de RAM com seu pipeline. Para fazer isso (se você quiser), você pode usar algo como pvno meio, com algum buffer grande (aqui, um gigabyte):

tar -cvf - /tmp/source-dir | pv --buffer-size 1G | lzip -o /media/my-usb/result.lz -

Isso ainda bloquearia tarsempre que pvbloquear. pvbloquearia quando seu buffer estivesse cheio e não pudesse gravar em lzip.

A situação inversa funciona de maneira semelhante, ou seja, se você tiver um lado esquerdo lento de um pipe escrevendo para um lado direito rápido, o consumidor à direita bloquearia read()até que houvesse dados para serem lidos do pipe.

Essa (E/S de dados) é a única coisa que sincroniza os processos que fazem parte de um pipeline. Além de ler e escrever (e ocasionalmente bloquear enquanto espera que alguém leia ou escreva), eles funcionariam independentemente um do outro.

O GNU tar tem a opção --lzip para "filtrar o arquivo através do lzip ", então você pode querer usar:

tar -cvf --lzip /media/my-usb/result.lz /tmp/source-dir

Respondendo à pergunta: no seu caso, o sistema gerenciará o pipe corretamente usando o tamanho padrão do buffer do sistema.