> > cp -a - очень приятная фри-юникс-специфичная штука, но она крайне редко > > оказывается лучше, чем rsync -a. И в половине случаев при этом на самом > > деле нужно еще более гну-читай-линукс-специфичное cp -al. Это к вопросу о > > нижепроцитированном sendfile(2), которая в этом последнем случае > > немедленно начинает проигрывать cp в разы по скорости и квадратично по > > месту на диске. > > Вопрос же не в том cp или rsync, а в том open/write или специальным ядерным > вызовом. Понятно, что чем изощреннее становятся оба планировщика, чем > сложнее дисковые драйверы и сами диски, тем больше будет разрыв в > производительности между двумя подходами.
Видишь ли, cp -al - это не open/write и не sendfile(2). Это link(2). > Ну и потом linux не добился бы никакого успеха без "Stable API Nonsense", и > широкого прорастания этого Non Stable API в userspace. Его козырем всегда > был и будет +1% к производительности. А он и есть IMHO за счет Non Stable > API. Я же не говорю, что линукс-специфичное решение _всегда_ хуже. Там, где тебе действительно нужен +1% - не вопрос, оптимизируй. Когда у тебя прорва файлов и ты точно знаешь, что тебе их надо скопировать из одной директории в другую не глядя, надо сделать это один раз и на линуксе, cp -a в норме будет быстрее, чем rsync -a, не вопрос. Потому что не будет читать даже целевое дерево, не говоря уже о файлах (интересно, у rsync есть противоестественный интеллект на тему "если копирование локальное, не считать контрольные суммы и дельты, а гнать файл не глядя"? и если он есть, то хорошо ли это для копирования на флешки?) > > вообще. Потому что нигде больше не применяемый и оттого не > > стандартизованный sendfile(2) вдруг взял и разучился копировать между > > файлами. > > Fall back to read/write все делают. Если нет жестких требований к производительности, то дешевле сразу написать read/write, чем писать sendfile и fallback на тот же самый read/write. А если есть, то какой нафиг fallback? Нет, я понимаю, есть узкий класс задач, где это имеет смысл. -- Unix-like -- для кинестетиков, Emacs -- для аудиалов, Mac -- для визуалов, Windows -- для чайников -- RockMover in <[email protected]> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/87hb4wpdwk.wl%[email protected]
