Início / unix / Perguntas / 512362
Accepted
Ruslan
Asked: 2019-04-14 22:27:15 +0800 CST

Por que o tar parece pular o conteúdo do arquivo quando o arquivo de saída é /dev/null?

  • 772

Eu tenho um diretório com mais de 400 GiB de dados nele. Eu queria verificar se todos os arquivos podem ser lidos sem erros, então uma maneira simples que pensei foi tarem /dev/null. Mas, em vez disso, vejo o seguinte comportamento:

$ time tar cf /dev/null .

real    0m4.387s
user    0m3.462s
sys     0m0.185s
$ time tar cf - . > /dev/null

real    0m3.130s
user    0m3.091s
sys     0m0.035s
$ time tar cf - . | cat > /dev/null
^C

real    10m32.985s
user    0m1.942s
sys     0m33.764s

O terceiro comando acima foi parado à força por Ctrl+ Cdepois de já ter sido executado por um bom tempo. Além disso, enquanto os dois primeiros comandos estavam funcionando, o indicador de atividade do dispositivo de armazenamento que continha .estava quase sempre ocioso. Com o terceiro comando, o indicador fica constantemente aceso, o que significa extrema ocupação.

Então, parece que, quando taré capaz de descobrir que seu arquivo de saída é /dev/null, ou seja, quando /dev/nullé aberto diretamente para ter o identificador de arquivo no qual tarescreve, o corpo do arquivo aparece ignorado. (Adicionar vopção para tarimprimir todos os arquivos no diretório sendo tar'vermelho.)

Então eu me pergunto, por que isso é assim? É algum tipo de otimização? Se sim, então por que iria tarquerer fazer uma otimização tão duvidosa para um caso tão especial?

Estou usando o GNU tar 1.26 com glibc 2.27 no Linux 4.14.105 amd64.

tar null

2 respostas

  1. Best Answer

    É uma otimização documentada :

    Quando o arquivo está sendo criado para /dev/null, o GNU tar tenta minimizar as operações de entrada e saída. O sistema de backup Amanda, quando usado com GNU tar, tem um passo inicial de dimensionamento que usa esse recurso.

    • 25

  2. Isso pode acontecer com uma variedade de programas, por exemplo, eu tive esse comportamento uma vez ao usar apenas cp file /dev/null; em vez de obter uma estimativa da velocidade de leitura do meu disco, o comando retornou após alguns milissegundos.

    Tanto quanto me lembro, isso foi no Solaris ou AIX, mas o princípio se aplica a todos os tipos de sistemas unix-y.

    Antigamente, quando um programa copiava um arquivo para algum lugar, ele alternava entre readchamadas que pegavam alguns dados do disco (ou o que o descritor de arquivo está se referindo) para a memória (com a garantia de que tudo está lá quando readretorna) e writechamadas (que pegam o pedaço de memória e enviam o conteúdo para o destino).

    No entanto, existem pelo menos duas maneiras mais recentes de alcançar o mesmo:

    • Linux tem chamadas de sistema copy_file_range(não são portáteis para outros Unixes) e sendfile(um pouco portáteis; originalmente destinado a enviar um arquivo para a rede, mas pode usar qualquer destino agora). Eles se destinam a otimizar as transferências; se o programa usa um desses, é facilmente concebível que o kernel reconheça que o alvo é /dev/nulle transforme a chamada do sistema em um não-op

    • Os programas podem usar mmappara obter o conteúdo do arquivo em vez de read, isso basicamente significa "certifique-se de que os dados estejam lá quando tento acessar esse pedaço de memória" em vez de "certifique-se de que os dados estejam lá quando a chamada do sistema retornar". Assim, um programa pode mmapacessar o arquivo de origem e chamar writeesse pedaço de memória mapeada. No entanto, como a gravação /dev/nullnão precisa acessar os dados gravados, a condição "certifique-se de que está lá" nunca é acionada, resultando na não leitura do arquivo.

    Não tenho certeza se o gnut tar usa algum e qual desses dois mecanismos quando detecta que está escrevendo para /dev/null, mas eles são a razão pela qual qualquer programa, quando usado para verificar velocidades de leitura , deve ser executado com | cat > /dev/nullem vez de > /dev/null- e por que | cat > /dev/nulldeveria ser evitado em todos os outros casos.

    • 8

relate perguntas