fread/fwrite

наверное setvbuf подойдет…

хотя это буфер библиотеки, а мне видимо нужен буфер ОС

фактическая запись осуществляется либо по fflush

Нет, по fflush фактическая запись не осуществляется.

Note  that fflush() flushes only the user-space buffers provided by the C library.  To ensure that the data is physically stored
on disk the kernel buffers must be flushed too, for example, with sync(2) or fsync(2)

Всё-таки ещё раз порекомендую навернуть Linux System Programming, Robert Love, 2013, главу вторую, там есть раздел Synchronized I/O.

gremlin_the_red

спасибо, а как кеш операционке задать? что то большой получается, тогда бы фсинк не пригодился бы даже, или если я задаю setvbuf и буду делать флуш и следом фсинк, то запись блоками по размеру в сетвбуф пойдет?

или вообще лучше не мешать операционке работать!? просто кеш почти 200Мб, при памяти всего в 512

Роберт Любовь конеш четкий писатель, но если Вам не сложно можете подсказать, что конкретно нужно сделать, чтобы делаю я кучу врайтов, а на диск пишется четко кеш выравненный по размеру сектора? да чтоб этот кеш еще не занимал 30% оперативки

спасибо, а как кеш операционке задать?

Никак. Кэш записи можно ограничить параметрами vm.dirty_bytes/vm.dirty_ratio

или вообще лучше не мешать операционке работать!?

Да.

просто кеш почти 200Мб, при памяти всего в 512

Free mem — wasted mem ©

vm.dirty_bytes/vm.dirty_ratio

спасибо, разбираюсь.

Непонятно почему тебя вообще это беспокоит. Ну да запись отложенная, но так или иначе данные будут записаны. Тебе не нужно по этому поводу ничего специально делать.

потому что памяти мало, 30% занято кешем это архи много + может питания пропадать на железке, которая пишет видео

конкретно нужно сделать, чтобы делаю я кучу врайтов, а на диск пишется четко кеш выравненный по размеру сектора

Ничего не нужно делать, это всегда так.

dd не создает такой хрени, так что не всегда

30% занято кешем

Нет, 70% занято кодом/данными, остальное свободно и используется под кэш.

размер блока данных (jpeg кадра) от 50кб до 200 кб, при этом кеш от 5% до 30%, в коде не меняется ничего при этом.

ну не выделяю я нигде 200Мб памяти… рост в 1000 раз происходит, только когда писать начинаю 15 раз в секунду по 50 или 200 кб

потому что памяти мало, 30% занято кешем это архи много + может питания пропадать на железке, которая пишет видео

общая идея кешей такого рода в том, что ос думает - раз ты память не используешь, то использовать ее буду я.

уменьшением такого кеша иы лучше не сделаешь. просто будет бестолку у тебя находиться в системе пустое озу.

наличие такого кеша вовсе не означает что данные не сброшены на физ носитель. они наверняка давно сброшены, но находятся и в кеше(то есть никому не нужном куске озу) на случай, если тебе их вздумается почитать.

в нормальных ос и фс размеры физ буферов из которых делается сброс на блочный физ носитель или чтение с него, всегда кратны размеру блока носителя, а обычно просто ему равны.

наличие такого кеша вовсе не означает что данные не сброшены на физ носитель. они наверняка давно сброшены, но находятся и в кеше(то есть никому не нужном куске озу) на случай, если тебе их вздумается почитать

спасибо, поверю наслово ) хотя какой смысл держать уже записанное в кеше, если я его читать не собираюсь.

про не нужное уточню, размер показывает top используемой памяти моим бинарником, который конечно же меньше 30% (но больше 5%), поэтому и не понимаю откуда такие цифры

в нормальной ФС физический сброс должен происходить по трем событиям

• прямая инициация сброса
• таймер
• превышение размера накопленных данных

плюс данные будут лежать в неиспользуемой памяти(на случай чтения), пока эту память не заберут под другие нужды… типа загрузить еще прогу например.

превышение размера накопленных данных

этот размер задается на уровне ФС или операционки? т.е. речь про использование vm.dirty_bytes/vm.dirty_ratio или в самой ФС какой то волшебный размер задан, связанный с размером логического сектора? (256 кб в среднем по палате?)

либо пиши низкоуровневыми не буферными колам и страдай фигней с ручным заходом солнца, если очень надо, либо слушай валенки: пиши буферными и синкайся после записи, особенно если не знаешь что делаешь.

актуально

Ну так прочитай уже как что делается в секциях man 2 и 3 или в книжке про программирование под юниксы/линуксы, где просто и понятно про писанину на диск (если не понятно и не просто — возьми другую книжку), чем плодить темы про пережеванные 100500 раз вопросы. Вариант ответа на твои вопросы «никак» тоже правильный. Обычно говорит о том что ты хочешь странного.

прочитать все подряд конечно хорошо, но мне бы что то покороче, как и размер буфера, который кроме размера меня всем устраивает )

Ну ограничься темой «файловый ввод/вывод» в хорошей книжке где тебе будет все понятно :)

man 2 open? O_SYNC и write() по 512 байт за раз.

Есть stdio буфер в адресном пространстве процесса, и есть блочный кеш в ядре. Можно отключить блочный кеш для файла, открыв его с флагом O_DIRECT. Только буфер в юзерспейсе должен быть тогда выровнен по границе страницы и размером в целое количество страниц:

#define _GNU_SOURCE
#include <stdio.h>
#include <sys/mman.h>
#include <fcntl.h>
int main(void)
{
    int fd = open("file", O_RDWR | O_DIRECT | O_CLOEXEC);
    FILE *f = fdopen(fd, "w+e");
    size_t size = 4 * 1024;
    void *buf = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
    int i;
    setvbuf(f, (char *)buf, _IOFBF, size);
    for (i = 0; i != size; ++i)
        fprintf(f, "hello, world!\n");
    fclose(f);
    return 0;
}

strace:

openat(AT_FDCWD, "file", O_RDWR|O_DIRECT|O_CLOEXEC) = 3
fcntl(3, F_GETFL)                       = 0xc002 (flags O_RDWR|O_DIRECT|O_LARGEFILE)
brk(NULL)                               = 0x8f1000
brk(0x912000)                           = 0x912000
brk(NULL)                               = 0x912000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f389f632000
write(3, "hello, world!\nhello, world!\nhell"..., 4096) = 4096
write(3, "orld!\nhello, world!\nhello, world"..., 4096) = 4096
write(3, "llo, world!\nhello, world!\nhello,"..., 4096) = 4096
write(3, "ld!\nhello, world!\nhello, world!\n"..., 4096) = 4096
write(3, "o, world!\nhello, world!\nhello, w"..., 4096) = 4096
write(3, "!\nhello, world!\nhello, world!\nhe"..., 4096) = 4096
write(3, " world!\nhello, world!\nhello, wor"..., 4096) = 4096
write(3, "hello, world!\nhello, world!\nhell"..., 4096) = 4096
write(3, "orld!\nhello, world!\nhello, world"..., 4096) = 4096
write(3, "llo, world!\nhello, world!\nhello,"..., 4096) = 4096
write(3, "ld!\nhello, world!\nhello, world!\n"..., 4096) = 4096
write(3, "o, world!\nhello, world!\nhello, w"..., 4096) = 4096
write(3, "!\nhello, world!\nhello, world!\nhe"..., 4096) = 4096
write(3, " world!\nhello, world!\nhello, wor"..., 4096) = 4096
close(3)                                = 0
exit_group(0)                           = ?

1. Если возможно не используй fread/fwrite/fflush — они для других задач
2. Пиши весь кадр одним write/writev. Если прям сильно хочется кусками - не стоит резать мельче чем 128 килобайт.
3. И как тебе уже обьяснили — твое узкое место — журнал. Держи хотябы три копии, и как только одна из копий наебнется — требуй смены SD-карты

Я сделал буфер 256к у библиотеки стдио и рассчитываю, что он выталкивается этим размером в кеш на запись, журнала у меня нет, я просто пишу в комментариях заголовка кадров, прямой поиск покадрово в таких условиях даёт около 150-300 мб/с при построении журнала, обратный вообще за секунду тестовую 32 Гб флешку перечитывает исходя из пакета 15 кадров * 60 сек

Поэтому не понимаю чем фрид фрайт плохи

журнала у меня нет

ну и отлично

рассчитываю, что он выталкивается этим размером в кеш на запись

тебе подсказывали выталкивать в кеш SD-карты

не понимаю чем фрид фрайт плохи

путаются под ногами