Calcular quanto espaço em disco teria sido usado

Existe no Linux um programa que pode calcular quantos dados um programa produziria?

Por exemplo, se eu gostaria de fazer backup do meu banco de dados MySQL, eu normalmente faria

mysqldump > dumpfile.sql

Em vez disso, gostaria de redirecionar para, /dev/nullmas calcular quanto espaço em disco teria sido usado, como

mysqldump | fancy_space_calc_program

Saída:

123456789 Bytes would have been used

Note, o backup do MySQL é apenas um exemplo. Estou muito ciente de como eu poderia estimar o tamanho antes, então não faça comentários sobre isso.

linux disk-space

— fancyPants
fonte

Eu nem acho que você pode realmente fazer um; para casos específicos, sim, mas não para uso geral, porque como você pode estimar se algum aplicativo chama algum servidor e baixa dados a partir daí - não há chance de estimar essas coisas em aplicativos estrangeiros. Portanto, isso seria por aplicativo - conforme você escreve que já conhece o MYSQL - não há explicação, mas outros aplicativos - por aplicativo, nenhuma ferramenta geral poderia fazer essa previsão corretamente.

— Drako

Espero que você compreenda que qualquer tentativa de fazer a estimativa exigiria realmente executar o programa e observar a saída enquanto ela é enviada para algum lugar seguro. Isso será impossível se o programa tiver algum tipo de efeito irreversível em outra coisa, para que você possa executá-lo SOMENTE uma vez sem efeitos colaterais indesejados. O outro problema é que, se o programa deriva sua saída de uma entrada alterada, a próxima execução criará outro arquivo de saída (tamanho diferente). Por último, mas não menos importante: espaço em disco <> (bytes de saída). E vários sistemas de arquivos têm despesas gerais diferentes para contabilidade.

— Tonny 29/05

Sim, eu estou bem ciente disso. Ainda é bom o suficiente para mim.

— Fancypants

@Drako Você pode ter uma maneira geral de medir a saída de texto de um programa. Isso não precisa ser por aplicativo (veja, por exemplo, a resposta aceita). Se a saída de texto será ou não idêntica de maneira confiável nas execuções subseqüentes é específica do aplicativo, mas isso não impede que você mede a saída de maneira geral. Presumivelmente, o OP e qualquer outra pessoa que tentasse medir a saída o faria apenas se os dados fossem significativos para qualquer aplicativo.

— Jon Bentley

@ JonBentley, eu nunca disse que você não pode, leia com mais atenção: "como escrevi a previsão geral, não será preciso nem chegará nem perto :)" e agora imagine que meu aplicativo após a execução verificará atualizações de si mesmo, de plugins , etc e baixará x quantidade de dados da i-net e armazenará esses dados no seu disco rígido; como você avaliará com precisão com antecedência, com a ferramenta geral sem saber nada sobre meu aplicativo, quanto armazenamento será necessário após a execução? Ainda assim, você pode fazer o seu melhor palpite com a resposta aceita e, em muitos casos, até ser bastante preciso.

— Drako

Respostas:

Retirado de /programming/13418688/use-pipe-with-du-to-compute-size-of-stdin

Você pode canalizá-lo para wc -ccontar o número de bytes que passam pelo pipeline.

Obviamente, esses são apenas os bytes brutos e não têm nada a ver com o tamanho do setor, etc., então leve-o com um pouco de sal ...

— Magnus
fonte

como escrevi previsão geral não vai ser preciso ou até mesmo fechar :)

— Drako

Uma boa implementação do @cat wcdescartará os dados desnecessários assim que possível.

— Ruslan

@cat Eu acho que é improvável que seja armazenado em buffer, pois você não precisa de buffer para contar linhas ou caracteres. Os coreutils GNU wcno meu computador manipulam facilmente dados stdin de 40 GB, com apenas 8 GB de memória.

— Frxstrem 29/05

@Magnus. Eu acho que você perdeu o jogo de palavras. WC é um termo britânico para o que os americanos chamam de banheiro. Você está canalizando os dados não utilizados no WC.

— Fund Monica's Lawsuit

@Frxstrem Você certamente fazer necessidade de tamponamento para contar linhas ou caracteres - assim que você não está trabalhando com uma codificação isomorphic. Desde o POSIX.2, wc -cnão conta caracteres - conta bytes. wc -mconta caracteres. A diferença mais óbvia está nos caracteres de vários bytes, como no UTF-16 ou no Windows \r\n(dois bytes em ASCII, mas um caractere). Na maioria das vezes, não é necessário muito armazenamento em buffer, mas o Unicode pode ter uma quantidade arbitrária de bytes para representar um único caractere; não algo que você veria em dados confiáveis, mas um possível vetor de estouro de buffer.

— Luaan

O comando pv é perfeito para isso.

mysqldump | pv -b > /dev/null

Eu acho que o acima dará o comando certo que você deseja, pode precisar de alguns ajustes, como pv -b | > /dev/nullnão posso testar agora

-b fornece um valor em bytes.

— djsmiley2k - CoW
fonte

Santo, eu esqueci pv, bem como wc. Que vergonha. Eu gostaria de aceitar as duas respostas. Desculpe, mas Magnus foi um pouco mais rápido e ele pode usar a reputação.

— Fancypants

Sim, não se preocupe, o truque do wc é muito bom, não sei por que isso não me ocorreu imediatamente tbh. Eu fui primeiro 'bar!' então percebi o que eu quis dizer com pv! :)

— djsmiley2k - CoW

E agora você tem me perguntando sobre agarrar o identificador de arquivo, e verificação de um tamanho em algum lugar / proc ....

— djsmiley2k - Cow

Eu nunca ouvi falar de pvantes .. Você aprende algo novo a cada dia :)

— Magnus

@ Magnus: Eu acho que o wc é mais antigo (parte de alguns sistemas Unix mais antigos), não possui tanta documentação e (possivelmente como resultado) o pv está pré-instalado em menos distribuições. Ainda assim, é bom saber. Veja esta foto conceitualmente bela, que vem da página inicial do programa "pv" ("visualizador de tubos")

— TOOGAM

Você pode usar ddpara isso, assim cat /dev/zero | dd status=progress of=/dev/null bs=4M.

Isso fornece alguns dados durante e após a execução sobre a quantidade de dados transmitidos a ele, como:

$ cat /dev/zero | dd status=progress of=/dev/null                                                                                                                              
5371334656 bytes (5.4 GB, 5.0 GiB) copied, 4 s, 1.3 GB/s^C # this is progress data
12271136+0 records in #summary
12271135+0 records out #summary
6282821120 bytes (6.3 GB, 5.9 GiB) copied, 4.66683 s, 1.3 GB/s #summary

— mosca de isopor
fonte