Можно ли использовать oflag=direct и conv=fsync вместе в dd?
Mutt является почтовым агентом (MUA ); по сути, мощный почтовый клиент для терминала, (См. также:NeoMutt). Он может использовать сценарии оболочки в качестве фильтров для новых писем . Я лично никогда не делал именно то, о чем вы просите, но вот несколько команд, которые могут помочь.
Чтобы отправить электронное письмо, запустите echo "This is the message body" | mutt -c . Подсказка :тело также может быть файлом на диске, mutt -c , (См.:справочную страницу для получения дополнительной информации ).
Итак, чтобы внести ясность, вам нужно: 1 )Создать новый сценарий электронной почты для анализа входящей почты, 2 )Создать сценарий для отправки вашего ответа, а затем 3 )Настроить запуск по cron.
Кроме того, по умолчанию ваши учетные данные хранятся в виде обычного текста. Однако, если у вас установлена GPG , вы можете зашифровать свои учетные данные, чтобы их можно было безопасно хранить, (См. пример:dotfiles/.mutt/muttrc ).
Я бы не стал беспокоить-ddввод настолько медленный, что вам следует максимизировать любое использование кэша, так как вывод невероятно медленный. Использование большого размера блока (для увеличения объема кеша )— лучшее, что вы можете сделать.
Что касается конкретного вопроса @sgon00, на справочной странице ddговорится:-
fdatasync physically write output file data before finishing
fsync likewise, but also write metadata
oflag=FLAGS write as per the comma separated symbol list...
oflag=nocache Запрос на удаление кеша. Эта опция по крайней мере упоминает кеш. Хотя это не обязательно означает, что он будет предоставлен. Эту катушку можно комбинировать с «прямым» вариантом.
dd— старая программа, поэтому многие ее возможные параметры могут интерпретироваться не совсем так, как они изначально предназначались.
Похоже, ваш вопрос касается скорости. Вы уже используете conv=fsync, поэтому я не вижу вопросов о безопасности или «правильности». Если у вас нет оборудования с определенной ошибкой, вам нужно будет точно сообщить нам, как выглядит ваша ошибка.
Общее правило производительности — проверять свою собственную ситуацию и не слишком беспокоиться о небольших различиях. ddсообщает вам скорость. Вы можете протестировать разные варианты с помощью небольшого count=. Например. вы можете использовать bs=4k count=100kдля проверки записи 400M.
Вы спрашиваете об относительно простом случае. /dev/zeroбудет намного быстрее, чем ваше устройство, поэтому производительность чтения я игнорирую.
Использование oflag=syncбудет ждать, пока все временные кэши опустеют после отправки каждого блока данных, теряя преимущество постоянного хранения данных в -потоке. Поэтому вам нужно будет указать больший размер блока, чтобы получить наилучшую скорость, например. bs=16M.
В принципе, вы хотите подавать на устройство до двух запросов одновременно, чтобы у него всегда был хотя бы один запрос для обработки. В частности, на механических приводах, если вы позволите корму высохнуть, вам придется подождать полного оборота, прежде чем ваш следующий запрос можно будет записать в нужном месте. ddсама ничего для этого не делает. Он зависит от кеша обратной записи в ядре или в устройстве.
oflag=directполезен в -между параметрами. Если у вас есть проблема с кешем ядра (, см. ниже ), это отличный способ обойти этот кеш. Многие устройства имеют собственный кэш обратной записи, поэтому oflag=directможет быть быстрее, чем oflag=syncдля того же размера блока.
Кэш ядра должен работать хорошо, не замедляя доступ ввода-вывода к другим устройствам. Например. ваш системный диск, который вы используете одновременно :-). Но эта проблема иногда возникает, и люди жалуются на нее. Так что это может зависеть от того, ожидаете ли вы или беспокоитесь о такой проблеме :-).
Если вы хотите попробовать оба варианта одновременно,вы указываете это как oflag=direct,sync.
Даже без oflag=syncувеличение размера блока еще в несколько раз может снизить нагрузку на ЦП. Например. bs=16kили bs=1M. А вот bs=4k/bs=4096уже достаточно хороши, намного лучше, чем древний дефолт bs=512.