Буферирование потока данных в файл, Идеи, критика Опции

[DeadMoroz]

Здравствуйте!
Имеется система на Линуксе. Примерная логика части программы такова:
программа получает постоянный поток данных от FPGA (64 байта/мс * 12 каналов), если при этом установлено соединение (100Мбит изернет) с GUI, то весь поток должен передаваться туда. Если соединения нет, то поток должен писаться в файл на HDD (EXT3\4). Размер файла может быть до 170Гбайт на канал (30 дней), 12 файлов соответственно. Данные из потока должны передаваться последовательно, т.е. перестановка недопустима. В данный момент собираюсь реализовать это следующим образом:
1) для каждого из каналов создать/открыть файл размером 230Мбайт (1 час данных), отобразить файл в память с mmap().
2) писать данные в файл в независимости от состояния соединения с GUI как в ФИФО буфер.
3) если соединение установлено - читать данные из файла как из ФИФО буфера, при этом файл не будет превышать первоначального/текущего размера.
4) если соединения нет, продолжать писать в файл, при достижении максимального размера, увеличивать размер файла опять на 230Мбайт (1 час) и делать mremap().
По этой реализации у меня такие вопросы:
1) будет ли это достаточно быстро работать (mmap|mremap)?
2) насколько это все надежно (питание может пропасть в произвольный момент), как делать сброс буфера на диск (как fflush)?
3) что лучше один файл на 30 дней или куча файлов (например 1 час) с точки зрения надежности и быстродействия?
4) какие есть альтернативные варианты?

P.S. Это мой первый проект под Линукс. Подобное ранее не делал. Система на TI OMAPL-138, 128MB DDR, SATA HDD.

[kurtis]

1. В чем вы видите преимущество использования mmap() перед write()/read()?
2. sync() сливает содержимое буферов ядра, в буфер устройства. Но это никак не влияет на надежность, т.к. если данные попали в буфер устройства, то не факт что они попали на физический носитель.
3. Зависит от способа обработки. Если вам нужно 1 раз построить график по данным и больше ничего не делать, то 1 файл вполне пойдет. Но если вам вдруг нужно будет посмотреть что было 23 мая, в 15 часов 12 минут, то искать вы будете долго. Я бы делал за каждый час.

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

[DeadMoroz]

1. В чем вы видите преимущество использования mmap() перед write()/read()?
2. sync() сливает содержимое буферов ядра, в буфер устройства. Но это никак не влияет на надежность, т.к. если данные попали в буфер устройства, то не факт что они попали на физический носитель.
3. Зависит от способа обработки. Если вам нужно 1 раз построить график по данным и больше ничего не делать, то 1 файл вполне пойдет. Но если вам вдруг нужно будет посмотреть что было 23 мая, в 15 часов 12 минут, то искать вы будете долго. Я бы делал за каждый час.

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

1) читал, что с mmaped файлами работа выполняется быстрее (за счет неиспользования swap в том числе)
2) как же убедиться, что данные на HDD? Если сделать повторное чтение, то тоже нет гарантии, что оно не выполняется из буфера(

Спасибо за обсуждение!

[SyncLair]

2) как же убедиться, что данные на HDD?

1. Найти опции к Linux-у которые сбрасывают кэш прямо на диск или уменьшают размер кеша до 1кбайта
2. Железный вариант -- отмонтировать файловую систему
3. Помнить что есть такие файлы -- pipe
4. Не пользоваться Linux-ом а самому железно писать на диск начиная с такого-то сектора и заканчивая таким-то
5. Как вариант создать самому драйвер устройства который достоверно пишет на ж/д

Я одно время был фанатом Linux-а, вот когда задумываешся о таких задачах то думаешь а зачем он тады нужен )). Одна из таких задач -- записать на носитель информацию так, чтобы при отключении питания в ЛЮБОЙ момент записи у нас отставалась возможность прочитать/восстановить новую или старую запись.
Например нууу оооочень важный для системы параметр размером ну в 256 байт.