[Alechin 0]

Имеем контроллер, управляющий неким устройством. Сейчас по всем событиям, происходящим в процессе работы, в терминальный последовательный порт выдается информация о событии и реакции на него в текстовом виде (просматривается на подключенном ноутбуке-терминале). Теперь необходимо этот журнал работы вести на имеющимся в системе флеш-диске с файловой системой (FAT16 - все под DOSом). Ни как на ум не приходит красивое решение по ведению этого журнала.

В предыдущем устройстве аналогичное делал - но там был сеансный режим работы (короткие сеансы с большими перерывами) и поэтому создавался каталог для журнала ("/LOG"), в нем каталог с текущей датой ("/LOG/070828/" для 28 августа 2007) и далее для текущего сеанса текстовый файл с именем, сформированным по времени начала сеанса ("/LOG/070828/13-25.log"). По окончании сеанса файл закрывался (fclose). Все было хорошо - и искать удобно, и при пропадании питания и других сбоях в худшем случае терялась информация только по последненму сеансу.

Здесь же работа ведется непрерывно, хотя и события возникают не чаще 1 раза в секунду, даже в несколько секунд), поэтому вроде как нужен один файл, но тогда при пропадании питания (допустимая ситуация) файл будет не закрыт и вероятно потеряна записанная в него ранее информация. Да и при заполнении диска непонятно как с работать - нужно будет как-то удалять устаревшие записи, т.е. вести "перелопачивание" всего файла. Да скачивание такого файла по медленному порту терминала и ручной поиск информации по какому либо событию (оператором в случае разбора журнала работы) затруднен в текстовом файле в 16 МБайт (объем флеш-диска). Значит разбивать на "короткие" файлы за небольшие промежутки времени? Но это как-то нелогично, ведь процесс работы устройства непрерывен. Да и индексироваться для поиска тоже надо как-то будет.

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

Кто как поступал в аналогичных ситуациях, и вообще, есть ли какие-нибудь правила по ведению логов?

[rezident 48]

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

[Alechin 0]

Хорошо, спрошу немного конкретнее - как организовать циклический буфер записей в файле? Т.е. я должен отслеживать переполнение диска при записи нового собщения в журнал и удалять самые "старые" сообщения? Если это возможно простым способом - то вопросов в ведении журнала не возникнет.

[vmp 0]

Может быть заводить по одному файлу на каждый день?

А слишком старые файлы удалять. Пусть буферами, свободныи местом и т.д. ОС занимается.

[Alechin 0]

Может быть заводить по одному файлу на каждый день?

А слишком старые файлы удалять. Пусть буферами, свободныи местом и т.д. ОС занимается.

Возможно, я уже думал, только день - многовато. При возможном (и допустимом выключении) пропадет журнал за целый день. Я думал минут по 5 делать, тогда надо как-то осмысленно файлы именовать, что бы была возможность поиска по дате/времени как оператором (при "разборе полетов"), так и контроллером. Правда что делать при корректировке времени - переименовывать все файлы? Как-то все сложно и запутанно получается.

[vmp 0]

Возможно, я уже думал, только день - многовато. При возможном (и допустимом выключении) пропадет журнал за целый день.

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

Кроме того, при слишком частой перезаписи быстро кончится ресурс флеш-диска. Я бы больше чем на 100 000 записей не закладывался. Поэтому данные надо где-то буферизировать. При гарантированном питании - в ОЗУ, при негарантированном - либо в ОЗУ с подпиткой, либо в FRAM от Ramtron. Если делаем буферизацию, то данные можно сбрасывать на диск либо по заполнению буфера, либо при смене даты по алгоритму - открыли файл на дозапись fopen(name, "ab"), записали данные, закрыли файл, сбросили кеш.

[Elvin Game 0]

Как с решением задачки? Много времени прошло :07: Если подобные задачи есть еще - у Рамтрона появились FRAM c большим объемом массива - и параллельные и последовательные. И одно из типичных массовых применений FRAM - как раз кольцевой энергонезависимый буфер. Самая большая, правда, всего 4 мегабита (FM22L16, 512кбайт, 8 или 16 разрядов шина данных), зато количество перезаписей не ограничено.

[Alechin 0]

Как с решением задачки?

Пока никак - эту задачу буду решать в последнюю очедь. А поменять файловую систему или применить что-либо другое нельзя - это ГОТОВЫЙ контроллер Octagon 6225, и что в нем есть, то есть, не добавить не отнять :)

[vshemm 0]

Не очень понятно, почему нельзя поменять файловую систему, если флешка в полном Вашем распоряжении. Этот вариант - наилучший, имхо.

Другой способ - создать fault tolerant хранилище поверх фат16. Это довольно трудоемкая задача, если делать "как надо" :) Облегченный вариант - это создавать файлы по n записей или по m кб, писАть в них нужно как сказал vmp - открыть, записать, закрыть, сбросить кеш если нужно. Индексация - по имени или дате модификации (если есть источник абсолютного времени). В идеале, потеряется только текущий файл лога, поэтому остается подобрать нужное значение n или m. Однако, если реализация драйвера фат16 и самой флешки "кривая", то можно потерять все :)

[Edit2007 3]

Лучший вариант - организовать подхват питания. В нормальном режиме файлы писать в ОЗУ (RAM диск). При сигнале отключения питания сбрасывать все на диск (FLASH) и контроллером отключать питание. Иначе диск убить можно, и никакая система распределения записей не спасет.

Вели журнал на контроллере FASTWELL (стоял DiskOnChip) писали файл раз в менуту и через 3 месяца получали отказ диска, дважды. Первый раз списали на дефект, второй раз отключили журнал.

[rezident 48]

Я думал минут по 5 делать, тогда надо как-то осмысленно файлы именовать, что бы была возможность поиска по дате/времени как оператором (при "разборе полетов"), так и контроллером. Правда что делать при корректировке времени - переименовывать все файлы? Как-то все сложно и запутанно получается.

Время не нужно корректировать. Никогда. Корректируется только поправка к этому времени: поправка для коррекции хода "набортных" часов, поправка на летнее/зимнее время, поправка для отображения пользовательского (поясного) времени и т.д. В таком случае никакой проблемы поиска по времени создания/редактирования не будет.

[vshemm 0]

Лучший вариант - организовать подхват питания. В нормальном режиме файлы писать в ОЗУ (RAM диск). При сигнале отключения питания сбрасывать все на диск (FLASH) и контроллером отключать питание. Иначе диск убить можно, и никакая система распределения записей не спасет.

Вели журнал на контроллере FASTWELL (стоял DiskOnChip) писали файл раз в менуту и через 3 месяца получали отказ диска, дважды. Первый раз списали на дефект, второй раз отключили журнал.

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

 

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

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

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

 

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

К тому же, при другом сбое (например, программном) весь лог в РАМ потеряется.

 

При нормальном wear leaving'е флешка должна жить довольно долго. Чтобы окончательно решить эту проблему, нужно, как уже говорили, ставить FRAM без ограничения циклов перезаписи.

[Edit2007 3]

Все зависит от конкретной системы.

Если это тумблер на приборе, то при подаче питания паралельно ему замыкать реле (или контактор)

а при отключении (определяется опросом) размыкать реле контроллером после записи данных.

Если же это внешний рубильник тогда сложнее. Тjгда FRAM.

[a_electronic 0]

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