 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Aleksey Barabanov 2:5020/400 09 Feb 2006 13:39:58 To : Oleg Drokin Subject : Re: reizerfs-suxx?//в завершение темы -------------------------------------------------------------------------------- Oleg Drokin wrote: > Hello! > > Aleksey Barabanov <abb@wessen.ru> wrote: >>>>> AB> Пример таких операций. И в чем должно проявится. >>>>> Пример - fsstress какой-нибудь (с XFS давали одно время назад). >>>>> Проявляется в inconsistent fs после ребута. >>>>> (Hу то есть fstress ; reset ; fsck = errors found|corrected). >>> AB> Это происходит 100%? >>> Hет, но не менее 50%. > AB> Значит в процессе задействованы факторы, которые не учтены. Иначе было > бы AB> ~100%. > > Hе понял мысли. Если кидать монетку, то с вероятностью не менее 50% выпадет одна из сторон. Вы уверены что на основании такой статистики можно вывести закон о том какая именно из сторон? > AB> Тут маленькая заковыка в логике. > AB> "При заполнении журнала на определенный процент" и говорит о том, что > в AB> процессе интенсивных операций не будет никакого приславутого висения > в кеше AB> 30 сек. > > Откуда это следует-то, я не пойму? > Вот я записал нечто в файл и потом 10 миллионов раз сделал rename. > Почему файловые данные не могут продолжить висеть в кеше все это время? В таком плане согласен. Я имел ввиду задержку цикла кеш-диск. > AB> Доказать мою позицию - легко. > AB> Запускаю систему и просто бросаю ее до la = 0.01 и на минимальной > дисковой AB> нагрузке вырубаю питание - нет проблем! Результативность 99%! > Hу насчет "нет проблем" - кто знает. Если система сразу после загрузки, > кто его знает что за грязных данных оно там накешировало, к примеру. > > AB> Доказать вашу позицию - легко! > AB> Вы указываете совокупность условий приводящих к повреждению журнала > при AB> неожиданном сбросе питания с вероятностью 99%. > > Тут без кернелпатча не обойтись, думается мне. > потому что питание должно пропадать когда мы как раз пересекли границу > журнала и начали заново. Странно, если в момент пересечения границы журнала так просто скинуть кеш, то почему не делается. Странно конечно. Hо пусть будет так. Теперь, как я понимаю, если сброс питания произойдет точно между пересечением границы журнала и до следующего сброса кеша, то возможны проблемы. Они возможны опять же не 100%. Да и время от пересечения границы журнала до сброса кеша тоже составляет лишь долю от времени работы системы. Так сколь велика вероятность получить повреждение в реальности? Кстати, надо еще учесть что рабочие станции, которые обычно без юпса, используются в интерактивном режиме, т.е. их дисковая активность тоже составляет лишь долю от времени работы. Так ли страшен "черт"? > AB> И после этого надо просто сравнить долю моих условий и ваших в > реальной AB> работе сервера с журналируемой ФС. > > А смысл? > Достоверно известно что ситуация воспроизводится. > Поэтому если нет UPS и хочется увеличить надежность - нужно запрещать > write cache или уметь его сбрасывать. Смысл в том, чтобы определить цену этого действия. Можно и монтировать с sync. Ведь не делают? -- Bye. Aleksey Barabanov <alekseybb at mail.ru> Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5.3 * Origin: home (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/78244532ef1d.html, оценка из 5, голосов 10
|
|
|