Приемущества и недостатки ФС для временных данных, Linux Опции

[RCray]

Два процесса работают через пул временных бинарных файлов. Файлы создаются, удаляются, создаются новые и так по кругу. Число файлов в пике ~1000/сек. По причинам сохранения информации в случае сбоя, нужно какое-то хранилище, а не оперативная память. Размеры файлов фиксированы для двух конфигураций ~1K и ~40К. Интересуют минусы на реальных приложениях 365/24.

Как скоро посыпится диск? =) Будет ли утечка fd?

Есть ли какие-то альтернативы? БД? Можно как-то сконфигурировать легковесную БД, задав оптимальность обращение к диску?

[gemuz]

Добрый день.
Сложно конечно представить себе такую реализацию, но... если есть, то решением проблемы будет SSD Intel DC S3700 200GB (SSDSC2BA200G301) - это диск начального уровня, который сделан для того, чтобы на него постоянно писали и читали с него.
Как достигать Вам еще большей скорости на запись и чтение?
Все как всегда просто. Пример берем такой. У вас максимальный требуемый объем данных, который будет писаться - это 40 Гб, то Вам нужен диск на 300-500 Гб. Разметка очень проста, размечаем только 40 Гб, а все остальное остается как есть. Это нам позволит увеличить скорость записи, срок службы, так как сбойные кластера будут заменяться. Главное учесть, что диск должен быть не дешевый (для дома), а интерпрайз класс.
Срок службы примерно 5 лет, но все зависит от типа диск и объема информации


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