sendfile в принципе не работает на ядрах 2.6.x?
Судя по man sendfile всё должно работать, а у меня стабильно
возвращает EINVAL. Ядро 2.6.18.
Единственное, что нашёл по этому поводу:
http://ilia.ws/archives/13-sendfile-syscall-and-why-the-2.6-linux-kernel-sucks!.
html
Благо, теперь появился новый способ быстрого копирования - с помощью
splice(), с ним всё нормально работает.
Тестовая программа:
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/sendfile.h>
#include <unistd.h>
#include <fcntl.h>
int main (int argc, char **argv)
{
int fd_in,
fd_out;
off_t offset;
ssize_t last_sent;
if (argc < 3) {
fprintf (stderr, "2 arguments required\n");
return -1;
}
fd_in = open (argv [1], O_RDONLY);
if (fd_in == -1) {
perror ("open #1");
return -1;
}
fd_out = open (argv [2], O_WRONLY | O_CREAT);
if (fd_out == -1) {
perror ("open #2");
return -1;
}
offset = 0;
for (;;) {
last_sent = sendfile (fd_out, fd_in, &offset, 1 << 20);
if (last_sent < 0) {
perror ("sendfile");
return -1;
}
if (last_sent == 0)
break;
}
fprintf (stderr, "OK\n");
return 0;
}
да, у меня anticipatory, но прямой зависимости я не вижу: слишком простая схема, чтение-запись (в обычном cp у меня буфер ~12Кб) против чтения 64Кб в pipe (максимум для pipe-буфера) и записи 64Kb из pipe-буфера в файл...
>Где-то я натыкался на письмо Линуса, где он писал, что это misfeature и
> мы мол её пофиксили.
Ну я писем Линуса не читал. Но по коду могу судить, что в 2.4 соответствующая поддержка была сознательно, а в 2.6 она настолько же сознательно не присутствует. Видимо, действительно генеральная линия партия ушла от этого...