|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Oleg Drokin 2:5020/400 09 Feb 2006 15:49:46
To : Aleksey Barabanov
Subject : Re: reizerfs-suxx?//в завершение темы
--------------------------------------------------------------------------------
Hello!
Aleksey Barabanov <abb@wessen.ru> wrote:
>> AB> Значит в процессе задействованы факторы, которые не учтены. Иначе было
>> бы AB> ~100%.
>> Hе понял мысли.
AB> Если кидать монетку, то с вероятностью не менее 50% выпадет одна из сторон.
AB> Вы уверены что на основании такой статистики можно вывести закон о том
AB> какая именно из сторон?
Hет, но у нас есть факты что каждая из сторон выпадает. Это - то что мы ищем.
>> AB> Доказать вашу позицию - легко!
>> AB> Вы указываете совокупность условий приводящих к повреждению журнала
>> при AB> неожиданном сбросе питания с вероятностью 99%.
>> Тут без кернелпатча не обойтись, думается мне.
>> потому что питание должно пропадать когда мы как раз пересекли границу
>> журнала и начали заново.
AB> Странно, если в момент пересечения границы журнала так просто скинуть кеш,
AB> то почему не делается.
Hе так и просто.
До 2.6 небыло вообще возможности файловой системе сказать "эй, там, не забудьте
сбросить кеш". Hе все storage устройства это поддерживают.
Всякие LVM/softraid & friends вроде бы до сих пор не поддерживают.
Hу и, наконец, понятное дело это приводит к некоторому performance penalty,
видимо поэтому, например reiserfs, по умолчанию барьеры не использует
(кроме версии из SuSE ядер).
AB> Странно конечно. Hо пусть будет так.
AB> Теперь, как я понимаю, если сброс питания произойдет точно между
AB> пересечением границы журнала и до следующего сброса кеша, то возможны
AB> проблемы.
Угу. При этом стоит учитывать что (принудительный) сброс кеша может не
произойти никогда.
AB> Они возможны опять же не 100%. Да и время от пересечения границы журнала до
AB> сброса кеша тоже составляет лишь долю от времени работы системы.
Были такие диски, где при некоторых неблагоприятных условиях "грязные" данные
могли висеть в кеше чуть ли не минутами и часами. Впрочем потом это, вроде,
исправили. (да, еще эти диски страдали тем, что на команду flush cache
просто отвечали "готово" и ничего не делали).
AB> Так сколь велика вероятность получить повреждение в реальности?
Кто знает. Зависит от нагрузки и фазы луны. Hо оно не нулевое.
И те, кому положено, должны это учитывать.
AB> Кстати, надо еще учесть что рабочие станции, которые обычно без юпса,
AB> используются в интерактивном режиме, т.е. их дисковая активность тоже
AB> составляет лишь долю от времени работы.
Hу это само собой.
AB> Так ли страшен "черт"?
Кому как.
Вот мне известны случаи когда у DDN (за несколько сотен килобаксов, как я
понимаю, запрещают write cache, потому что батарейку туда не доложили.
Версия с батарейкой стоит намного дороже (ну там и возможнойстей добавлено
других, понятно).
>> AB> И после этого надо просто сравнить долю моих условий и ваших в
>> реальной AB> работе сервера с журналируемой ФС.
>> А смысл?
>> Достоверно известно что ситуация воспроизводится.
>> Поэтому если нет UPS и хочется увеличить надежность - нужно запрещать
>> write cache или уметь его сбрасывать.
AB> Смысл в том, чтобы определить цену этого действия. Можно и монтировать с
AB> sync. Ведь не делают?
Hу почему, некоторые делают (в *bsd до сих пор sync metadata по дефолту поди?).
Вот только при нынешних дисках которые пишут по дорожке подряд и если ее не
дописали, то уже прочитать назад не могут, это может еще больше навредить.
Особенно если оно как в случае с приснопамятными ibm deskstar - возвращает
i/o error на попытку прочитать такую дорожку.
Bye,
Oleg
--- ifmail v.2.15dev5.3
* Origin: Green's home news server (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
