Надежная запись на диск

Twister
Спасибо. Такой протокол конечно же надежен, но к сожалению, возможности хранить и по возможности дублировать информацию у Sender-a нет, т.к. это аппаратура сборщик данных со множества других датчиков и объем памяти у него ограничен лишь нуждами внутренних операций и буферов для аппаратной отсылки по интерфейсу.

 

Тогда, боюсь, Ваша задача не решаема в таком разрезе, в котором бы Вам хотелось.

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

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

 

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

 

По поводу возможности и безперебойника полностью с Вами согласен, но оно есть как оно есть. Вот и ищу пути в данной ситуации выжать максимум "надежности".
Попробую подвести итоги.
1. Запись производится сессиями (от начала сбора до конца).
2. Каждая сессия - это набор минифайлов, кратным размеру кластера ФС, на которую пижется. Каждый минифайл предварительно наполнен нулями. Минифайлы именуются уникальными последовательным номерамт\и.
3. Запись производится в каждый минифайл, ограничиваясь либо по размеру, либо по времени, добавляя избыточную информацию на случай сбоя. Так же минифайл содержит служебную информацию о размере, контрольной сумме, уникальному номеру.
4. По завершении записи минифайла, по нему выболняется sync и он уже переоткрывается на чтение только.
5. При накоплении достаточно большого кол-ва минифайлов, они считываются в один большой, выполняется sync по большому файлу и в случаае успеха, он открывается на чтение, а минифайлы удаляются.

Дополнения?

 

а как его использовать?

 

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

 

s/клиенты/клиентов

 

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

 

PavPS

Используется-то он сам и всегда - тут тебе нужно разбираться как его обойти или принудительно сбросить, если оно вообще возможно

А в постановке задачи есть искусственный момент - какая тебе разница какие данные пропадут - те которые пришли, но не записались или те которые ещё не дошли?
Принципиально они отличаются только если пославший данные получил подтверждение что они приняты, а потом они не записались - для этого случая лучше усложнить протокол - ввести систему двойного подтверждения:
1 подтверждение - данные приняты
2 подтверждение - данные надёжно записаны

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

 

Booster
Вы поймите, я полностью с вами согласен, но нет возможности менять аппаратуру. Есть аналогичного характера софт, который решает поставленную задачу сбора и у него есть проблемы со стабильностью, но его используют. Если я предлагаю софт, который еще требует модернизации парка машин, то привлекательность предложения будет значительно ниже. С этим уже приходилось сталкиваться на аналогичных проектах. К тому же, если оператор или иные ответственные лица будут даже способствовать (чаще некомпетентность) потере данных (может и не умышленно), то все камни полетят в сторону проекта, после чего приходится долго рассказывать, что не наша вина. Но слово не воробей.... Это тоже этап пройденный. Так что задача поставлена так как поставлена.

Y_Mur
Про подтверждения: подтверждения требуют дополнительной памяти (для хранения тех пакетов, которые еще receiver не подтвердил). Это пока что не заложено, хотя не проблема. Суть лишь в том, чтобы не получить ВСЕ данные до одного, а при записи на диск не потерять то, что записано из-за аппаратной ошибки. Ну или свести потери к минимуму.

 

PavPS
Блин не решаема задача чисто софтово на 1 компе без использования спец сретсв резервирования и защиты: при выходе из строя любой части или всего компа какието данные пропадут адназначна!, чтобы не пропали нужно полюбому использовать избыточность и защиту - не хотите батарейки сделайте запись на несколько компов (необязательно компов можно исользовать любые, хоть пзушки или DVD устройства подключаемые удалённо, на DVD аккумулятор можно простенький нагородить который гарантированно скинит буфер на балванку) сразу, разнесите их на разные ветки по питанию и заземлению.
P.S.
Чисто софтовое решение проблемы стабильности не является надежным изначально, кроме шаловливых ручек операторов есть ещё уборщицы и космическое излучение, а также различные времена года =)

 

PavPS
Один комп с упсом это модернизация? Ну я уже не знаю тогда.

 

PavPS
Не вижу необходимости в изобретении чего то там непонятно зачем.
Если возможно перебои с электричеством то ставим бесперибойник. Если потери части последних данных ни критично, то от бесперебойника отказываются. От него вы отказались отсюда вывод потери части данных не критично. Все дальше минимизировать потери. Для этого делается две вещи. Это резервное копирование. И второе применение средств от логических сбоев: это выбор файловой системы и базы данных.

 

Всем огромное спасибо! Пиши для размышления мне хватит.

 

Это типа шутка, но с долей правды. Надо было сразу оценить в деньгах данные здесь советы. И сразу вариант с UPS стал бы экономически выгодным Чисто программно надежность повысить в принципе нельзя, т.к. дополнительная обработка увеличивает вероятность и цену сбоя, а не наоборот.

 

Ну и еще: 100% надежной системы нет. Поэтому важно правильно запроектировать случаи "восстановления" после сбоев. Большой рейд например , когда "слетели" настройки или при аварийном отключении питания требует до 20 часов на "check consistence". Слава богу на этот раз пронесло, т.к рекавери там вообще необозримое по времени.