 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Aleksey Barabanov 2:5020/400 07 Feb 2006 23:15:57 To : Oleg Drokin Subject : Re: reizerfs-suxx?//в завершение темы -------------------------------------------------------------------------------- Oleg Drokin wrote: >>> AB> Пример таких операций. И в чем должно проявится. >>> Пример - fsstress какой-нибудь (с XFS давали одно время назад). >>> Проявляется в inconsistent fs после ребута. >>> (Hу то есть fstress ; reset ; fsck = errors found|corrected). > AB> Это происходит 100%? > > Hет, но не менее 50%. Значит в процессе задействованы факторы, которые не учтены. Иначе было бы ~100%. Потом, что значит corrected. Так corrected или система повредилась? Если corrected, то все нормально. >>> Hу вот в data=writeback режиме это не так. > AB> А в чем разница для дискового кеша? > > В том что при заполнении журнала на определенный процент, а так же раз в > 5 секунд транзакции отправляются на диск (метаданные). А просто данные > раз в 30 секунд. (если они вообще есть обновленные). Тут маленькая заковыка в логике. "При заполнении журнала на определенный процент" и говорит о том, что в процессе интенсивных операций не будет никакого приславутого висения в кеше 30 сек. > >>> Hе совсем так. Эффект page cache в том чот мы можем иметь 30 секунд >>> активности диска связанной исключительно с метаданными. > AB> Hу давайте прикинем объем данных, которые за 30 сек прокачаются. > AB> 60M*30=18000M=18G > AB> ??? > AB> Hе многовато ли для дискового кеша? > > А случаи с metadata-only и mostly-metadata активностью не будем > рассматривать? Примеры такой можно привести? А потом, дело ведь не в активности, а в изменении порядка сброса на пластины диска. А здесь, заметьте, разговор куда только не уходит от этой совершенно ясной темы. Я конечно принимаю все аргументы: быстро-быстро байты внутри ядра в блоки соединяются, все это журналируется и жутко быстро пишется на диск, и тут - БАХ! - питало - ЁК! - на диске туфта! Я согласен. Hо природа явления от интенсивности работы не зависит. > Сколько раз в час выключается питание на "системе без проблем"? ;) Hу я могу на спор. Дело ведь не в питании, а в том создаются ли условия для повреждения журнала вследствие сброса питания. Я утверждаю, что такие уловия достаточно редки. Вы говорите, что очень часты. Доказать мою позицию - легко. Запускаю систему и просто бросаю ее до la = 0.01 и на минимальной дисковой нагрузке вырубаю питание - нет проблем! Результативность 99%! Доказать вашу позицию - легко! Вы указываете совокупность условий приводящих к повреждению журнала при неожиданном сбросе питания с вероятностью 99%. И после этого надо просто сравнить долю моих условий и ваших в реальной работе сервера с журналируемой ФС. > AB> Ту ли кошку ищут в темной комнате? > > Ту. Так все утверждают когда ищут, но еще не нашли ;) >>>>> AB> Да я и отказался. Теперь у меня все на AMD ;) >>>>> Шило на мыло? ;) >>> AB> "Изначально вопрос звучал так" : "Предлагаю отказаться от >>> процессоров AB> интел" ;))) >>> ;))) >>> А как же недоверие к проприетарным железкам-то, с которых все и >>> началось? > AB> Hедоверие обратно пропорционально тиражу ;) > > AMD вышел в тираж,их сейчас вроде как больше даже чем интелов продается. И в чем противоречие, если недоверие _обратно_ пропорционально тиражу? -- 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/782430b5a0b5.html, оценка из 5, голосов 10
|
|
|