Всем привет. Честно говоря не знаю куда писать эту тему т.к. она в принципе касается и железа и ОС и алгоритмов ее работы (имхо громковато звучит). Итак, последнее время меня терзает мысль о надежности ПК, т.к. при наличии таких факторов как статическое электричество, помехи в сети, различные сбои и просто старение и выход из строя аппаратных элементов системы возрастает вероятность такого неприятного процесса как порча данных (в ОЗУ на харде), что как вы понимаете черевато временными, денежными и нервными затратами. Суть: я думаю что сбои в данных подсистемах должны отслеживаться на программном уровне (контрольные суммы, биты четности и т.п.) и, например, если процесс записи\чтения файла завершился удачно я могу быть уверен, что данные корректны. Имеют ли место данные методики выявления ошибок аппаратной части и предупреждения порчи данных в ОС(Linux & windows)? Заранее благодарен. 
PS Ответы типа "делай бэкап" и т.д. не принимаются. (я и так его делаю, просто хочу знать для собственного успокоения, ну и для тех кого беспокоит)

Это сообщение отредактировал(а) fry - 30.1.2009, 17:03

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


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

удачи!

Товарищ модератор, "орать" не хотел, просто по моему читать крупный шрифт ИМХО несколько проще - сделал поменьше. 

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

Размещение данной темы на форуме, по моему мнению, могло помочь найти ответ на данный вопрос не только мне, но и другим, а насчет домашнего задания, при наличии людей на форуме, знающих реализацию ОС и к быстрому ответу на вопрос. В моем случае ответ займет достаточно большое время. Спасибо за внимание.

Привет!

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

теперь к вопросу.
Я еще не понял с какого угла вас интересует ответ:

• с т.з. разработчика ПО для ОС с целью поддерживания и предупреждения коррупции данных

или

• с т.з. пользователя, которому нужно тех. решение, которое не попадёт в ту лужу, в которую вам пришлось попасть по воле случая

?

дальше уже начнем действительно на вопрос отвечать.

Добавлено через 1 минуту и 34 секунды

в общем - да, но если надо поконкретнее - надо ответить на мой встречный вопрос сначала.

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

журналируемые ФС

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

В случае реального примера (в первом сообщении) система win-ws не подавала никаких признаков некорректной работы, хотя присутствовало некоторое "подвисание" системы и журнал регистрации "молча" дополнялся ошибками, хотя корректнее было бы инициировать BSOD при "первой возможности", тем самым предотвратя дальнейшую порчу данных. Используемая ФС не проявляла никаких действий и операции с ней проходили при этом корректно. 

Это сообщение отредактировал(а) fry - 30.1.2009, 23:28

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

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

единственный вариант такой проверки использование цепочки
вычисление контрольной суммы сектора->запись->сброс кэша диска->чтение сектора->вычисление контрольной суммы->проверка
но т. к вам еще нужно гарантировать целостность данных в ОЗУ, то на практике контрольная сума должна вычисляться целиком минуя ОЗУ, т. е использование регистров, а регистры в свою очередь - это тоже аппаратная часть, где возможны сбои...

насколько я понимаю идею совр. компьютерной архитектуры - все компоненты имеют какой-то механизм текущей проверки правильности работы: процессор, основная память, жесткий диск, сетевое устойство и т.д.

Для того, чтобы быть уверенной в корректности работы своего "скелета" ОС регулярно считывает и отслеживает данные об этих компонентах, и всё это происходит на аппаратном уровне, т.е. ОС считывает специальные данные с каждого устройства.
Кроме этого, всегда "by design" пытаются обнаружить не ВСЕ возможные сбои, а НАИБОЛЕЕ возможные и случавшиеся.

O каждом компоненте расписать тут можно свиток, напр., в серверной аппаратуре используется "дублированная память", когда для получения N байтов данных испольуется в 2 раза больше модулей памяти, и контроллер памяти аппаратно реализует какой-то механизм обнаружения и починки ошибок в памяти (напр. ECC)

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

жесткие диски тоже имеют механизмы обнаружения и даже предупреждения неполадок. Одна из технологий - S.M.A.R.T

всё ПО на уровне ОС исходит из принципа "всё работает, пока мне не известно обратное" (это не цитата)
для узнавания, что есть обратное есть несколько "стратегических" решений.

У каждого компьютерного компонента есть разные параметры надёжности вписанные в его документацию, напр. MTBF. При планировке информационной системы в случаях серьёзных затрат от простоя аппаратуры берётся в счет профилактической замены аппаратуры ДО дохождения до этого MTBF.
Кроме этого все эти параметры сравнивают с "операционными условиями".
напр. у большинства компонентов эти условия - какой-то диапазон температуры, атмос. давления, чистоты воздуха и влажности. 
Если поместить аппаратуру в один из "экстримов" этих диапазонов - легко понять, что MTBF укоротится.
Поэтому напр. в датацентрах, обычно специальное кондиционирование воздуха - очистка, просушка и охлаждение до 17-23 (в зависимости от "уличной температуры", чем жарче климат на улице - тем ниже держат этот диапазон)

Также, в организациях с тем высоким риском используют специальное "супернадёжное" оборудование, и накладывают на них слоих "высокой доступности", и различные механизмы защиты от конкретных сбоев:

• от проблем электро питания - UPS сеть с генератором и двойными аккумуляторами.
• от проблем с воздухом (температура, влажность, чистота) - система кондиционирования, нередко на основе жидкого охлаждения, с дублированием, и с датчиками воздуха внутри помещения с обратной связью к автономной сети и сообщениями дежурному
• 24 часовое дежурство в контрольной комнате с методическим просмотром метрик
• данные хранят на системах RAID различного уровня с различными слоями дублирования, обычно пользуются интегрированными решениями, всякими там NAS - вроде EMC, и выше. эти системы не нужно бэкапить - у них это происходит внутри само собой, и делается это на разных уровнях с частотой в несколько раз в минуту (snapshots). даже замена дисков происходит их персоналом, регулярно.
• долгосрочные контракты поддержки оборудования с заведомо оговорённым временем на реакцию/решение, напр. контракт по условиям NBD - next business day. т.е. реакция будет не позже чем до сл. рабочего дня.
• дублирование наиболее критических сервисов и узлов практически простаивающих большинство времени, пока они не понадобились (redundancy -> high availability)

Это неполный список, и я умышленно вообще не затронул тему резервного копирования, по чьей-то просьбе.

Внимательный читатель заметит, что каждый пункт - стоит $$$

стратегия - какое из всех решений использовать, а каким пренебречь - решение серьёзное, которое может и сэкономить, и погубить. Но главное - это всё решается.

Далее, к корню:
Я понимаю, что вы вдались в эту тему по причине огромных неприятностей причиненных вам из-за какого-то случая сопряженного с потерей данных. Я не берусь быть "учителем", и т.д, и возможно то, что я пишу сейчас - брутально. Но это соответствует действительности.

То, что вы спросили сам вопрос: "как этого можно избежать в будущем?" - это очень хорошо.
а вот то, что вы ограниченили свой вопрос дополнением до
"как этого можно избежать в будущем посредством только ОС линукс?"
подчеркивает, что вы идёте по принципу "и рыбку съесть, и денег не заплатить".
это конечно идея неплохая, но иногда - нереализуемая:
только программным путём, причем без поддержки самой аппаратуры на "железном" уровне каких-то механизмов текущего мониторинга и может даже "предсказания" сбоев, этих сбоев не избежать.

Кроме того, вы (как и большинство других хомо-сапиенов) используете компьютер для работы, т.е. для получения прибыли.
Так отнеситесь к бизнесу серьёзно: есть доход, есть и текущие расходы.
Не брать в счёт тех. сбои при полном отсутствии решения проблемы сбоя - несло в себе довольно легко просчитываемый риск сбоя. 
И кто это не взял в счет - не важно уже. Главное - вынести из этого урок на будущее, а не травму (т.е. неосмысленный подсознательный страх)

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

Удачи.

С.У.В., и ИМХО.

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

хм, пример можно?

пример: S.M.A.R.T + smartd
ещё - всякие данные в /proc, /sys, сама подистема syslog
большая часть диагностики считывается драйверами, и превращается в ошибки.

ну ОС тут не причем ;)

я просто придрался к фразе, что именно ОС осуществляет мониторинг

hmm...
без общей терминологии что есть "ОС" это довольно понятно. 
ясно одно: моё определение ОС намного ширше чем твоё 

но, я всё равно думаю, что я прав ;) поясню:

драйвер любого устройства должен проверять статус устройства до/после операций над этим устройством.
этот результат - не всегда 0/1

чем это не мониторинг ?

Происходит ли какая либо попытка предсказать возможные проблемы ?
не знаю, но возможно.

Если я не прав, прошу поправить.