A1EF Sep 1 at 23:23

Бесполезность dd

Easy

4 min

14K

*nix*

Translation

+10

Comments 27

Naves Sep 1 at 23:48

У меня есть шуруповерт, но я не умею использовать насадки. Зато у меня есть набор отверток, они умеют делать то же самое, значит шуруповерт бесполезен.

Почему я все время использую шуруповерт, у меня же есть замечательный набор отверток, и они умеют делать тоже самое, а еще они гораздо легче, и им не нужно электричество. Загадка.

А теперь по теме.

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

MzMz Sep 1 at 23:57

... можно прочитать файл с убитого накопителя игнорируя блоки в которых есть ошибки

ivankudryavtsev Sep 2 at 08:57

Лучше ddrescue, а не dd.

MzMz Sep 1 at 23:58

... потестировать производительность записи играясь с блоками разного размера

ivankudryavtsev Sep 2 at 12:03

лучше fio, а не dd. Но dd тоже можно как первый шаг.

dimkrayan Sep 2 at 02:51

ну, по дефолту (без специального ключа) оно использует кеш.
А если знать об этой проблеме - не сложно и вручную выполнить sync после выполнения нужной команды.

Но не подумайте, что я согласен с автором статьи.

13werwolf13 Sep 2 at 13:14

всё же есть небольшая разница, при `oflag=direct` писаться будет игнорируя кеш и стараясь занять устройство настолько на сколько это возможно. в случае же отсутствие флага и выполнения sync после dd вы можете открыть iotop/iostat и убедиться что 9 стоматологов из 10 занимают устройство процентов на 30 (конечно же цифра не точная, просто пример) неторопливо сбрасывая кеш в промежутках между более важными делами.

к тому же если в системе не одна флешка куда пользователь записывал iso а 100500 устройств с 100500 файлух то sync можно ждать очень долго не зная точно а чего мы собственно ждём флешку или какой нибудь оверзанятый рейд на 100 дисков 5600rpm.

Sly_tom_cat Sep 2 at 00:00

А cp умет читать игнорируя ошибки?
Ну да, я допустим буквально вчера на флешку образ через `cp ... ; sync` залил. Но только потому, что это гораздо проще набрать, чем все эти параметры dd (которые после долгого срока "непользования" этой командой еще и вспомнить надо или ман полистать). Но вот вытаскивая данные с полуживого диска опция игнора ошибок dd мне сильно помогла однажды.

Sap_ru Sep 2 at 00:12

А cat умеет работать с буферами большого размера? А с асинхронным чтением/записью? А то у вас там пример с bs=1M, а у cat какой буфер? 64k?
А чтобы буфер 10Gb и аcихнонное direct чтение в него, cat умеет? А то бывает нужно, если хочется всё быстро прочитать, а потом медленно писать, и при этом не забивать кэш системы.
А прямое чтение и запись в обход кэшей cat умеет? Ну, чтобы точно на устройство, а не в буфера? А так, чтобы чтение через кэш, а запись direct?
А sync в конце записи cat умеет?
А так, чтобы вообще без барьеров синхронизации cat умеет писать?

Более того, зачем вы этот gzip вообще используете?! У вас есть много лишнего времени? То есть МНОГО лишнего времени - в восемь раз больше, чем реально нужно? Или у вас есть много лишнего места - раза в два больше, чем нужно? Есть же pigz и pixz, которые намного быстрее и лучше жмут, что может быть критически важно для сжатия образов! pixz круто уделает ваш "gzip -9" одновременно и по скорости и степени сжатия!

P.S. Да, я понимаю, что перевод, но это такая лютая дичь, что она банально вредна для неокрепших умов. Неокрепшим умам нужно бы узнать про dd, про pipes и про pixz/pigz, а не забивать шурупы доски деревянным молоком.

Melirius Sep 2 at 04:40

А есть какая книжка на тему современная?

ivankudryavtsev Sep 2 at 08:59

man dd - самая современная книжка. Или вы про Advanced bash scripting guide спрашиваете?

Melirius Sep 3 at 00:22

Вообще про инструменты скриптов в Linux, всё, что знаю, похоже, подустарело - рекомендует gzip тот же самый, только тут узнал про pigz и pixz. Из man gzip про это не узнаешь.

Naves Sep 3 at 15:49

Во многих местах стали упоминать zstd в качестве альтернативного стандартного алгоритма сжатия, например, в ZFS.

gumanzoy Sep 2 at 17:07

А зачем именно pixz ? Обычный xz с ключем -T 0 утилизирует все доступные ядра. Или есть разница?

Sap_ru Sep 3 at 18:15

pixz исторически преподносится, как заточенный на многопоточность xz. xz не обязан поддерживать многопоточность, а pixz обязан.
В случае применения совместно с TAR pixz умеет отображать содержимое архива без распаковки, что бесконечно круто. Не уверен, что xz так умеет.
Синтаксис pixz/pigz намного проще, что облегчает использование. Не нужно кучу ключей запоминать.
У pixz есть полный аналог pigz, который позволяет перейти на GZIP и обратно ничего не меняя в скриптах.

rogoz Sep 2 at 00:14

cp и cat не умеют в, например, oflag=dsync или oflag=direct.

Wesha Sep 2 at 02:19

А ещё они не умеют в status=progress или в SIGINFO.

CrazyOpossum Sep 2 at 07:20

Для сложных вещей отлично rsync подходит.

A1EF Sep 2 at 04:42

Видимо, чрезмерная провокационность заголовка привела к тому, что комментаторы просмотрели статью по диагонали и сразу накидали возражений вида "автор неправ и вот почему" :)

Что ж, попробую пояснить почему мне статья показалась интересной и стоящей перевода. Во-первых, на самом деле автор не утверждает, что dd не нужен, а cat , pv и cp полностью его заменяют. Дело лишь в том, что львиная доля статей в Интернете с использованием dd -- это что-то вида:

Запишем образ на флешку: dd if=image.iso of=/dev/sdb

Вот как раз это -- на мой взгляд -- и вредит "неокрепшим умам", формируя уверенность, что только так и нужно всегда делать, только dd и может записать образ на блочное устройство (или наоборот). А ведь это совсем не так!

Во-вторых, автор знает про флаги dd , просто в данной статье демифилогизирует её как саму по себе некую "волшебную утилиту". Поэтому странно видеть нападки на те тезисы, которые вовсе и не утверждались. Тем более, что тут всегда можно углубиться в поисках более оптимальных вариантов выполнения определённых действий: так, субъективно, с убитого накопителя лучше читать силами ddrescue , тестировать производительность -- fio , красивый прогресс-бар может рисовать pv, а потребность использовать буферы большого размера, обход кэша и вызов sync уже явно выходят за общеупотребительный универсальный вариант использования. Ну а архиваторы и вовсе не тема данной статьи.

unreal_undead2 Sep 2 at 07:57

А ведь это совсем не так!

Угу

Вы можете увидеть, насколько это глупо, заменив dd функционально эквивалентным cat: cat /dev/sda | pv | cat > /dev/sdb

Это удобнее, чем dd ?

A1EF Sep 2 at 09:24

Удобство - вопрос субъективный, а так-то тут и pv вместо cat можно было сразу вписать, и буковок чуть меньше набирать :)

eps Sep 2 at 09:30

Давайте заменим useless dd на useless use of cat (Award)

The purpose of cat is to concatenate (or "catenate") files. If it's only one file, concatenating it with nothing at all is a waste of time, and costs you a process.

Naves Sep 2 at 11:53

Проблема этой статьи именно в том, что она не объясняет ничего, а имеет только заголовок.

Немного затрагивает проблематику множества противоречивых инструкций, успешно пополняя это множество.

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

В общем и целом, автор троль, успешно набросил на вентилятор.