Блокирование сбойных адресов физической памяти в FreeBSD

Класс! В лине небось ентого нету! Патчи не предлагать!

С чего это вдруг патчи не предлагать? Линь сам по себе - один большой
патч к minix'у. Ещё один маленький патчик погоды не изменит.

А в соляре и процы можно на лету менять, что с того?

>перечисленных сбойных адресов

>В лине небось ентого нету!

эта фишка была доступна еще черти когда, причем "bad spots" определяются сами, не недо ничего "перечислять"

Надо память ставить с техн. "чип кил" специально ведь такую делают.

а IBM одно время были серваки с ecc'шной памятью, которые за счет хитрого контроллера в чипсете могли прозрачно для программ пережить выход из строя любого МОДУЛЯ памяти.
вот бы сие реализовать не в чипсете, а в менеджере памяти...

> вот бы сие реализовать не в чипсете, а в менеджере памяти...

... и на каждое (!!!) обращение к памяти программно подсчитывать контрольные суммы? В железе для кода Хэмминга это несколько xor-вентилей (если мне не изменяет память --- в голове ecc не предусмотрено :-) плюс логика возбуждения прерываний на случай невосстановимого сбоя (например, когда код обнаруживает две ошибки, а корректирует только одиночную), а как будет выглядет программная реализация оного --- страшно подумать. Кстати, собственно память, в котрой хранится корректирующий код --- тоже надо защищать, иначе сам этот код в принципе может такого наделать. Ну а еще нужно где-то хранить контрольные разряды (точное их количество считать не берусь, так как оно зависит от вида кодирования).

Резюме: бесплатных пирожных не бывает. :-)

--

SVK

И все равно не поможет! Если ошибка произошла ПОСЛЕ схем контроля

Благими намерениями выложена дорога в ад. При обнаружении сбойной памяти необходимо отписать в лог и сделать shutdown немедленно. Ибо попытка работать на сбойном железе ещё ни разу ничем хорошим не заканчивалась.

Никто не предлагает работать на сбойной памяти. Речь идёт о временном исключении сбойных адресов пока новая память ещё не доставлена.

До Соляры на Спарке и Линуксу, и *BSD, как до Луны пешком (а про вин даже страшно подумать)

Вот когда Билайн с МТС переведут свой биллинг с Е-10000 на Xeon кластеры под Линухом - тогда поверю, что доросли до enterprise

Офтопить то зачем?

>Офтопить то зачем?

IMHO, не офтоп совсем.

>Речь идёт о временном исключении сбойных адресов пока новая память ещё не доставлена.

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

Ну и че? Тоже мне, достижение.

> Вот когда Билайн с МТС переведут свой биллинг

А нахрена им это надо? Они бы как любят тут говорит "лехко!" - просто они трахаться с CBOSS'ом на новой платформе не хотят.

> В лине небось ентого нету

Если не ошибаюсь, довольно давно в инструкции к Memtest86 видел упоминание о том, что, при наличии сбойных адресов, эта прога может создать специальный файл для компиляции ядра Линукса с опцией "BadRAM". Это не оно?

> > Офтопить то зачем?

> IMHO, не офтоп совсем.

Именно что оффтоп. Про архитектуру железа тут речь не идёт.

> > Речь идёт о временном исключении сбойных адресов пока новая память ещё не доставлена.

> Если бы, когда новая память доставлена, было возможно заменить сбойный модуль налету, тогда новость достойна упоминания. А пока, так, возня в песочнице.

Ещё раз говорю, речь идёт не о железе, а о чисто програмном решении. Простой сервера, вызванный сбоем памяти, может исчисляться днями (в обычном случае) или минутами (в случае использования vm.blacklist). Чувствуете разницу?

Понятно что решения в железе лучше, но что делать если их нет? IMHO vm.blacklist всё же лучше чем ничего.

> И все равно не поможет! Если ошибка произошла ПОСЛЕ схем контроля

Если я не ошибаюсь, почему нужно было корректировать именно память --- в ней данные хранятся долго и был весьма вероятный источник отказов --- залетные альфа-частицы. Вероятность сбоя при хранении бита в течение, скажем, часа, ИМХО куда выше, чем вероятность сбоя при его полете через АЛУ в течение энного количества наносекунд, хотя, конечно же, и в проводах наводки бывают и все такое.

Кстати, в давние-давние времена, когда советские умельцы делали компы с арифметикой в остаточных классах, для этих машин существовали коды коррекции ошибок, обладающие свойством арифметичности. Если я правильно понял, то если, скажем, при сложении возникал сбой сумматора, то результирующий код суммы позволял это обнаружить и скорректировать! Ж8-О И кроме того, при вылете отдельных разрядов АЛУ комп продолжал фунциклировать, и всего-навсего, при этом понижалась точность расчетов (других применений у них тогда не было, так что это было как раз то, что нужно... другое дело сейчас пропадали бы отдельные буквы в набираемом документе :-).

Для подробностей курить соотв. монографию Акушского и Юдицкого.

--

SVK

А зачем её (память) доставлять ??? А ЗИП тогда для чего сушествует ? А убытки при искажении информации IMHO больше чем от простоя сервера ! :) Это для Web сервера со статическими страничками решение ... в общем то .. под задачи для F***BSD подходит :) а про Sparc ... им далеко до zSeries от IBM и Linux'а на нём :)

даааа.... чувствую здесь знатоки собрались.........

> а про Sparc ... им далеко до zSeries от IBM и Linux'а на нём :)

Расскажи, как там обстоят дела, plz.

>просто они трахаться с CBOSS'ом на новой платформе не хотят.

дык они-ж на FORIS весь из себя виндовый переходят :)

CBOSS фактически труп...

>А ЗИП тогда для чего сушествует ?
ЗИП говоришь ? :) Все в сервере, памяти мало не бывает :)

>Вот когда Билайн с МТС переведут свой биллинг
Муа-ха-ха :)))

Кому надо для Linux: http://rick.vanrein.org/linux/badram/ http://sourceforge.net/projects/badmem/

>дык они-ж на FORIS весь из себя виндовый переходят :)

>CBOSS фактически труп...

тьфу, блин... это вообще!.. кем надо быть, чтоб фтопку кинуть HPшные серваки на MIPSах ради венды!?

>тьфу, блин... это вообще!.. кем надо быть, чтоб фтопку кинуть HPшные >серваки на MIPSах ради венды!?
Как кем ? Манагером ясен пень. Это вам повезло что вы к этому отношения не имеете.

У нас тоже (сот.компания)все на солярисах и спарках - очень надежно!

CBOSS фактически труп... Это точно. CBOSS - барахло!

Если не ошибаюсь есть специальная ветка Linux ядра где разрабатывалась возможность замены памяти на лету. т.е. не останавливая машину.

>Demimurych (*) (18.04.2005 11:36:16):Если не ошибаюсь есть специальная ветка Linux ядра где разрабатывалась возможность замены памяти на лету. т.е. не останавливая машину.

Ага, всю и сразу ;).

>У нас тоже (сот.компания)все на солярисах и спарках - очень надежно!

Считаете чем, если не секрет?

>а про Sparc ... им далеко до zSeries от IBM и Linux'а на нём :)

Е-мое, вот пиздуны красноглазые! 1) SPARC намного дешевле zSeries, и работает быстрее. 2) на zSeries ни один нормальный человек слюникс гонять не будет. Там есть нормальные z/OS и z/VM. Вот в виртуальной машине VM - может быть, но не более того