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

Никакая файловая система (и никакое железо) такого не переживет. Разве что раскошелишься на гигабайтную флэшку...

Ну это читать надо !
Делаеш линух на дискетке ! пихаеш туда прогу!
тока надо чтобы дисковод дискетку непортил при включении
выключении! Вроде есть такие умные !
Ставиш винт неважно какой ! Главное чтоб он сам ненакрылся!
Пихаем дискетку в дисковод !
Включаем питание!
Грузиш ядро в память ! запускаеш fdisk сносиш все
бьеш винт на разделы ! mkfs!
с дискетки все разворачеваеш на винт
и все запускаеш наверное классно получится !
Ну логи прийдется слать куданибуть на стабильное !

Где то дока была на эту тему!

Да ежели памяти много (в чем я сомневаюсь) то можно и без
винта обойтись ! Тогда все круто будет!

Да если поразмыслить то можно поставить первый винт в
read_only аппаратно и монтировать в read_only!
все с него грузить и разворачивать на второй !

Вобщем нема денег занимаемся гемороем :-(

Попробую более точнее сформулировать вопрос,
на винте надо хранить небольшую БД которая в процессе работы обновляется.
Но так как linux-овый ext2 все операции с диском здорово кэширует,
то вероятность потери данны при сбое очень велика.
Интересно чтобы было нечто похожее на транзакции, то бишь я
я сам мог управлять работой кэша, скажем я накапливаются изменения
в файлах А,В и С, потом я говорю "записать на диск" и происходит
запись всех изменения на диск, если перед "записать на диск" вырубился свет
то файлы А,В,С останутся в предыдущем состоянии. Конечно
если свет вырубят в момент физической записи, то получится херня.
Но вариант такого события уже намного маловерояней, и его можно обойти.

Ты упоминал про доку. Если можно поподробней.

Про доку сразу нескажу !
Исчи на тему watchdog или удаленных роутеров нв линухе!
Про этот изврат есть две статейки!

А про кешерирование были грабли man fsynk должно помочь!
Но так непрокатит может аккомулятор от мотоцикла через диод на
5 вольт и на 12 от машины!
Неполучится что либо на диске хранить !

Нет таких крепостей которые небрали большевики :-).
Конечно к 0-я вероятность потери данных свести не удастся,
но до разумных пределов я думаю можно.
Просто интересно если кто нечто подобное делал? Отзовитесь.

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

поставь журнализируемую FS - reiserFS (будь там пеньтиумы сказал бы поставить NTFS :) По крайней мере журнализирвоанные FS гарантируют не противоречивость логических записей на диске.

Записали A,B,C umount; mount записали A+B+C; umount; mount; стерли
A,B,C. Жуть, а что делать? Еще лучше, если база и A,B,C на разных
разделах, причем слет нафиг одного 100% не должено сказываться на
восстанавливаемость задачи.
PS: это я придумал только что, не серчайте если что...

без UPS'ы хотя бы для аварийного завершения только вешаться остаётся

А кого колышет целостность метаданных FS, когда нужна в первую очередь целостность файловых данных? Журналирующие FS не помогут (тем более NTFS, где журналирования что-то и не видно, так лихо она умеет слетать).

2vsl: не надо на счет слетать, еще не разу не видел, хотя выключал нт просто кнопкой питания часто...
2temofey: разбей диски на три раздела: boot, там где база писать будет и все остальное, тем самым ты уменьшишь вероятность слета вообще всего и глянуть как система синхронизирует когда используются magic key и сделать тоже самое, наверняка есть соответсвующий ioctl и вот вызывать его перодически.

Слетает NTFS со страшной силой, еще веселее, чем ext2... Ну а всякие там извращения с синхронизацией ни к чему хорошему все равно не приведут. Файлы базы данных угробить элементарно, они посложнее любой fs будут...

Граждане какой UPS, UPS - будет стоить больше чем таже вонючая тройка,
на которой все будет исполнятся.
2Org: Что такое magic key?

Такой вопрос - какой минимум ОЗУ на которой будет крутится линукс?
Сразу говорю никаких сетевых примочек не надо.

а причём тут метаданные, SIGPWR handler при достаточном количестве времени (например, ups на 30 секунд) выведет программу к выходу за ручку и всего хорошего пожелает.

2temofey: magic-key это комбинация sysrq+еще одна клавиша. В линукс используется в лсучае глобального зависания для того чтоб прибить, сохранить данные перед тем как нажмешькнопку питания. Соответствующая документация лежит в /usr/src/linux/Documentation. Кстати ты еще можешь делать бэк-ап на лету (PostgreSQL это умеет), и бэк-ап переписывать на один из не активных разделов. Будет выглядет так (раздел B - back-up( желательно reiserfs), A - куда база данных пишет (все равно какой, этот раздел после каждого unexpected reboot должен быть пересоздан) ):
1) делаешь бэк-ап, на A
2) копируешь его под уникальным именем на B (если в этот момент вырубят питание, то этот бэк-ап улетит)
3) на разделе B хранятся предыдущие бэк-апы, последний из них имеет линк на last-good-backup (lgb)
4) после перезаписывания перекидываешь линк lgb на только что скопированный бэкап (Если вырубят питания на этом месте, то из-за того что журнализированная ос сохраняет метаданные, линк не улетит в неизвестность, а будет показывать на предыдущий бэкап, и даже если вылетит fs, то вероятность такого события ничтожна, т.к. перекидывание линка оооочень быстрая опперация).
5) при unexpected reboot (т.е. система при старте пишет куда-то, что она загрузилась, а при нормальном shutdown'e что нормально выгрузилась) раздел A удаляется и пересоздается, туда же копируется lgb. Возможен как вариант перед удалением проверить целосность базы и на этом основании принимать решение об удалении.
Таким образом у тебя всегда есть last-good-know-state. Частота делания таких бэкапов определяется эксперементально.
2vsl: я не собираюсь тут флеймить, это не фронтпэйдж сайта и не прикольно. Опубликуй новость про НТ Sucks на главной странице и я с удовольствием буду флеймить.

Спасибо, чегото вроде этого я и думал.

И всетаки какой минимальный обьем ОЗУ для Линукса?
В 1Мб влезет? Или это не реально?
Еще вопрос - возможноли сжатие данных на лету на уровне
файловой системы?

2temofey: 1мег это очень очень мало. У меня есть ноутбук 486dx2 66 c 8 мегами, заргузка на нем RH6.2 с выключенными по макисмуму демонами вглядит очень душераздирающе. Тебе придется выкинуть из системы все не нужные модули (т.е. тереть с диска, чтоб не мешали), но все равно для работы нужно хотя бы 4 мега, чтоб это все как-нибудь еще и шевелилось.

Надежности по дешевке НЕ БЫВАЕТ в принципе. Или ты за копейки соберешь убожество, которое сдохнет через месяц, или потратишь в два/три раза больше, и получишь надежную систему, которую один раз поставил, и забыл. И вообще, объяснил бы, какая задача... Промышленная железка, или что еще?

Linux kernel gruzitsya s adresa 1mb t.e. eto ne proidet ...
dumau chto na 4mb on zavedetsya ... koe-kak

Понял. Спасибо.
2vsl: если затраты в 2-3 раза больше то вопрос сам собой отпадет.
Тогда себестоимость получается высоковата. А задача - построить
нечто вроде кассового аппарата.

По поводу кассовых аппаратов!
На сегодняшний день выглядит так!
Стоит флаш маркировку непомню гдето на 16 киллобайт!
Все что бьется пишется во флэш!
Вечером при снятии отчетов ! все дневные чеки плюсуются и
записывается общая выручка в ПЗУ на 256 кил (64 кил)!
одной строкой.

Лет на 10 хватит ежели небольше :-)

Флэшка простая как 3-и рубля обойдется в 50 руб микросхема
+ 100 руб рассыпуха микросхем(+ПЗУ РФ8) для адаптера!
Подцепиш это все к com или lpt но вот прогу писать самому
прийдется !

Я поминал и про другой, дешевый вариант: завести сервер, который все такие аппараты обслуживал бы, и сетку протянуть. Или аппарат один нужен?

Аппаратов нужно много. Но они работают в автономном режиме, никаких сетей.

Сделайте как раньше было в Сбербанке - провели операцию, на матричнике печатается строчка лога :). А на счет mount/umount - неужели идея не понравилась? Она ведь абсолютно рабочая при одном дополнении: на обоих файлухах нужно создать файлы, заполнив их не нулями, размером равным кешу диска (железного) и после демонтирования, диск должен быть подмонтирован с noatime, a туда опять писать эти единицы, не стирая, а прямо поверх - тем самым гарантируется сброс апаратного кеша при демонтировании и неизменный суперблок.

Пачему не нравится, все мне нравится - основные идеи понятны. Будем пробовать. Есть еще вопросы. Про возможность сжатия данных ФС на лету. Возможно ли? И еще кто нибудь работал с мини дистрибутивами? Интересует следующее - есть скажем минимальный набор всякой билиберды: поддержка IDE, PCI, ISA, VGA, LPT + пользовательская программа. Какова вероятность того что на случайно взятый комп начиная с 386го - все это станет без проблем?

Насчет сжатия - не пробовал. Министрибутив есть и свой:
ftp://ftp.simtreas.ru/pub/my/my-rescue-disk

Сжатие для ext2 есть, и вполне нормально работает (я за 3 года использования e2compr на проблемы не нарывался), но все же оно очень сильно снижает надежность. Так что лучше забыть. Я таки не понимаю, чем плоха сеть? Это не сильно дорого получится, дешевле, чем весь тот трах, который ты поимеешь, добиваясь надежности. Кроме того, на винтах поэкономишь...

Я против сети ничего не имею, но как ты собираешься провести сеть скажем в несколько сотен организаций разбросанных по всей стране и разных по уровню - начиная от киоска продающего жевачки - до супермаркета? Хотя наше мудрое правительство хотело нечто подобное сделать - в каждом киоске к кассовому аппрату приделать радиомодем и чтоб данные о каждой покупке бутылки пива прямиком отправлялись в к фискальным органам. Во как. Прямо план ГОЭРЛО. Слава богу ума хватило отказатся.

? ??? ?? ???? ?????? ?????????? ??? ?????? ????????-??????????? ? ???????????

Вас ис дас? :-)

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

Может я и не в тему, однако жа припомнился мне тут ROM DOS. Творение небезизвестной Calder'ы

(не надо меня бить!)

Сам по себе ДОС может работать с новелловсой сеткой. Итого: ДОС в ПЗУ (а можно и прогу), сетевой адаптер, и провод. До сервера.

Если все же интересно, то можно поискать на калдеровском ftp. Что-то вроде embedding dos...

Граждане я может не по руски говорю в 10-й раз,
_сетка в условиях задачи отсутствует как понятие_.
Повторю еще раз что меня интересует:
Интересует следующее - есть скажем минимальный набор всякой
билиберды: поддержка IDE, PCI, ISA, VGA, LPT + пользовательская
программа. Какова вероятность того что на случайно взятый
комп начиная с 386го - все это станет без проблем?

А чем umount; mount; _save_; umount; mount лучше, чем sync; _save_; sync ?

Я бы сделал так: два раздела - система+прога и данные(наименьший раздел). Система всегда readonly, данные либо read-only постоянно, remount rw при записи либо raedwrite всегда, при падении питания fsck в любом случае пройдет быстро.

Если не будешь увлекаться новшествами типа ядра 2.4.0, то работать будет норамьно, особенно если из того списка выкинуть PCI, и все, что надо, скомпилировано под i386.

А по поводу памяти - работал у меня Slackware 4.0 на 386+4Mb. Без компиляции и иксов работал нормально, даже свопа больше 8Mb не требовалось для tetex'а.

temofey: Слушай, а ты уверен что для твоей задачи необходим именно линукс? Может быть на самом деле дос хватит? Там и памяти мега достаточно, и с железом проблем практически нет. Писать можно на винт через bios в конец _устройства_ - что то вроде своей ФС. Дос и ФАТ проще в этом отношении. А если волнует "легальность" - возьми FreeDOS. Или у меня еще интереснее валяется - сырцы килобайт на 20 в асме - вроде доса. Даже проги запускает многие.
P.S. За упоминание "не-линукса" сильно прошу не бить :)))

> акова вероятность того что на случайно взятый
> комп начиная с 386го - все это станет без проблем?
Высокая.
А надёжность... ReiserFS с сокращённым до минимума временем "отброса" (в ноль его! man fstab!) минимизирует возможные гондурасы.

А я бы посоветовал использовать в качестве файловой системы AdvFS . Ибо устойчивая она к сбоям и очень быстро проверяется - проверено на собственном опыте

2eliterr:Насчет убрать поддержку PCI - так проблематично, потому как
видеокарта на PCI, тоже может сидеть. А что PCI - настолько проблематичная
штука?

А насколько ReiserFS требовательна к памяти? И возможноли ее криптование?
И как она со старыми ядрами дружит?

Ya bolshe goda nazad zanimalsya primerno shozhei problemoi dlya odnogo iz holdingov v Moskve. Delal dlya nih korporativnuu sistemu peredachi elektronnyh soobshenii. Odna iz zadach byla sleduushei - neobhodimo bylo avtomaticheski peredavat' dannye iz proizvodstvennyh podrazdelenii (tam beton izgotavlivaut, poetomu vsudu cementnaya pyl', gryaz' i polnoe otsutsvie ludei hot' chto-nibud' ponimaushih v komputerah). My ispol'zovali tam svyazku pochtovyi server (Linux) + DOS client. Na servere modem, nastroeno uucp+sendmail i svoi sobstvennyi soft dlya avtomaticheskoi peredachi failov v central'noe podrazdelenie. Dos client imeet dostup k Linux cherez ncpfs (na Linux zapushen mars-nwe) Tak vot, dlya togo chtoby sdelat' server poustoichivei bylo sdelano sleduushee. Kornevoi rasdel montirovalsya v rezhime read-only. /tmp i /var zavedeny na otdel'nyae razdely. Krome togo master obrazy /tmp i /var hranyatsya v kornevom razdele (dopustim /images/tmp i /images/var). Ya perepisal rc.sysinit (my ispol'zovali RedHat5.2) sleduushim obrazom. kornevoi razdel ne proveryaetsya fsck nikogda tak kak povrezhdeniya failovoi systemy voznikaut v osnovnom pri rabote v rezhime read-write. Esli pri proverke /tmp ili /var fsck vozvrashaet oshibku, to my prosto formatiruem eti razdely (mkfs.ext2) i kopiruem na nih obrazy /images/tmp i /images/var iz kornevogo razdela. Dopolnitelno tam stoit UPS i zapushem programmnyi watchdog. Nu i prishlos' neskolko dopolnitelnyh usilii prilozhit', chtoby nekotorye faily iz /etc (i celikom /dev) v kotoryie vse taki proishodit zapis' pri rabote systemy peretashit' v /var. V itoge my poluchili pochtovyi server, kotoryi mozhno smelo vykluchat' bez shutdown i voobshe obrashatsya s nim ochen' vol'no (ludi kotorye tam sidyat znaut pro server tolko to, chto esli chto-to ne tak, nado vykluchit' UPS iz seti i podozhdat' 10 minut). Poterya dannyh konechno vozmozhna, no s etim tam mozhno miritsya, esli voznikaut problemy oni prosto povtoryaut otsylku failov. Bylo ustanovleno 7 takih serverov i oni rabotaut v avtonomnom rezhime uzhe bolshe goda bez sboev. Fedor.

> А насколько ReiserFS требовательна к памяти?
Примеро как ext2, но чем больше - тем лучше.
> И возможноли ее криптование?
Непрямую - нет, можно через loop-устройства.

Насчёт старых ядер... 2.2.16 и 2.2.18 - Ok.

Но всё равно - однозначного ответа в Вашей ситуации никто не даст....

Я бы вообще ДОСом в этой ситуаци обошелся. Если хочется unix-like - можно встраиваемые ОС глянуть (типа ECOS от того же RedHat) - но я сомневаюсь что они на x86 хороши. Короче, с досом намного проще будет IMO чем с linux'ом.

/etc/fstab: <br>/dev/hda1 / ext2 defaults,sync 0 0 <br>И потри скэшированных данных небудет. Плохо будет только если рубанут свет во время физической записи данных на винт. <p>Про 1 Мб памяти забудь, минимум 4. <p>Можно сделать неувалимый линух -- / монтировать в ro, БД держать на /var. Но, ессесно в таких условиях целостности данных не добьешся. Увы.

Уважаемый ! Я не знаю, че у вас там за контора и какие задачи вы там себе ставите, но хочу довести до Вашего сведения, что использовать кассовый аппарат, которого нет в реестре, низзя. Вам налоговая этого не разрешит. А реестр Вашу поделку протащить нельзя по многом причинам. Во-первых, насколько я понял, Вы не планируете оснащать этот Ваш аппарт флэшкой, а кассовый аппарат эту флэшку обязательно должнен иметь и должна эта флэшка иметь защиту от порчи содержимого хулиганами или некорректной работой Вашей программы. Эта штука называется фискальной памятью и без нее Ваш аппарат кассовым называться никак не может. Есть также много других вещей, из-за которых из IBM PC под Linuxом нельзя кассовый аппарат сделать. Как Вы уберете возможность пользователя переключиться в другую задачу и начать изменять/просматривать файлы ? Ведь за машину может сесть и человек нехороший... Короче, проблема та еще, и правильно гороворя людит, что для таких вещей традиционно используется MSDOS. Других вариантов пока нет. Вот Windows 95 еще, может быть. Dmitry Sanarin sdb386@hotmail.com

2Dmitry Sanarin:вы случаем не в налоговой работаете? Спасибо что просветили,
а тож мы находились в пучине невединия, и еслиб не вы, то и прибывали там
поселе ;-). Насчет налоговых и всяких реестров - в курсе. В настоящее время
имеется такая поделка, которая "протащена" вопреки всяким злопыхателям
через налоговую, и успешно используется пяток лет. Правда написана
она на клиппере под дос, и от нее уже чуть отдает тухлятинкой. Вот
и встал вопрос переписать ее заново. Тем более что граждан
"хакеров" секущих как перехватывать прерывания,
и ломать программы, под линуксом поменьше будет.
"Как Вы уберете возможность пользователя переключиться в другую задачу и начать
изменять/просматривать файлы?" - это помоему не проблема, как раз в
линукс это зделать гораздо проще, т.к. разграничение прав доступа
имеется, и пускать пользователя только туды куды надо - делается
элементарно.

И еще - посмотрел бы я как win95 будет пыхтеть на тройке с четырьмя
метрами памяти.

Без ГУЁв -- отлично. А на 386 и 4Mb RAM Х-ы запускать быстрее не будет.

Про Х-ы речь не идет.
Речь идет только о консоли. И собственно что из себя представляет
Win95 без ГУИ? Тот же голый дос.

А почему бы не обращаться напрямую к одному из разделов. Не нужно никакой файловой системы. Через файл-устройство, например, /dev/hda4. Я так понимаю, что записи нужно делать небольшие, но в большом количестве. При пропадании питания наверняка данные успеют сохранится на тех крохах енергии, что остались в конденсаторах блока питания. И ничего восстанавливать после отключения питания не нужно. И кэшированием самому управлять прийдется. А вот насчет инсталяции RedHat 6.2 на i486DX2-66 с 4 Мб ОЗУ. Это только разве что ради эксперимента. Я например, придерживаюсь мнения, что версия Linux, напрямую зависит от аппаратных средств компьютера. Тем более для тех компьютерах, которые теоритически не могут быть подключены к сети (согласно ТЗ). И приемлемый уровень безопасности и работает нормально и быстро. У меня например, когда-то терминальный сервер на i486DX4-100 с 32 Мб ОЗУ очень даже неплохо 20 пользователей обслуживал в тексте естественно.

2timofey: Во-первых, построить зашищенную от сбоев систему для использование в e-commerce на одной единице в принципе не возможно. Нужна вторая, серверная часть. Во-вторых, без транзакций у вас ничего не выйдет. Я рекомендую использовать транзакционный сервер(известный севис CORBA) плюс в качестве хранилища данных любой доступный SQL сервер, например MySQL или PostgreSQL. Dmitry Yusupov <dmy7@yahoo.com>