|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Oleg Drokin 2:5020/400 05 Feb 2006 22:37:24
To : Aleksey Barabanov
Subject : Re: reizerfs-suxx?//в завершение темы
--------------------------------------------------------------------------------
Hello!
Aleksey Barabanov <abb@wessen.ru> wrote:
>> сканируем журнал, все полные транзакции с номером больше чем последняя
>> закоммиченная - проигрываются.
AB> Т.е. мусор создасться так чтобы совпали и индексы, и номера и маджики врядли
AB> сможет без волшебства.
Hет конечно.
Достаточно чтобы header и commit record остались какие были, а вместо блоков с
данными появился мусор (или остался мусор, потому что сами блоки не успели
записать из-за write cache).
>> AB> Иначе говоря, может ли быть в журнале "полная фигня" так, что ФС не
>> поймет AB> этого и примет за норму. Журнал пишется последовательно? Как
>> проверяется AB> консистентность каждой записи? - Только по данным этой
>> записи. В отличие от
>> Hу считать crc кажного помещенного в журнал блока пока что ни в ext3 ни в
>> reiesrfs не планируется, наверное уж очень сильно cpu жрет. Или
>> еще по каким причинам.
AB> Crc в диске и так есть. Здесь же как вы сами написали commit record зарывает
AB> верные реплики.
Угу. Если диск не обманул нас что он уже записал все блоки и можно писать commit
record.
>> AB> Тут мне кажется, были смешаны темы. Если журналировались операции с
>> данными, AB> а не только метаданные. Т.е. "проблема журнала" в том что
>> метаданные AB> рассинхронизировались с данными это "одна" проблема, а если
>> в том, что в AB> журнале протокола операций с данными оказалась "чушь" -
>> "другая".
>> Э. Так журнал то общий. И хранит он не некий "лог операций", а просто
>> измененные блоки целиком. Это на сегодняшиний момент стандартный подход к
>> журналированию. Как узнать что вот этот конкретный блок - тот что нужно?
AB> А как там может быть что-то иное? Т.е. в журнале записаны пары блоков, а
AB> вместо блоков набор шума? А так может быть?
Потому что нужные блоки не записались - наиболее частая ситуация в наши дни,
сдается мне.
Hу или криво прочитались (DMA заглючило там и тп).
>> Во втором.
>> То есть грубо говоря, мы записали заголовок транзакции и commit record
>> (который записывается когда все блоки для жтой транзакции уже попали в
>> журнал), а вот сами блоки для транзакции записаны не все.
AB> Это будет лишь в том случае, если write cache будет писать не в порядке
AB> поступления. А этого не будет. Так как журнал пишется в большую сплошную
Все IDE диски так делают.
AB> область. И элеватор не будет вешиваться в очередность записи. Иначе говоря,
AB> коммит не попадет на диск вперед самих блоков. Или, вероятность
AB> несоблюдения последнего правила _очень_ мала.
Hет. Все дело в том, что журнал имеет конечный объем. Пусть 32 мегабайта.
И когда он переполняется, новые блоки продолжают писаться с начала,
то есть имеет место переход головки назад. Если изначально головка была ближе
к началу журнала, то запишет последние несколько блоков и commit record,
потом побежит вперед и там запишет header и начальную порцию блоков.
Если питание пропадет после успешной записи header в таком сценарии - то
привет.
Схожая ситуация может возникнуть при апдейте last committed в суперблоке
и записью непосредственно самих данных.
>> AB> Вообще, на сколько адекватно люди оценивают свои возможности
>> управления AB> write cache у диска? А если scsi? А если sata? А если это
>> SAN?
>> Какие-то такие штуки в ядре есть.
AB> Hе факт, что даже те устройства, которые декларируют запрет write cache, не
AB> обманывают на самом деле.
Ясное дело, более того, есть некоторые винты которые именно так и поступают.
WD вроде какие-то, например. В кернеле есть blacklist на эту тему, как я
помню.
>> AB> Т.е. если нет возможности отключить кеш у диска (а ее РЕАЛЬHО нет!),
>> то AB> журналируемая ФС не применима? Т.е. все SAN в помойку?
>> Она применима, но при условии что питание пропасть не может.
>> Либо если кеш "на батарейках" и не может быть потерян.
>> Так же она применима если кешем можно управлять чем-то навроде TCQ.
AB> Так. Давайте определимся. Дело в том что commit пишется вперед блоков с
AB> данными или вообще в кеше? Если первое, то кеш fifo не мешает.
Кто сказал что кеш fifo? Кеш там "что ближе, то и запишу".
Bye,
Oleg
--- ifmail v.2.15dev5.3
* Origin: Green's home news server (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
