Разработка ПО устойчивого к сбоям под Linux

2anonymous (*) (2001-01-19 20:53:02.0) : Спасибо за идею, довольно интересный подход!А что при работе напрямую с /dev/hda4 - сама OS никакого кэширования не проводит? И еще такой вопрос: если к примеру /dev/hda4 - это логический раздел,
и я открыв его как файл, возьму и начну писать, и превышу его размер,
и начну писать за его пределы. Как в этом случае поведет себя ОС?

2Dmitry Yusupov: Где в моих вопросах вы видели слово "e-commerce ", или
узнав новые для себя и красивые слова "зашищенная от сбоев система",
"e-commerce", "транзакция", "серверная часть", "CORBA", "SQL сервер",
"MySQL" и "PostgreSQL", вы решили блеснуть эрудицией и применить их в разговоре?

Насчет кэширования я точно не знаю. Если чесно я никогда не работал с разделами на таком уровне. Это так голая схема, которая требует дальнейшей проработки. Единственное могу сказать, что когда выполняется дамп дискеты командой dd кэширования вроде никакого не происходит (по крайней мере визуально не заметно), как например, если просто работать с дискетой как с объеком, на котором размещена файловая система. Очень может быть, что и при работе с файлами устройств разделов происходит то же самое. Учитывая иерархичность постоения Linux кэшированием занимается файловая подсистема ядра, которая использует это файл-устройство для доступа к структурам данных расположенных на разделе (а файл устройства это как известно точка входа в драйвер, который располагается на самом нижнем уровне иерархии ОС, это потом выше идет кэширование и остальное). Единственное что меня беспокоит, так это аппаратное кэширование, расположенное на самом винчестере. Но я так понимаю, что наличие большого кэша на винчестере не предполагается, так что даные наверняка успеют сбросится. (Если это вообще не функция аппаратуры сбрасывать кэш винта при обнаружении сигнала "плохое питание" шины). А вот про размер, то средствами операцинной системы можно определить общий объем винчестера, объемы разделов, которые имеют файловые системы и просто подсчитать максимальный объем раздела без файловой системы. И в программе вести соответствующую статистику. Я думаю, что для успешного функционирования программы необходимо будет в начале раздела разместить переменную, содержащую общее число записей на разделе. При этом увеличивать ее значение только после того как запись занесена на раздел. Таким образом вероятность нормальной работы программы значительно повышается. Даже если в момент выключения питания будут сохранятся данные, то затем они не будут учитываться, так как счетчик не инкрементировался. А поскольку размер записи известен, то можно подсчитать число записей, которые можно разместить на данном разделе, узнав предварительно его объем. Если раздел закончился переходить к началу, сбросив счетчик. Можно так же предусмотреть переменную на разделе, говорящую о том, что раздел когда-то закончился и счетчик был сброшен. При этом можно получить и старые данные. Alexsey Nadtochey - <irbis@ai.kharkov.com> (прошу прощения что не представился в прошлый раз)

Ну, для того, чтобы сама ОС не проводила никакого кэширования, достаточно сказать mount /dev/hdxy /mountpoint -o sync.
Другое дело, что есть аппаратный кэш. А при вырубании питания во время физической записи на винт чревато потререй целостности данных. Причем достаточно серьезной.

Аппаратным кэшем я думаю что в моем случае можно принебречь, во первых веники старенькие в основном, а во вторых, по опыту: в настоящий момент под ДОСом, при криво написанной базе на клиппере, и жестких условия эксплуатации, получаются не такие страшные результаты, скажем так вероятность сбоя 1/250 - 1/500 в месяц. Т.е. из 500 компьютеров - на одном-двух раз в месяц база летит. И это при том что механизмы обеспечения надежности никто не продумывал.