Обчисліть, скільки дискового простору було б використано


25

Чи є в Linux програма, яка може обчислити, скільки даних виробляє програма?

Наприклад, якщо я хотів би зробити резервну копію своєї бази даних MySQL, я б зазвичай це робив

mysqldump > dumpfile.sql

Натомість я хотів би переадресувати, /dev/nullале обчислити, скільки б дискового простору було б використано, наприклад

mysqldump | fancy_space_calc_program

Вихід:

123456789 Bytes would have been used

Зауважте, резервна копія MySQL - лише приклад. Я дуже добре знаю, як я міг оцінити розмір заздалегідь, тому, будь ласка, жодних коментарів з цього приводу.


1
Я навіть не думаю, що ти справді можеш її зробити; для конкретних випадків так, але не для загального використання, тому як ви можете оцінити, чи якась програма зателефонує на якийсь сервер і завантажить звідти дані - не випадково ви можете оцінити такі речі в іноземних додатках. Тож це буде за програму - як ви пишете, що вже знаєте для MYSQL - там немає пояснень, але інші додатки - за програму, жоден загальний інструмент не міг зробити таке передбачення правильно.
Драко

1
Я сподіваюся, що ви зрозуміли, що будь-яка спроба зробити оцінку потребує насправді запуску програми та спостереження за результатами, поки вона надсилається кудись у безпеку. Це стане неможливим, якщо програма має якийсь необоротний вплив на щось інше, тож Ви можете ТІЛЬКИ запустити її один раз без ненавмисних побічних ефектів. Інша проблема полягає в тому, що якщо програма отримує свій результат із зміни вводу, наступний запуск створить інший (різного розміру) вихідний файл. І останнє, але не менш важливе: дисковий простір <> (байти виводу). І різні файлові системи мають різні накладні витрати для ведення бухгалтерського обліку.
Тонні

1
Так, я це добре знаю. Це все ще досить добре для мене.
fancyPants

@Drako У вас може бути загальний спосіб вимірювання виводу тексту програми. Це не потрібно робити на додаток (див., Наприклад, прийняту відповідь). Незалежно від того, чи буде виведення тексту надійно ідентичним при наступних запусках, залежить від додатка, але це не заважає вам загально вимірювати вихід. Імовірно, ОП та хто-небудь інший, хто намагається виміряти вихід, зробили б це лише в тому випадку, якщо дані мали значення для будь-якої програми.
Джон Бентлі

@JonBentley Я ніколи не говорив, що ти не можеш цього прочитати, уважніше: "як я писав, загальний прогноз не буде точним або навіть близьким :)", а тепер уявіть, що моя програма після запуску перевірить на оновлення себе, плагінів , тощо, завантажить x кількість даних з i-net та збереже їх на вашому hdd; як ви будете точно заздалегідь вимірювати загальний інструмент, не знаючи нічого про мою програму, скільки місця буде потрібно після її запуску? Тим не менш, ти можеш найкраще здогадатися з прийнятою відповіддю, а в багатьох випадках навіть бути досить точним.
Драко

Відповіді:


37

Взято з /programming/13418688/use-pipe-with-du-to-compute-size-of-stdin

Ви можете передати його на wc -cпідрахунок кількості байтів, які проходять через конвеєр.

Звичайно, це просто необроблені байти, і вони не мають нічого спільного з розміром сектора тощо, тому візьміть його із зерном солі ...


як я писав, загальний прогноз не буде точним або навіть близьким :)
Драко

6
@cat хороша реалізація wcбуде відкидати дані, які вже не потребують, як тільки це стане практичним.
Руслан

2
@cat Я думаю, що це навряд чи буде буферизовано, оскільки для підрахунку рядків чи символів вам не потрібно буферизація. GNU coreutils wcна моєму комп’ютері легко обробляє стаціонарні дані 40 ГБ, маючи лише 8 ГБ пам'яті.
Frxstrem

8
@Magnus. Я думаю, ти пропустив гру слів. WC - це британський термін для того, що американці називають ванною. Ви запираєте невикористані дані у туалет.
Фонд позову Моніки

3
@Frxstrem Ви, звичайно , потребуєте буферизації для підрахунку рядків або символів - як тільки ви більше не працюєте з ізоморфним кодуванням. Оскільки POSIX.2 wc -cне рахує символів - він рахує байти. wc -mрахує символів. Найбільш очевидна відмінність полягає в багатобайтових символах, таких як UTF-16 або Windows \r\n(два байти в ASCII, але один символ). Це не обов'язково потребує великої кількості буферизації більшу частину часу, але Unicode може мати довільну кількість байтів, щоб представити один символ; не те, що ви бачите у надійних даних, але можливий вектор переповнення буфера.
Луань

28

Для цього ідеально підійде команда pv.

mysqldump | pv -b > /dev/null

Я думаю, що вищесказане дасть вам потрібну потрібну вам команду, можливо, знадобиться деяке коригування, таке pv -b | > /dev/nullяк я зараз не можу перевірити

-b дає значення в байтах.


1
Святий, я забув про ПВ, а також про туалет. Мені так соромно. Я хотів би прийняти обидві відповіді. Отже, вибачте, але Магнус був трохи швидшим і він може користуватися репутацією.
fancyPants

Так, не хвилюйтесь, фокус у туалеті справді приємний, не впевнений, чому це мені не трапилось одразу ж. Я вперше пішов "бар!" потім зрозумів, що я мав на увазі пв! :)
djsmiley2k - CoW

І тепер у мене виникає питання про захоплення файлової ручки та перевірку розміру в / proc десь ....
djsmiley2k - CoW

2
Я ніколи раніше не чув pv.. Ви щодня дізнаєтесь щось нове :)
Магнус

2
@Magnus: Я думаю, що wc є старшим (частина деяких старих систем Unix), не в такій же кількості документації, і (цілком можливо, в результаті) pv попередньо встановлюється в меншій кількості дистрибутивів. Все-таки приємно знати. Дивіться цю концептуально красиву картину, що походить з домашньої сторінки програми "pv" ("трубопровід")
TOOGAM

0

Ви можете використовувати ddдля цього, як це cat /dev/zero | dd status=progress of=/dev/null bs=4M.

Це надає вам деякі дані під час та після виконання про кількість переданих їм даних, наприклад:

$ 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
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.