Комментарии 27
У меня есть шуруповерт, но я не умею использовать насадки. Зато у меня есть набор отверток, они умеют делать то же самое, значит шуруповерт бесполезен.
Почему я все время использую шуруповерт, у меня же есть замечательный набор отверток, и они умеют делать тоже самое, а еще они гораздо легче, и им не нужно электричество. Загадка.
А теперь по теме.
Ничего не сказано про то, что с помощью dd можно скопировать заданное количество блоков нужного размера, или записать их куда-то, при этом не используя кеши, чтобы после завершения операции сразу можно было извлечь конечное блочное устройство не дожидаясь пока кто-нибудь вспомнит про sync...
... можно прочитать файл с убитого накопителя игнорируя блоки в которых есть ошибки
... потестировать производительность записи играясь с блоками разного размера
ну, по дефолту (без специального ключа) оно использует кеш.
А если знать об этой проблеме - не сложно и вручную выполнить sync после выполнения нужной команды.
Но не подумайте, что я согласен с автором статьи.
всё же есть небольшая разница, при `oflag=direct` писаться будет игнорируя кеш и стараясь занять устройство настолько на сколько это возможно. в случае же отсутствие флага и выполнения sync после dd вы можете открыть iotop/iostat и убедиться что 9 стоматологов из 10 занимают устройство процентов на 30 (конечно же цифра не точная, просто пример) неторопливо сбрасывая кеш в промежутках между более важными делами.
к тому же если в системе не одна флешка куда пользователь записывал iso а 100500 устройств с 100500 файлух то sync можно ждать очень долго не зная точно а чего мы собственно ждём флешку или какой нибудь оверзанятый рейд на 100 дисков 5600rpm.
А cp умет читать игнорируя ошибки?
Ну да, я допустим буквально вчера на флешку образ через `cp ... ; sync` залил. Но только потому, что это гораздо проще набрать, чем все эти параметры dd (которые после долгого срока "непользования" этой командой еще и вспомнить надо или ман полистать). Но вот вытаскивая данные с полуживого диска опция игнора ошибок dd мне сильно помогла однажды.
А 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, а не забивать шурупы доски деревянным молоком.
А есть какая книжка на тему современная?
А зачем именно pixz ? Обычный xz с ключем -T 0 утилизирует все доступные ядра. Или есть разница?
pixz исторически преподносится, как заточенный на многопоточность xz. xz не обязан поддерживать многопоточность, а pixz обязан.
В случае применения совместно с TAR pixz умеет отображать содержимое архива без распаковки, что бесконечно круто. Не уверен, что xz так умеет.
Синтаксис pixz/pigz намного проще, что облегчает использование. Не нужно кучу ключей запоминать.
У pixz есть полный аналог pigz, который позволяет перейти на GZIP и обратно ничего не меняя в скриптах.
cp и cat не умеют в, например, oflag=dsync или oflag=direct.
Видимо, чрезмерная провокационность заголовка привела к тому, что комментаторы просмотрели статью по диагонали и сразу накидали возражений вида "автор неправ и вот почему" :)
Что ж, попробую пояснить почему мне статья показалась интересной и стоящей перевода. Во-первых, на самом деле автор не утверждает, что dd не нужен, а cat , pv и cp полностью его заменяют. Дело лишь в том, что львиная доля статей в Интернете с использованием dd -- это что-то вида:
Запишем образ на флешку:
dd if=image.iso of=/dev/sdb
Вот как раз это -- на мой взгляд -- и вредит "неокрепшим умам", формируя уверенность, что только так и нужно всегда делать, только dd и может записать образ на блочное устройство (или наоборот). А ведь это совсем не так!
Во-вторых, автор знает про флаги dd , просто в данной статье демифилогизирует её как саму по себе некую "волшебную утилиту". Поэтому странно видеть нападки на те тезисы, которые вовсе и не утверждались. Тем более, что тут всегда можно углубиться в поисках более оптимальных вариантов выполнения определённых действий: так, субъективно, с убитого накопителя лучше читать силами ddrescue , тестировать производительность -- fio , красивый прогресс-бар может рисовать pv, а потребность использовать буферы большого размера, обход кэша и вызов sync уже явно выходят за общеупотребительный универсальный вариант использования. Ну а архиваторы и вовсе не тема данной статьи.
А ведь это совсем не так!
Угу
Вы можете увидеть, насколько это глупо, заменив
ddфункционально эквивалентнымcat:cat /dev/sda | pv | cat > /dev/sdb
Это удобнее, чем dd ?
Удобство - вопрос субъективный, а так-то тут и pv вместо cat можно было сразу вписать, и буковок чуть меньше набирать :)
Давайте заменим 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.
Проблема этой статьи именно в том, что она не объясняет ничего, а имеет только заголовок.
Немного затрагивает проблематику множества противоречивых инструкций, успешно пополняя это множество.
Если бы изначально статья была построена именно от противного: смотрите в интернете множество поверхностных инструкций. Возьмем, например, любую статью, в котором используется утилита dd. Но ведь вместо нее можно делать вот так, и вот этак, или вообще наперекосяк, то тогда и вопросов бы не было.
В общем и целом, автор троль, успешно набросил на вентилятор.
Радость познания и не более. Смысла переводить чужие радости на русский нет.
По крайней мере, я нашел её для себя познавательной и, надеюсь, вам она тоже будет интересна
Нет.
Есть перевод на другие языки, но он обычно опаздывает.
https://wiki.archlinux.org/title/Dd
https://wiki.archlinux.org/title/Disk_cloning
https://wiki.archlinux.org/title/USB_flash_installation_media#Using_basic_command_line_utilities
https://wiki.archlinux.org/title/Benchmarking#dd
https://wiki.archlinux.org/title/Securely_wipe_disk#dd
Самое интересное и содержательное для меня в этой статье оказалось объяснение происхождения названия "dd" :)
Создать файл на 10ГБ, например
Потестить диск
Склонировать диск
АфФТАР - питух.
Бесполезность dd