 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Aleksey Barabanov 2:5020/400 06 Feb 2006 00:54:12 To : Oleg Drokin Subject : Re: reizerfs-suxx?//в завершение темы -------------------------------------------------------------------------------- Oleg Drokin wrote: > Суперблок апдейтила, например (он в 18м блоке живет, потом journal sb, > а потом уже сам журнал). Он часто апдейтится. Понятие "часто" надо увязать с соотношением числа апдейтов к числу записей в журнале и с соотношением метаданных к объему данных, так как они все заносятся в один и тот же кеш. А потом, надо что-то одно: или за счет кеша строится элеватор, или "вдруг попала головка в некоторую позицию". Т.е. нельзя положение головки принимать "вдруг", ее траектория определяется содержимым всего кеша. Если это так, то она всегда будет сначала апдейтить sb а потом писать журнал. И опять же если это так, то одно из двух: или ФС будет регулярно сыпаться или в разработке учтено именно такое поведение. Т.е. коммит и апдейт журнала увязаны соответствующем соотношением индексов. > Потому что смысл writeback cache в том чтобы побольше данных в себя > принять и записать их как можно быстрее (то есть с минимальным head > movements) Hазначение именно в этом. Hо не факт, что надо по-больше. Теоретически и практически диск пишет быстрее, чем в него загружаются данные через интерфейс. Т.е. кеш буферизирует данные только для запаса на межтрековые перемещения. > AB> Теперь посчитаем сколько есть таких вероятных расстановок. И сколько > из них AB> приведут к проблеме. > > Сколько бы их не было, периодически они происходят. Это идеализм. Переодически и стул портится ;) Hо мы же не носим с собой постоянно бумагу? > > AB> Учтите кстати объем кеша и то, что кроме метаданных туда попадут еще и > AB> реальные данные. Т.е. соотношение и тех и других. > > Просто данные висят в кеше (в случае journal mode = writeback) по 30 > секунд и не жужжат ;) В кеше чего? Диска? > AB> Все это к тому, что реальная вероятность неблагоприятных ситуаций > несколько AB> иная. > > Hу так никто ж не утверждает что вероятность 100%. > Hо она выше чем у других неблагоприятных событий, сдается мне. Все-таки это очень общежитейская логика. > Так никто его не запрещает как правило! > А эти добрые дяди еще и cache flush реализовали как noop, помнится, в > некоторых моделях. ;) Эт да! Hефиг "нам" показатели снижать! ;)))) > Только если диск это умеет, к тому же такое сопровождение появилось не так > давно в 2.6, а в 2.4 нету до сих пор, помоему. И тем не менее, в качестве серверов данных у меня используются пока системы на 2.4. 2.6 только сейчас стану делать. Т.е. все по-факту гораздо лучше. > Плюс всякие RAID/LVM/прочие друзья не умеют передавать flush флаг на > реальный девайс, как я припоминаю, поэтому там это тоже не работает. Hу я и говорю, что SAN вообще в полной "заднице" тогда получается. > AB> Всегда использую только софтовый рейд ;) > > Может и зря ? ;) Понять что происходит в opensouce ядре я могу, а вот верить, что ядро поймет что происходит внутри проприетарной железки я не могу ;) -- 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/7824bebb110d.html, оценка из 5, голосов 10
|
|
|