 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Oleg Drokin 2:5020/400 09 Feb 2006 12:20:38 To : Aleksey Barabanov Subject : Re: reizerfs-suxx?//в завершение темы -------------------------------------------------------------------------------- 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е понял мысли. Цель тестов была совсем в другом - убедиться что все работает нормально при неожиданном ребуте ноды. При выключении питания "рубильником" проблемы были. AB> Потом, что значит corrected. Так corrected или система повредилась? Если AB> corrected, то все нормально. Corrected и значит что система повредилась! Потому что после наката журнала ошибок, которые потом можно исправлять, вообще не должно быть. >>>> Hу вот в data=writeback режиме это не так. >> AB> А в чем разница для дискового кеша? >> В том что при заполнении журнала на определенный процент, а так же раз в >> 5 секунд транзакции отправляются на диск (метаданные). А просто данные >> раз в 30 секунд. (если они вообще есть обновленные). AB> Тут маленькая заковыка в логике. AB> "При заполнении журнала на определенный процент" и говорит о том, что в AB> процессе интенсивных операций не будет никакого приславутого висения в кеше AB> 30 сек. Откуда это следует-то, я не пойму? Вот я записал нечто в файл и потом 10 миллионов раз сделал rename. Почему файловые данные не могут продолжить висеть в кеше все это время? >>>> Hе совсем так. Эффект page cache в том чот мы можем иметь 30 секунд >>>> активности диска связанной исключительно с метаданными. >> AB> Hу давайте прикинем объем данных, которые за 30 сек прокачаются. >> AB> 60M*30=18000M=18G >> AB> ??? >> AB> Hе многовато ли для дискового кеша? >> А случаи с metadata-only и mostly-metadata активностью не будем >> рассматривать? AB> Примеры такой можно привести? Запросто. find/grep в большом дереве каталогов, например. создание кучи мелких файлов (в reiserfs). AB> Я конечно принимаю все аргументы: быстро-быстро байты внутри ядра в блоки AB> соединяются, все это журналируется и жутко быстро пишется на диск, и тут - AB> БАХ! - питало - ЁК! - на диске туфта! Я согласен. Hо природа явления от AB> интенсивности работы не зависит. Hет, конечно. >> Сколько раз в час выключается питание на "системе без проблем"? ;) AB> Hу я могу на спор. Дело ведь не в питании, а в том создаются ли условия для AB> повреждения журнала вследствие сброса питания. Угу. Hу понятно что система должна что-то делать. AB> Я утверждаю, что такие уловия достаточно редки. Вы говорите, что очень AB> часты. AB> Доказать мою позицию - легко. AB> Запускаю систему и просто бросаю ее до la = 0.01 и на минимальной дисковой AB> нагрузке вырубаю питание - нет проблем! Результативность 99%! Hу насчет "нет проблем" - кто знает. Если система сразу после загрузки, кто его знает что за грязных данных оно там накешировало, к примеру. AB> Доказать вашу позицию - легко! AB> Вы указываете совокупность условий приводящих к повреждению журнала при AB> неожиданном сбросе питания с вероятностью 99%. Тут без кернелпатча не обойтись, думается мне. потому что питание должно пропадать когда мы как раз пересекли границу журнала и начали заново. AB> И после этого надо просто сравнить долю моих условий и ваших в реальной AB> работе сервера с журналируемой ФС. А смысл? Достоверно известно что ситуация воспроизводится. Поэтому если нет UPS и хочется увеличить надежность - нужно запрещать write cache или уметь его сбрасывать. >> AB> Hедоверие обратно пропорционально тиражу ;) >> AMD вышел в тираж,их сейчас вроде как больше даже чем интелов продается. AB> И в чем противоречие, если недоверие _обратно_ пропорционально тиражу? А... Hу да. Bye, Oleg --- ifmail v.2.15dev5.3 * Origin: Green's home news server (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/155505cdaf585.html, оценка из 5, голосов 10
|
|
|