Эмуляция O_DIRECT

Да, я бы с удовольствием забил на Линуса, но O_DIRECT не реализован на некоторых файловых системах (например vfat aka fat32).

возможный варинат записал, вызвал posix_fadvise с POSIX_FADV_DONTNEED

Тоже самое.

IIRC, Линус говорил о madvise и о том, что posix_fadvise недоотлажен из-за того, что мало используется.

>оже самое.

тоже это что?
тестовый код?
каким образом измеряется объем кэша?

# echo 1 > /proc/sys/vm/drop_caches

код:

posix_fadvise(fd_in, 0, filesize(argv[1]), POSIX_FADV_DONTNEED);

читаю весь файл, смотрю вывод top - весь файл оказался в кеше

> Линус говорил о madvise

Т.е. предлагаете mmap'ить файл? Иначе никак?

>posix_fadvise(fd_in, 0, filesize(argv[1]), POSIX_FADV_DONTNEED);

эта программа даже не скомпилируется,
posix_fadvise вызывается до или после чтения?

>> Линус говорил о madvise

> Т.е. предлагаете mmap'ить файл?

Предлагаю попробовать. Альтернативно - предлагаю вызывать posix_fadvise так - прочитал кусок файла, вызывал _для прочитанного куска_. Если posix_fadvise и работает, то работает оно на содержимом страничного кэша, а при вызове сразу после открытия файла страничный кэш для него еще пуст.

> Иначе никак?

Не знаю. Линус выражался туманно.

http://anvil.perm.ru/files/sfcp4.2.c

> Альтернативно - предлагаю вызывать posix_fadvise так - прочитал кусок файла, вызывал _для прочитанного куска_.

А смысл? файл уже в кеше

Короче, надо попробовать с mmap'ом

>> Альтернативно - предлагаю вызывать posix_fadvise так - прочитал кусок файла, вызывал _для прочитанного куска_.

>А смысл?

Смысл в том, чтобы следующий кусок лег на это же место в кэше

> файл уже в кеше

Не весь, а только прочитанный кусок

>http://anvil.perm.ru/files/sfcp4.2.c

как-то абсолютно нелогично fadvise используется,
сначала говорите не нужно:
posix_fadvise(fd_in, 0, filesize(argv[1]), POSIX_FADV_DONTNEED);
а потом
bytes_read = read(fd_in, (void *) buffer, BUFFER);

надо делать наоборот,
по аналогии выделил память - освободил.

а для копирования можно использовать splice наверное,
так будет быстрее.
и вызывать posix_fadvise после.

diff можете для моего кода сюда кинуть? Я окончательно запутался.

> а для копирования можно использовать splice наверное, так будет быстрее. и вызывать posix_fadvise после.

у меня glibc старый :(

man splice

No manual entry for splice

Хотя это вопрос и не ко мне :), но всё же: поставь оба вызова posix_fadvise в цикле после вызовов read.

PS splice тебе не нужен - ты же не копируешь файлы, а сравниваешь их, так?

Помогло! Спасибо!

> PS splice тебе не нужен - ты же не копируешь файлы, а сравниваешь их, так?

Эта программулька сначала копирует, потом сравнивает.

Круглосуточный DevSupport @ LOR: всегда рады помочь!

8)

И всё же непонятно, почему posix_fadvise надо вызывать после чтения и что тогда реально значит третий параметр у этой функции.

posix_fadvise - это функция управления вытеснением данных из страничного кэша. Почему после чтения - потому что до него страничный кэш пустой (как правильно сказал fghj: "выделил память - освободил"). Третий параметр указывает, как именно вытеснять указанные страницы (POSIX_FADV_DONTNEED - заменять указанные страницы новыми при первой возможности).

Вышеприведенное не претендует на корректность в рамках любой POSIX-системы - это мое понимание реализации в Linux.

#define _XOPEN_SOURCE 600
#include <fcntl.h>

int posix_fadvise(int fd, off_t offset, off_t len, int advice);

Третий параметр - это off_t len (значение, которого мне не столь понятно), значение advice более менее само по себе ясно.

> Третий параметр - это off_t len (значение, которого мне не столь понятно), значение advice более менее само по себе ясно.

Прохлопал ;( 3-й параметр вкупе со 2-м указывают, на какие страницы распространяется указанный метод вытеснения страниц из кэша.

Так почему в цикле нужно каждый раз почте чтения объявлять posix_fadvise?

ИМХО, потому что posix_fadvise действует на содержимое страничного кэша - новый вызов read заполняет кэш новым содержимым, поэтому нужен новый вызов posix_fadvise.