Командная строка для записи медиа DVD+R DL на Linux?

Все следующие команды эквивалентны. Они считывают байты компакт-диска /dev/sr0 и записывают их в файл с именем image.iso .

cat /dev/sr0 >image.iso
cat </dev/sr0 >image.iso
tee </dev/sr0 >image.iso
dd </dev/sr0 >image.iso
dd if=/dev/cdrom of=image.iso
pv </dev/sr0 >image.iso
cp /dev/sr0 image.iso
tail -c +1 /dev/sr0 >image.iso

Зачем использовать одно над другим?

• Простота. Например, если вы уже знаете cat или cp , вам не нужно изучать еще одну команду.

• Надежность. Это немного вариант простоты. Насколько велик риск того, что изменение команды изменит то, что она делает? Давайте посмотрим несколько примеров:

  • Что угодно с перенаправлением: вы можете случайно поставить перенаправление неправильно, или забыть его. Поскольку местом назначения должен быть несуществующий файл, set -o noclobber должен гарантировать, что вы ничего не перезаписываете; однако вы можете перезаписать устройство, если случайно напишете >/dev/sda (для компакт-диска, который доступен только для чтения, риска, конечно, нет). Это говорит в пользу cat/dev/sr0 > image.iso (трудно ошибиться в повреждающем пути) по сравнению с альтернативными вариантами, такими как tee image.iso (если вы инвертируете перенаправления или забудете входной, tee запишет в /dev/sr0 ).
  • cat : возможно случайное объединение двух файлов. Это делает данные легко спасаемыми.
  • dd : i и o близки на клавиатуре и несколько необычны. Нет эквивалента noclobber , = с радостью перезаписывает что-либо. Синтаксис перенаправления менее подвержен ошибкам.
  • cp : если случайно поменять местами источник и цель, устройство будет перезаписано (опять же, при условии, что устройство не доступно только для чтения). Если вызывается cp с некоторыми параметрами, такими как -R или -a , которые некоторые пользователи добавляют через псевдоним, узел устройства будет скопирован, а не содержимое устройства.

• Дополнительные функциональные возможности. Одним из инструментов, который имеет полезные дополнительные функциональные возможности, является pv с мощными возможностями создания отчетов.
  Но здесь вы можете проверить, сколько было скопировано, глядя на размер выходного файла в любом случае.

• Производительность. Это связанный с вводом-выводом процесс; основное влияние в производительности оказывает размер буфера: инструмент считывает порцию из источника, записывает порцию в пункт назначения, повторяет. Если блок слишком мал, компьютер тратит время на переключение между задачами. Если блок слишком велик, операции чтения и записи не могут быть параллелизованы. Оптимальный размер блока на ПК обычно составляет около нескольких мегабайт, но это, очевидно, очень зависит от ОС, оборудования и от того, что еще делает компьютер. Я сделал тесты для копий на жестком диске некоторое время назад, в Linux, которые показали, что для копий в пределах одного диска, dd с большим размером буфера имеет преимущество, но для кросс-дисковых копий, cat выиграл над любым dd размером буфера.

Существует несколько причин, по которым dd упоминается так часто. Кроме производительности, они не являются особенно вескими причинами.

• В очень старых Unix-системах некоторые средства обработки текста не могли справиться с двоичными данными (они использовали последовательности с нулевым окончанием внутри, поэтому у них были проблемы с нулевыми байтами; некоторые инструменты также предполагали, что символы использовали только 7 бит и не обрабатывали 8-битные наборы символов должным образом). Я не уверен, было ли это когда-либо проблемой с cat (это было с более линейно-ориентированными инструментами, такими как head , sed и т.д.), но люди склонны избегать его на двоичных данных из-за его связи с обработкой текста. Это не проблема современных систем, таких как Linux, OSX, * BSD, и не проблема, совместимая с POSIX.
• Существует своего рода миф о том, что dd несколько ниже, чем другие инструменты, такие как cat , и обращается к устройствам напрямую. Это полностью ложь: dd и cat и tee , а остальные все считывают байты со своего входа и записывают байты на свой выход. Настоящая магия в /dev/sr0 .
• dd имеет необычный синтаксис командной строки, поэтому объяснение того, как он работает, дает больше возможности блеснуть, объясняя что-то, что просто пишет cat/dev/sr0 .
• Использование dd с большим размером буфера может иметь более высокую производительность, но это не всегда так (см. некоторые тесты в Linux ).

Основной риск, связанный с dd , заключается в том, что может незаметно пропустить некоторые данные . Я думаю, что dd безопасен, пока пропускают или count не пройдены, но я не уверен, так ли это на всех платформах. Но у него нет никакого преимущества, кроме исполнения.

Поэтому просто используйте pv , если вы хотите, чтобы его модный отчет о ходе выполнения, или cat , если вы не хотите.

Всякий раз, когда сетевой интерфейс поднимается или отключается, выполняются сценарии в /etc/network/* .d .

Так, например, можно сделать /etc/apt/apt.conf.d/10proxy символьной ссылкой, цель которой изменяется сценарием в /etc/network/if-up.d . Эти сценарии получают несколько переменных среды, в частности IFACE с именем интерфейса; для получения информации о присоединяемой сети можно использовать ifconfig , route , ip и т.д. Справочная страница interfaces (5) документирует этот объект.

Если вы не указали cdrecord, куда положить разрыв слоя, накопитель заполнит носитель до 100%. Это вызывает длительную задержку.

Если cdrecord не удается, вы можете стать жертвой различных модифицированных версий, которые сорвали поддержку DVD и заменили оригинальный код чем-то наполовину ослабленным.Эти дефектные версии не сообщают о версии 3, и они не знают о правильных тайм-аутах для записи DVD. Это может быть причиной слишком раннего истечения времени cdrecord.

Последняя версия cdrecord - 3.01a31, и скоро будет 3,01-final.

Вы использовали последнюю версию?