Re: dd

[Artem Chuprina <ran@ran.pp.ru>]

> >> dd практически всегда нуждается в указании bs для оптимального
> >> быстродействия, чем не страдают cat/pv.
> >
> > ... в которых размер буфера наверняка забит руками раз и навсегда,
> > что тоже не есть хорошо.
> 
> ... но там запросто может быть забито руками что-то поумнее
> умолчательного bs=512.
> 
> По-моему, никому не помешает периодическое напоминание о том, что cp и
> cat тоже справляются (особенно если оно не утверждает великую кошерность
> cp и халяльность cat на фоне скоромности dd).

Тогда только надо не забывать упоминать, в каких именно ОС они справляются.
Я понимаю, что рассылка тематическая, но у меня есть, гм, предубеждение, что
линукс-специфичное решение, как правило, хуже общеюниксового там, где их
сложность сравнима, а дистрибутив-специфичное решение там, где есть хотя бы
общее линукс-специфичное, обычно вообще невменяемо.

cp -a - очень приятная фри-юникс-специфичная штука, но она крайне редко
оказывается лучше, чем rsync -a.  И в половине случаев при этом на самом деле
нужно еще более гну-читай-линукс-специфичное cp -al.  Это к вопросу о
нижепроцитированном sendfile(2), которая в этом последнем случае немедленно
начинает проигрывать cp в разы по скорости и квадратично по месту на диске.

> Кстати, я вспомнил ещё один подход: писал когда-то простенькую хреновину
> на си, содержательная часть которой состояла в вызове sendfile(2) (оно
> тогда умело между файлами копировать; сейчас это splice(2), если не
> ошибаюсь).

Вот, кстати, да.  Яркий пример.  Выигрыш в производительности в полтора раза
ценой того, что в какой-то момент хреновина ВНЕЗАПНО перестает работать
вообще.  Потому что нигде больше не применяемый и оттого не стандартизованный
sendfile(2) вдруг взял и разучился копировать между файлами.

> Использовал её для разделов и для больших файлов (типа
> образов CD), где копирование тормозило; разница по времени с cp
> иногда была раза в полтора (ну, точно не помню, но десятки процентов).

-- 
Весь юникс для того и был придуман, чтобы PS в принтер выплевывать.
	Alex Korchmar в <a63nn3$ef7$1@alx.private>