Oblicz, ile miejsca na dysku zostałoby wykorzystane

Czy w systemie Linux jest program, który może obliczyć, ile danych mógłby wytworzyć program?

Na przykład, jeśli chciałbym wykonać kopię zapasową bazy danych MySQL, zwykle tak robię

mysqldump > dumpfile.sql

Zamiast tego chciałbym przekierować na, /dev/nullale obliczyć, ile miejsca na dysku byłoby wykorzystane, na przykład

mysqldump | fancy_space_calc_program

Wydajność:

123456789 Bytes would have been used

Uwaga: kopia zapasowa MySQL jest tylko przykładem. Doskonale zdaję sobie sprawę z tego, jak mogłem wcześniej oszacować rozmiar, więc proszę nie komentować tego.

linux disk-space

— wymyślne majtki
źródło

Nie sądzę nawet, żebyś mógł naprawdę taki zrobić; w szczególnych przypadkach tak, ale nie do ogólnego użytku, ponieważ jak można oszacować, czy jakaś aplikacja wywołuje jakiś serwer i pobiera stamtąd dane - nie ma szans, aby oszacować takie rzeczy w zagranicznych aplikacjach. Byłoby to na aplikację - jak piszesz, że już znasz MYSQL - nie ma tam żadnego wyjaśnienia, ale inne aplikacje - na aplikację, żadne ogólne narzędzie nie mogłoby poprawnie przewidzieć takiej prognozy.

— Drako

Mam nadzieję, że zdajesz sobie sprawę, że każda próba oszacowania wymagałaby uruchomienia programu i obserwowania wyniku, gdy jest on wysyłany w bezpieczne miejsce. Będzie to niemożliwe, jeśli program będzie miał jakiś nieodwracalny wpływ na coś innego, więc można go uruchomić TYLKO raz bez niezamierzonych skutków ubocznych. Innym problemem jest to, że jeśli program zacznie uzyskiwać dane wyjściowe ze zmieniającego się wejścia, w następnym uruchomieniu utworzony zostanie inny plik wyjściowy (o innym rozmiarze). Na koniec: przestrzeń dyskowa <> (bajty danych wyjściowych). Różne systemy plików mają różne koszty ogólne związane z księgowością.

— Tonny

Tak, jestem tego świadomy. Nadal jest dla mnie wystarczająco dobry.

— fancyPants

@Drako Możesz mieć ogólny sposób mierzenia wyniku tekstowego programu. Nie musi to dotyczyć jednej aplikacji (patrz np. Zaakceptowana odpowiedź). To, czy tekst będzie niezawodnie identyczny w kolejnych uruchomieniach, zależy od aplikacji, ale nie przeszkadza to w ogólnym pomiarze wyniku. Przypuszczalnie OP i ktokolwiek inny, próbujący zmierzyć wynik, zrobiłby to tylko, gdyby dane miały znaczenie dla dowolnej aplikacji.

— Jon Bentley

@JonBentley Nigdy nie mówiłem, że nie możesz go mieć, czytaj uważniej: „jak napisałem, ogólne przewidywania nie będą dokładne ani nawet bliskie :)” i teraz wyobraź sobie, że moja aplikacja po uruchomieniu sprawdzi dostępność aktualizacji wtyczek , itp. i pobierze x danych z i-net i zapisze je na dysku twardym; jak zamierzasz dokładnie zmierzyć z wyprzedzeniem za pomocą ogólnego narzędzia, które nie wie nic o mojej aplikacji, ile miejsca będzie potrzebne po uruchomieniu? Nadal możesz zgadywać z zaakceptowaną odpowiedzią, a w wielu przypadkach nawet być dość precyzyjnym.

— Drako

Odpowiedzi:

Zaczerpnięte z /programming/13418688/use-pipe-with-du-to-compute-size-of-stdin

Możesz go potokować, aby wc -cpoliczyć liczbę bajtów przechodzących przez potok.

Oczywiście to tylko surowe bajty i nie mają nic wspólnego z wielkością sektora itp., Więc weź to z odrobiną soli ...

— Magnus
źródło

jak napisałem, ogólne przewidywania nie będą dokładne ani nawet bliskie :)

— Drako

@cat dobra implementacja wcodrzuci dane, których nie potrzebuje już tak szybko, jak to możliwe.

— Ruslan

@cat Myślę, że buforowanie jest mało prawdopodobne, ponieważ nie trzeba buforować, aby policzyć wiersze lub znaki. Coreutils GNU wcna moim komputerze z łatwością radzą sobie z danymi standardowymi o wielkości 40 GB i tylko 8 GB pamięci.

— Frxstrem

@Magnus. Myślę, że przegapiłeś grę słów. WC to brytyjskie określenie na to, co Amerykanie nazywają łazienką. Przesyłasz nieużywane dane do toalety.

— Pozew Fund Moniki w

@Frxstrem pewno zrobić potrzebę buforowanie liczyć linie lub znaki - najszybciej jak to już nie pracujesz z kodowaniem izomorficzna. Od POSIX.2 wc -cnie liczy znaków - liczy bajty. wc -mliczy znaki. Najbardziej oczywista różnica polega na znakach wielobajtowych, takich jak UTF-16 lub Windows \r\n(dwa bajty w ASCII, ale jeden znak). Przez większość czasu niekoniecznie wymaga dużo buforowania, ale Unicode może mieć dowolną liczbę bajtów reprezentujących pojedynczy znak; nie coś, co można zobaczyć w zaufanych danych, ale możliwy wektor przepełnienia bufora.

— Luaan

Polecenie pv jest do tego idealne.

mysqldump | pv -b > /dev/null

Myślę, że powyższe da ci właściwe polecenie, które chcesz, może wymagać pewnych regulacji, takich pv -b | > /dev/nulljak nie mogę teraz przetestować

-b daje wartość w bajtach.

— djsmiley2k - CoW
źródło

Cholera, zapomniałem o pv i wc. Wstydź się. Chciałbym zaakceptować obie odpowiedzi. Przykro mi, ale Magnus był trochę szybszy i może wykorzystać reputację.

— fancyPants

Tak, nie martw się, sztuczka z wc jest naprawdę fajna, nie jestem pewien, dlaczego od razu nie przyszło mi to do głowy. Najpierw poszedłem do baru! wtedy zrozumiałem, że miałem na myśli pv! :)

— djsmiley2k - CoW

A teraz zastanawiam się, jak

— chwycić

Nigdy wcześniej o tym nie słyszałem pv. Codziennie uczysz się czegoś nowego :)

— Magnus

@Magnus: Myślę, że wc jest starsze (część niektórych starszych systemów uniksowych), nie ma takiej dokumentacji i (całkiem możliwe, że w rezultacie) pv jest wstępnie zainstalowany w mniejszej liczbie dystrybucji. Mimo to miło wiedzieć. Zobacz ten koncepcyjnie piękny obraz, który pochodzi ze strony głównej programu „pv” („przeglądarka

— potoków

Możesz do tego użyć dd, w ten sposób cat /dev/zero | dd status=progress of=/dev/null bs=4M.

Zapewnia to pewne dane podczas i po wykonaniu o ilości danych, które zostały do niego przekazane, takie jak:

$ 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

— mucha styropianowa
źródło