Как предотвратить бессмысленный прогресс dd в Linux?
После некоторых исследований я узнал, что это не проблема NAT. Это с медиасервером Plex.
Откройте веб-интерфейс медиасервера Plex и просмотрите дополнительные настройки. У вас будет возможность установить интервал обновления медиа-ресурса.
Это произойдет не мгновенно, но произойдет в соответствии с указанным вами интервалом.
Из первой строки видно, что ddпрочитал и записал 1,5 ГБ за одну секунду. Даже SSD не может так быстро писать.
Произошло следующее: блочное устройство /dev/sdc приняло (обратную запись ), но не отправило его на диск, а буферизовало и начало запись на диск со скоростью, которую диск может принять. Что-то вроде 3 МБ/с.
Система не может бесконечно буферизовать данные таким образом, количество данных, которое она может хранить в этом не -зафиксированном грязном состоянии, ограничено. Итак, через некоторое время (в вашем случае, после того, как было записано более 1,5 ГБ, но прошло менее 2 секунд (, поскольку строки выполнения записываются каждую секунду )), системный вызов dd's write()будет блокироваться до тех пор, пока данные не будут сброшены на диск (, в течение которого он не может записывать сообщения о ходе выполнения ). Когда он пройдет, ddможет отправить несколько дополнительных недостающих мегабайт, и это произойдет менее чем за секунду, так что вы получите только одну дополнительную строку прогресса.
Чтобы увидеть другое поведение, вы можете сделать запись синхронной, то есть не возвращать данные, пока данные не будут зафиксированы на диске. Например, используя oflag=syncили oflag=dsyncили oflag=direct(, я бы не советовал делать это, хотя ).
Когда вы записываете файл на блочное устройство, используйте ddс oflag=direct. При этом используются записи O _DIRECT, что позволяет избежать использования ОЗУ в качестве кэша обратной записи. Обратите внимание, что для получения хорошей производительности oflag=directобычно требуется большой размер блока.
Это позволит избежать невероятно быстрого прогресса, если только у вас нет странного устройства, которое само имеет очень большой кэш ОЗУ .
Многие устройства имеют небольшой объем кэш-памяти. В этом случае oflag=directпокажет реалистичную скорость прогресса. Это более осмысленно, но не говорит вам всего, что вы хотите знать :-). Это не гарантирует, что последние записи будут завершены, когда ddскажет, что они завершены. Вы можете убедиться, что все записи завершены -, а также проверить наличие ошибок записи -с помощью опции conv=fsync. Это вызывает fsync ()в конце, чтобы убедиться, что кеш очищен. Вот пример:
dd if=my.iso of=/dev/sdc oflag=direct bs=4M status=progress conv=fsync
Некоторые люди после этого запускают команду syncи по понятным причинам не удосуживаются запомнить conv=fsync. Это не так хорошо. syncне будет сообщать о сбое одной из операций записи.
Если у устройства очень большой кэш ОЗУ, вам придется использовать oflag=direct,sync. Но обычно я думаю о oflag=syncкак о потенциальном барьере для производительности. Возможно, вы захотите еще больше увеличить размер блока, чтобы уменьшить частоту очистки кеша. При очень синхронном вводе-выводе и одновременном чтении нескольких аппаратных блоков вы можете захотеть использовать двойную буферизацию -для поддержания хорошей производительности, т.е.используя вторую команду dd, как показано в ссылке ниже.
Иногда вы также можете захотеть передать образ диска из другой программы, например gunzip. В этом случае хорошая производительность также зависит от iflag=fullblockи передачи через другую команду dd. В ответе есть полный пример :. Почему конвейер gunzip в dd замедляется в конце?
Какой Linux вы используете? Если он основан на Debian (Ubuntu, Mint, Debian и т. д. )Я бы использовал программу под названием Disks. Это встроенный диспетчер дисков с графическим интерфейсом, который может делать то же самое, что и DD, и давать вам постоянный статус.