Одновременное чтение и запись «файла»

Предлагаю расставить метки времени и все проверить. В качестве обучения.

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

Мне кажется, что если реально нужно одновременно читать и писать, то надо переходить на mmap

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

) сравнить конечно можно, просто вдруг кто уже сравнивал и подскажет сразу по какому пути идти

Мне кажется, что если реально нужно одновременно читать и писать, то надо переходить на mmap

Учитывая, что в прошлый раз ТС писал:

Нужно писать (иногда одновременно читать записанное) с камеры видеоархив на USB или SD карты в формате MJPEG, для максимального сохранения ресурса и объема планирую выполнять ЦИКЛИЧЕСКУЮ запись без файловой системы напрямую в физические блоки, выделив в начале область под «журнал» из пары 32 байта временная метка + 32 байта адрес физического блока флешки.

То +100500.

а mmap быстрее stdio в записи? потому что чтение - редкая операция, а запись вообще все время, столкнулся даже с тем, что пришлось ondemand на performance переключить, потому что системный процесс «флешки» переходил в какое то там состояние D, что приводило к зависанию, падению устройства и ребуту Падают устройства на ARM

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

Да, для ЦИКЛИЧЕСКОЙ записи - то, что доктор прописал.

Если упираетесь в скорость записи, то тестируйте. mmap для файла - это способ отдать на откуп ОС решить по сколько читать/писать. Для ряда задач он будет быстрее read/write.

В ситуации, когда не успеваете записать все кадры, вероятно, более правильным будет использовать epoll, libuv и т.п. Тогда будет механизм понять, что текущий кадр не сохранить.

В ситуации, когда не успеваете записать все кадры, вероятно, более правильным будет использовать epoll, libuv и т.п.

Прежде чем думать о epoll (который для слежения за одним-двумя fd совершенно избыточен), нужно получить асинхронный I/O. В Linux для этого есть криво работающий aio и новомодный io_uring. Но более разумным решением, на мой взгляд, было бы отрегулировать частоту кадров под реальные возможности устройства. Либо использовать mmap и пусть оно в фоне пишется с той скоростью, с которой может (а что не успеет, то при потере питания пропадает).

да уже и так уменьшил до 10 кадр/сек, кажется это 2.5 мбайт/сек, предельно мало конечно это, хоть и можно мириться.

а как отнесется этот mmap к тому, что я будут скажем 500Гб-1Тб «файлы» так «одновременно» обрабатывать, ведь памяти у меня всего лишь 512Мб???

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

а как отнесется этот mmap к тому, что я будут скажем 500Гб-1Тб «файлы» так «одновременно» обрабатывать, ведь памяти у меня всего лишь 512Мб???

В связи с проблемами с libtorrent, который перешёл на mmap, ValdikSS кое-что резюмировал в Libtorrent 2.x memory-mapped files and RAM usage #6667.

У него цикличная (а не RA) запись на маленького размера флешку (а не многогигабайтный файл).

Не нашёл, где упомянут размер флэшки.

а как отнесется этот mmap к тому, что я будут скажем 500Гб-1Тб «файлы» так «одновременно» обрабатывать, ведь памяти у меня всего лишь 512Мб???

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

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

Просто циклический вариант и для mmap удобен. У mmap главный недостаток в том, что для расширения файла нужно делать ремап.

Флешка не маленькая, думаю это будет в среднем 512GB, в идеале 1 TB

Спасибо вам большое за помощь, но все таки уточните пожалуйста вот даже этот ремап будет ли что то тормозить-переполнять на больших объемах данных? Просто я думал mmap не для больших объёмов и читал что stdio самый быстрый вариант записи и чтения.

У меня последовательная запись и даже последовательное чтение, ра возникает только РЕДКО при одновременном доступе, связанный с чтением

но все таки уточните пожалуйста вот даже этот ремап будет ли что то тормозить-переполнять

А у тебя нет возможности вести архив в своем формате в виде циклического буфера. Заводим файл фиксированного размера и пишем «по-кругу». Никакие ремапы тогда не будут нужны.

Для записи по кругу mremap как раз не нужен - размер файла не изменяется.

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

а что не успеет, то при потере питания пропадает).

А разве mmap гарантирует порядок сброса страниц на диск? Если система решит сбрасывать не в том порядке толку будет от записанных после пропущенной страницы данных?

А разве mmap гарантирует порядок сброса страниц на диск?

Не гарантирует

Если система решит сбрасывать не в том порядке толку будет от записанных после пропущенной страницы данных?

У него поток MJPEG, так что худшее, что может произойти от пропущенной страницы - повредится пара кадров (и потеряются кадры из страницы)

Так мжпег это и есть уже формат, в случае чего можно тупо dd раздела в файл сделать.

Кстати да, в stdio я теряю только конец потока кадров, что не успели записаться

Можно в отдельном потоке дергать msync для перезаписанных страниц в пордяке следования, тогда порядок записи будет более-менее контролируемым

Как вариант - писать последовательно (через stdio или write), а если нужно читать, то делать это через маппинг

Это было бы идеально! но опять вопрос, то что в кеше стдио и/или линукса (первое вряд ли, а после вероятнее), я смогу ммап прочитать? Например, нужен кусок архива близко к концу записи. Или тоже придется принудительно сбрасывать кеш, тогда очевидно seek из разных потоков для одного открытого «файла» будет работать быстрее

решил тут погуглить сравнение записи на носитель mmap и stdio и натолкнулся на такие ссылки

https://groups.google.com/g/leveldb/c/C5Hh__JfdrQ

https://groups.google.com/g/leveldb/c/VM5nYLvLVME/m/Ri8MThbM4I0J

в которых говорится что последовательная запись через stdio существенно быстрее, а для меня это критически важно

однако как бы все таки еще так же эффективно читать записанное параллельно )

mmap только для чтения ОК (спасибо madvise и mlock), для записи нельзя контролировать момент сброса dirty pages из программы, что выливается в рандомные блокировки в самый неподходящий момент и тормоза.

но опять вопрос, то что в кеше стдио и/или линукса (первое вряд ли, а после вероятнее), я смогу ммап прочитать?

Первое конечно нет, второе через mmap прочитается, если файл открыт без O_DIRECT. В таком случае нельзя использовать асинхронный IO (aio), но можно uring.

msync(2)

Нужно писать (иногда одновременно читать записанное) с камеры видеоархив на USB или SD карты в формате MJPEG, для максимального сохранения ресурса и объема планирую выполнять ЦИКЛИЧЕСКУЮ запись без файловой системы напрямую в физические блоки

Как не только поставить перед собой практически бессмысленную цель,

выделив в начале область под «журнал» из пары 32 байта временная метка + 32 байта адрес физического блока флешки.

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

ТС, если бы у тебя была raw flash без wear levelling и алгоритм, который реально пишет только по кругу (timestamp в каждом блоке или ещё что такое), то ещё ладно. Но у тебя не raw flash, и тебе не mmap нужен, тебе нужна две такие штуки: «файловая система» и «не выпендриваться».

Нет, ты что. Всем известно, что файловая система добавляет недопустимо большой оверхед к каждой операции – в отличие от, например, буферизации и записи через stdio, через который пациент пишет в файл raw data.

Если мне не изменяет память, его «хайлоад» это запись с вебки или регика 10 кадров в секунду на флешку. На таких нагрузках и журналирование будет дорогого стоить, доо.

алгоритм, который реально пишет только по кругу

а шо он по вашему делает как не пишет по кругу ))

зы. области нет под журнал и никогда не было, журнал создается в памяти во время первого запуска перечитывая всю флешку, кстати 32гб флешка перечитывается где то за 60-90 секунд и даже меньше если запись остановилась в начале флешки (тада вапще практически мгновенно) иба гениальная идея внедрена - писать вместе с кадром не только временную метку, но адрес предыдущей «серии» (иба время каждого не важно для журнала) кадров.

второе через mmap прочитается

это такая особенность mmap прочитать данные файла из кеша ОС, который пишет другой поток или stdio тоже так умеет? иба как я понял гугл блочное чтение-запись через stdio быстрее mmap

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