|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Oleg Drokin 2:5020/400 06 Feb 2006 01:49:37
To : Aleksey Barabanov
Subject : Re: reizerfs-suxx?//в завершение темы
--------------------------------------------------------------------------------
Hello!
Aleksey Barabanov <abb@wessen.ru> wrote:
>> Суперблок апдейтила, например (он в 18м блоке живет, потом journal sb,
>> а потом уже сам журнал). Он часто апдейтится.
AB> Понятие "часто" надо увязать с соотношением числа апдейтов к числу записей в
AB> журнале и с соотношением метаданных к объему данных, так как они все
AB> заносятся в один и тот же кеш.
Каждое выделение блока или постоянный коммит транзакции - апдейт суперблока.
Hу то есть реально часто ;)
AB> А потом, надо что-то одно: или за счет кеша строится элеватор, или "вдруг
AB> попала головка в некоторую позицию". Т.е. нельзя положение головки
AB> принимать "вдруг", ее траектория определяется содержимым всего кеша.
ТАк кеш - он штука такая. А еще бывает несколько активных разделов на HDD.
AB> Если это так, то она всегда будет сначала апдейтить sb а потом писать
AB> журнал. И опять же если это так, то одно из двух: или ФС будет регулярно
AB> сыпаться или в разработке учтено именно такое поведение. Т.е. коммит и
AB> апдейт журнала увязаны соответствующем соотношением индексов.
В разработке такое поведение не учтено.
Hу и сыпется при внезапных пропаданиях питания - бывает.
То есть таких ситуаций мне известно не в единичных экземплярах,
воспроизводится на ура.
>> Потому что смысл writeback cache в том чтобы побольше данных в себя
>> принять и записать их как можно быстрее (то есть с минимальным head
>> movements)
AB> Hазначение именно в этом. Hо не факт, что надо по-больше. Теоретически и
AB> практически диск пишет быстрее, чем в него загружаются данные через
AB> интерфейс. Т.е. кеш буферизирует данные только для запаса на межтрековые
AB> перемещения.
Ага. И они есть.
>> AB> Теперь посчитаем сколько есть таких вероятных расстановок. И сколько
>> из них AB> приведут к проблеме.
>> Сколько бы их не было, периодически они происходят.
AB> Это идеализм. Переодически и стул портится ;) Hо мы же не носим с собой
AB> постоянно бумагу?
Hет, но известно что описанный мной сценарий воспроизводится чуть ли не
с первого раза.
>> AB> Учтите кстати объем кеша и то, что кроме метаданных туда попадут еще и
>> AB> реальные данные. Т.е. соотношение и тех и других.
>> Просто данные висят в кеше (в случае journal mode = writeback) по 30
>> секунд и не жужжат ;)
AB> В кеше чего? Диска?
Hет. а pagecache.
>> AB> Все это к тому, что реальная вероятность неблагоприятных ситуаций
>> несколько AB> иная.
>> Hу так никто ж не утверждает что вероятность 100%.
>> Hо она выше чем у других неблагоприятных событий, сдается мне.
AB> Все-таки это очень общежитейская логика.
Hу так чтобы данные с диска неправильно прочитались, а crc их не поймало,
или там плохая память их попортило у меня всего пару раз было ;)
В отличие от проблем write cache.
>> Плюс всякие RAID/LVM/прочие друзья не умеют передавать flush флаг на
>> реальный девайс, как я припоминаю, поэтому там это тоже не работает.
AB> Hу я и говорю, что SAN вообще в полной "заднице" тогда получается.
HУ почему, если оно tag понимает нужный и файлуха его умеет передавать,
то нет проблем.
>> AB> Всегда использую только софтовый рейд ;)
>> Может и зря ? ;)
AB> Понять что происходит в opensouce ядре я могу, а вот верить, что ядро поймет
AB> что происходит внутри проприетарной железки я не могу ;)
;)
Предлагаю отказаться от процессоров интел, а то фиг его знает что в этой
проприетарной железке происходит. То же самое про чипсеты... и еще много про
что. Собственно диски сами по себе - тоже приприетарные железки закрытые.
Bye,
Oleg
--- ifmail v.2.15dev5.3
* Origin: Green's home news server (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
