Подсчитайте, сколько дискового пространства было бы использовано

Есть ли в Linux программа, которая может рассчитать, сколько данных программа выдаст?

Например, если я хочу сделать резервную копию моей базы данных MySQL, я обычно делаю

mysqldump > dumpfile.sql

Вместо этого я хотел бы перенаправить, /dev/nullно рассчитать, сколько дискового пространства было бы использовано, как

mysqldump | fancy_space_calc_program

Выход:

123456789 Bytes would have been used

Обратите внимание, резервное копирование MySQL является лишь примером. Я очень хорошо знаю, как я могу оценить размер заранее, поэтому, пожалуйста, без комментариев об этом.

linux disk-space

— выпендрежник
источник

Я даже не думаю, что вы действительно можете сделать это; для определенных случаев да, но не для общего использования, потому что как вы можете оценить, если какое-то приложение вызывает какой-либо сервер и загружает данные оттуда - нет шансов, что вы можете оценить такие вещи в иностранных приложениях. Так что это будет для каждого приложения - как вы пишете, что вы уже знаете, для MYSQL - никаких объяснений нет, но другие приложения - для приложения, ни один общий инструмент не может сделать такой прогноз правильно.

— Драко

Я надеюсь, что вы понимаете, что любая попытка сделать оценку потребует фактического запуска программы и наблюдения за результатами, пока она отправляется в безопасное место. Это станет невозможным, если программа оказывает какое-то необратимое влияние на что-то другое, поэтому вы можете запускать ТОЛЬКО один раз без непредвиденных побочных эффектов. Другая проблема заключается в том, что если программа выводит свои данные из изменяющегося ввода, то при следующем запуске будет создан другой выходной файл (другого размера). И последнее, но не менее важное: дисковое пространство <> (байты вывода) И разные файловые системы имеют разные накладные расходы на бухгалтерию.

— Тонни

Да, я хорошо это знаю. Это все еще достаточно хорошо для меня.

— fancyPants

@Drako Вы можете иметь общий способ измерения текстового вывода программы. Это не обязательно для каждого приложения (см., Например, принятый ответ). То, будет ли текстовый вывод надежно идентичным при последующих запусках, зависит от приложения, но это не мешает вам измерить вывод в общем виде. Предположительно, ОП и любой другой, кто пытается измерить выход, будут делать это только в том случае, если данные будут значимыми для любого конкретного приложения.

— Джон Бентли,

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

— Драко

Ответы:

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

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

Конечно, это только необработанные байты, и они не имеют ничего общего с размером сектора и т. Д.

— Магнус
источник

как я писал, общий прогноз не будет точным или даже близким :)

— Драко

Хорошая реализация @cat wcотбросит данные, которые больше не нужны, как только это станет практически возможным.

— Руслан

@cat Я думаю, что это вряд ли буферизуется, так как вам не нужна буферизация для подсчета строк или символов. GNU coreutils wcна моем компьютере легко обрабатывает 40 ГБ стандартных данных, используя только 8 ГБ памяти.

— Frxstrem

@Магнус. Я думаю, что вы пропустили игру слов. WC - это британский термин, который американцы называют ванной. Вы отправляете неиспользуемые данные в туалет.

— Фонд Моники судебный процесс

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

— Луаан

Команда pv идеально подходит для этого.

mysqldump | pv -b > /dev/null

Я думаю, что приведенное выше даст вам правильную команду, которую вы хотите, может потребоваться некоторая корректировка, например, pv -b | > /dev/nullя не могу проверить прямо сейчас

-b дает вам значение в байтах.

— djsmiley2k - CoW
источник

Святой, я забыл о пв, а также туалет. Мне стыдно. Я хотел бы принять оба ответа. Так что, извините, но Магнус был немного быстрее, и он может использовать репутацию.

— fancyPants

Да, не беспокойся, трюк с wc очень хорош, не уверен, почему это сразу не произошло со мной. Я сначала пошел "бар!" потом понял, что я имел в виду, был pv! :)

— djsmiley2k - CoW

И теперь у вас возник вопрос, как мне захватить дескриптор файла и проверить где-нибудь размер в / proc ...

— djsmiley2k - CoW

Я никогда не слышал pvраньше .. Вы узнаете что-то новое каждый день :)

— Магнус

@Magnus: Я думаю, что wc старше (часть некоторых более старых систем Unix), не так много документации, и (вполне возможно, в результате) pv предустановлен в меньшем количестве дистрибутивов. Тем не менее, приятно знать о. Посмотрите на эту концептуально красивую картинку, которая появилась на домашней странице программы "pv" ("pipe viewer")

— TOOGAM

Вы можете использовать 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

— пенополистирол летать
источник