Re: dd
> > > > немедленно начинает проигрывать 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
Reply to:
- References:
- Re: dd
- From: Artem Chuprina <ran@ran.pp.ru>
- Re: dd
- From: Иван Лох <loh@1917.com>
- Re: dd
- From: Artem Chuprina <ran@ran.pp.ru>
- Re: dd
- From: Иван Лох <loh@1917.com>