> >> 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 в <[email protected]>
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/87k49sq089.wl%[email protected]
