Перейти к содержанию
    

Отказоустойчивая запись на жёсткий диск

Привет, уважаемые форумчане! Имеется одноплатный компьютер, с которого необходимо записывать данные на жёсткий диск, примерно 100 КБ каждые 10 мс. Получится ли использовать стандартную линуксовую файловую систему, каждые 10 мс открывая файл, дописывая новые данные в его конец и закрывая его? Какую файловую систему лучше выбрать? Или без низкоуровневой посекторной записи на жёсткий диск не обойтись? Кроме требования по скорости записи есть ещё требование по сохранности данных при аварийном отключении питания: желательно, чтобы данные не портились при этом и были доступны при восстановлении напряжения питания. Буду рад совету, пишите.

Изменено пользователем Enthusiast

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Привет, уважаемые форумчане! Имеется одноплатный компьютер, с которого необходимо записывать данные на жёсткий диск, примерно 100 КБ каждые 10 мс. Получится ли использовать стандартную линуксовую файловую систему, каждые 10 мс открывая файл, дописывая новые данные в его конец и закрывая его? Какую файловую систему лучше выбрать? Или без низкоуровневой посекторной записи на жёсткий диск не обойтись? Кроме требования по скорости записи есть ещё требование по сохранности данных при аварийном отключении питания: желательно, чтобы данные не портились при этом и были доступны при восстановлении напряжения питания. Буду рад совету, пишите.

Открывать и закрывать при каждой записи файл совсем не нужно - это никак не влияет на механизмы общения ОС Linux с жёстким диском, при закрытии файла кэши не сбрасываются на диск в обязательном порядке. Открытие и закрытие файла - исключительно логические операции, манипулирующие с выдачей и освобождением файловых дескрипторов и статистической информацией о файле (время последнего доступа и т. п.). Для сброса кэша записи на диск нужно использовать sync().

В общем и целом, думаю, что станд. линуксовая ФС типа EXT непригодна для вашей задачи. Более того, низкоуровневая запись секторов на жёсткий диск тоже вас не спасёт, ибо так или иначе вам придётся как-то организовывать эти сектора, то есть по сути с нуля изобретать свою ФС.

Для ваших целей придуманы так называемые "Power Safe Filesystem", правда, в мире QNX. Есть ли такие под Linux - мне неизвестно.

Посмотрите здесь, раздел "Power-Safe Filesystem", там описаны принципы построения таких ФС, также изложено, почему системы EXT таковыми не являются.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для ваших целей придуманы так называемые "Power Safe Filesystem", правда, в мире QNX. EXT таковыми не являются.

 

Причем тут QNX ? COW и снапшоты поддерживают многие ФС. Если бы не экстравагантность разработчика Ханса Райзера (который сидит за убийство жены) - в Linux давно была бы превосходная ФС - Reiser4. Сейчас нужно ориентироваться на Brtfs - правда к ней до сих пор много претензий.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Открывать и закрывать при каждой записи файл совсем не нужно - это никак не влияет на механизмы общения ОС Linux с жёстким диском, при закрытии файла кэши не сбрасываются на диск в обязательном порядке. Открытие и закрытие файла - исключительно логические операции, манипулирующие с выдачей и освобождением файловых дескрипторов и статистической информацией о файле (время последнего доступа и т. п.). Для сброса кэша записи на диск нужно использовать sync().

В общем и целом, думаю, что станд. линуксовая ФС типа EXT непригодна для вашей задачи. Более того, низкоуровневая запись секторов на жёсткий диск тоже вас не спасёт, ибо так или иначе вам придётся как-то организовывать эти сектора, то есть по сути с нуля изобретать свою ФС.

Для ваших целей придуманы так называемые "Power Safe Filesystem", правда, в мире QNX. Есть ли такие под Linux - мне неизвестно.

Посмотрите здесь, раздел "Power-Safe Filesystem", там описаны принципы построения таких ФС, также изложено, почему системы EXT таковыми не являются.

Чем плох fflush()? Последняя запись данных может быть потеряна, главное - чтобы сохранились все предыдущие данные и файл был доступен для чтения в последствии.

Если записывать данные на жёсткий диск каждые 10 мс, то не откажет ли он от такой частой записи? Стоит ли кэшировать запись, к примеру, раз в 100 мс?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вы еще учтите, что даже если вы с программной стороны все сделали верно, то не факт что данные с буферов накопителя успели попасть в сам накопитель. Сталкивался с проблемой, когда писал софт для обновления прошивки устройства, если сделать sync() и затем сразу выключить устройство, данные часто портились, а если добавить задержку в секунду (мне временные задержки были не критичны), то запись всегда проходила без ошибок. Правда это касалось MMC карточки, но для HDD думаю что-то такое тоже есть, нужно смотреть документацию. Писал через dd, без файловой системы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Решил я не морочиться с низкоуровневой записью на диск и сделал запись данных в обычные двоичные файлы через fopen(), fwrite(), fflush(), fclose(). Данные записаться в двоичные файлы вполне успевают, а при пропадании и последующем восстановлении напряжения питания, на мой взгляд, все предшествующие данные из файлов должны восстановиться из журнала файловой системы ext3.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

нормальное решение зачем усложнять

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...