Re: dd

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

> > > > немедленно начинает проигрывать cp в разы по скорости и квадратично по
> > > > месту на диске.
> > > 
> > Видишь ли, cp -al - это не open/write и не sendfile(2).  Это link(2).
> 
> Я в курсе. Именно поэтому мне трудно понять какое отношение к ней имеет
> sendfile.

Речь шла о кастомной программе с использованием sendfile, которая выигрывала
десятки процентов у cp.  Я говорю о том, что да, у cp -a она выиграет десятки
процентов.  А cp -al, если оная вдруг применима, проиграет в разы.  К вопросу
об использовании более или менее стандартных решений.

> > > Ну и потом linux не добился бы никакого успеха без "Stable API
> > > Nonsense", и
> > > 
> > > Fall back to read/write все делают.
> > 
> > Если нет жестких требований к производительности, то дешевле сразу
> > написать read/write, чем писать sendfile и fallback на тот же самый
> > read/write.  А если есть, то какой нафиг fallback?
> > 
> > Нет, я понимаю, есть узкий класс задач, где это имеет смысл.
> 
> IMHO жесткие требования на высокую производительность при копировании файлов, 
> есть почти всегда. read/write имеет смысл сразу делать только для небольших файлов.

Повторюсь: а если требования жесткие, то какой нафиг fallback?  Жесткие - это
значит, что read/write не тянут.  Если они не тянут, то делать на них fallback
нельзя.

-- 
The effort of using machines to mimic the human mind has always struck
me as rather silly. I would rather use them to mimic something better
 -- Edsger Dijkstra