Calcola la quantità di spazio su disco che sarebbe stata utilizzata

Esiste su Linux un programma in grado di calcolare quanti dati produrrebbe un programma?

Ad esempio, se vorrei fare il backup del mio database MySQL, di solito lo farei

mysqldump > dumpfile.sql

Invece vorrei reindirizzare /dev/nullma calcolare quanto spazio su disco sarebbe stato utilizzato, come

mysqldump | fancy_space_calc_program

Produzione:

123456789 Bytes would have been used

Nota, il backup di MySQL è solo un esempio. Sono ben consapevole di come potrei stimare le dimensioni in anticipo, quindi per favore non fare commenti a riguardo.

linux disk-space

— fancypants
fonte

Non penso nemmeno che tu possa davvero farne uno; per casi specifici sì, ma non per un utilizzo generale, perché come è possibile stimare se alcune app chiamano alcuni server e scaricano dati da lì - nessuna possibilità è possibile stimare tali cose in app straniere. Quindi questo sarebbe per app - mentre scrivi che conosci già per MYSQL - nessuna spiegazione lì, ma altre app - per app, nessuno strumento generale potrebbe fare correttamente questa previsione.

— Drako,

Spero che ti renda conto che qualsiasi tentativo di effettuare la stima richiederebbe di eseguire effettivamente il programma e osservare l'output mentre viene inviato in un luogo sicuro. Questo sarà impossibile se il programma ha una sorta di effetto irreversibile su qualcos'altro in modo da poterlo eseguire SOLO una volta senza effetti collaterali indesiderati. L'altro problema è che se il programma deriva il suo output da un input in modifica, la prossima esecuzione creerà un altro file di output (di dimensioni diverse). Ultimo ma non meno importante: diskspace <> (byte di output). E vari filesystem hanno diverse spese generali per la contabilità.

— Tonny,

Sì, ne sono ben consapevole. È ancora abbastanza buono per me.

— fancyPants

@Drako Puoi avere un modo generale di misurare l'output del testo di un programma. Non è necessario che ciò avvenga per app (vedere ad esempio la risposta accettata). Se l'output del testo sarà affidabile o identico nelle esecuzioni successive è specifico dell'app, ma ciò non impedisce di misurare l'output in modo generale. Presumibilmente l'OP e chiunque tentasse di misurare l'output lo farebbe solo se i dati fossero significativi per una determinata applicazione.

— Jon Bentley,

@JonBentley Non ti ho mai detto che non puoi averlo, leggi più attentamente: "come ho scritto la previsione generale non sarà precisa o nemmeno vicina :)" e ora immagina che la mia app dopo l'esecuzione controllerà gli aggiornamenti di se stessa, dei plugin , ecc. e scaricherà x quantità di dati da i-net e li memorizzerà sul tuo hdd; come misurerai in anticipo con precisione con uno strumento generale che non sa nulla della mia app, quanto spazio di archiviazione sarà necessario dopo averlo eseguito? Puoi comunque fare la tua ipotesi migliore con una risposta accettata e in molti casi anche essere abbastanza preciso.

— Drako,

Risposte:

Tratto da /programming/13418688/use-pipe-with-du-to-compute-size-of-stdin

È possibile reindirizzarlo wc -cper contare il numero di byte che attraversano la pipeline.

Naturalmente, questi sono solo i byte grezzi, e non hanno nulla a che fare con le dimensioni del settore ecc., Quindi prendilo con un granello di sale ...

— Magnus
fonte

come ho scritto, la previsione generale non sarà precisa o nemmeno vicina :)

— Drako,

@cat una buona implementazione di scarterà i wcdati di cui non ha più bisogno non appena pratico.

— Ruslan,

@cat Penso che sia improbabile che sia bufferizzato, poiché non è necessario il buffering per contare righe o caratteri. I coreutils GNU wcsul mio computer gestiscono facilmente i dati stdin da 40 GB, con solo 8 GB di memoria.

— Frxstrem,

@Magnus. Penso che ti sia perso il gioco di parole. WC è un termine britannico per quello che gli americani chiamano bagno. Stai trasferendo i dati non utilizzati nel WC.

— Fondi Monica's Lawsuit,

@Frxstrem Certamente fare necessità di buffering per contare le linee o caratteri - non appena non è più sta lavorando con una codifica isomorfi. Da POSIX.2, wc -cnon conta i caratteri - conta i byte. wc -mconta i personaggi. La differenza più evidente è nei caratteri multi-byte come in UTF-16 o Windows \r\n(due byte in ASCII, ma un carattere). Non richiede necessariamente un sacco di buffering per la maggior parte del tempo, ma Unicode può avere una quantità arbitraria di byte per rappresentare un singolo carattere; non qualcosa che vedresti nei dati affidabili, ma un possibile vettore di overflow del buffer.

— Luaan,

Il comando pv è perfetto per questo.

mysqldump | pv -b > /dev/null

Penso che quanto sopra ti darà il comando giusto che desideri, potrebbe essere necessario un aggiustamento pv -b | > /dev/nullcome non posso testare in questo momento

-b ti dà un valore in byte.

— djsmiley2k - CoW
fonte

Santo, mi ero dimenticato del pv e del wc. Mi vergogno. Vorrei accettare entrambe le risposte. Quindi, scusa, ma Magnus è stato un po 'più veloce e può usare la reputazione.

— fancyPants

Sì, non preoccuparti, il trucco del wc è davvero carino, non so perché non mi sia subito venuto in mente. Per prima cosa sono andato a "bar!" poi ho capito cosa intendevo dire pv! :)

— djsmiley2k - CoW,

E ora mi stai chiedendo come afferrare l'handle del file e controllare una dimensione in / proc da qualche parte ....

— djsmiley2k - CoW

Non ne ho mai sentito parlare pvprima .. Ogni giorno impari qualcosa di nuovo :)

— Magnus,

@Magnus: penso che wc sia più vecchio (parte di alcuni vecchi sistemi Unix), non in tanta documentazione, e (molto probabilmente come risultato) pv è preinstallato in meno distribuzioni. Comunque, bello da sapere. Guarda questa immagine concettualmente bella che viene dalla home page del programma "pv" ("pipe viewer")

— TOOGAM

Puoi usarlo dd, in questo modo cat /dev/zero | dd status=progress of=/dev/null bs=4M.

Questo ti fornisce alcuni dati durante e dopo l'esecuzione sulla quantità di dati passati ad esso, come:

$ 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

— polistirolo volare
fonte