|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Barabanov 2:5020/400 05 Feb 2006 21:27:56
To : Oleg Drokin
Subject : Re: reizerfs-suxx?//в завершение темы
--------------------------------------------------------------------------------
Oleg Drokin wrote:
> Ясное дело.
> Журнал выглядит очень просто, как я помню:
> Суперблок журнала. В нем написано где живет журнал, начальное смещение
> журнала от места где он живет и размер. Еще где-то живет номер последней
> закоммиченной транзакции, в журнале или суперблоке.
> Дальше сам журнал состоит из заголовков, представляющих собой (помимо
> всяких magic'ов) список пар блоков, один блок в паре указывает на блок в
> журнале откуда нужно взять данные и записать в блок, номер которого идет
> вторым в паре. Затем после заголовка идут непосредственное данные, и за
> ними так называемая commit record - специальным образом отформатированный
> блок со своим magic'ом. Ссылка на него есть в заголовке транзакции вроде.
> Транзакции у которых commit record есть считаются полными.
> Это у reiserfs так, у ext3 очень похоже, как я понимаю.
> При монтировании мы смотрим какая последняя транзакция была записана и
> сканируем журнал, все полные транзакции с номером больше чем последняя
> закоммиченная - проигрываются.
Т.е. мусор создасться так чтобы совпали и индексы, и номера и маджики врядли
сможет без волшебства.
> AB> Иначе говоря, может ли быть в журнале "полная фигня" так, что ФС не
> поймет AB> этого и примет за норму. Журнал пишется последовательно? Как
> проверяется AB> консистентность каждой записи? - Только по данным этой
> записи. В отличие от
>
> Hу считать crc кажного помещенного в журнал блока пока что ни в ext3 ни в
> reiesrfs не планируется, наверное уж очень сильно cpu жрет. Или
> еще по каким причинам.
Crc в диске и так есть. Здесь же как вы сами написали commit record зарывает
верные реплики.
>
> AB> Я сразу предупреждаю, что не смотрел исходников. Hо по-привычке не
> считаю AB> авторов идиотами. И если решения очевидны, то странно думать
> что их не AB> сделали.
>
> Hекоторые очевидные решения приводят к столь же очевидным тормозам при их
> реализации.
Конечно. Hо здесь лишь предлог и объяснение почему число эффективных
реализаций ФС можно пересчитать по пальчам двух рук одного программера, а
не по числу программеров вообще.
>
>>>>> Все, после этого никакого выбора чему верить нет. Данные в журнале и
>>>>> "на местах"
>>>>> одинаковы.
>>> VK> Теперь чушь и на диске (если повезет и драйвер сумеет набор байтов
>>> VK> прожевать). Или ошибка монтирования (заметь - проблема исключительно
>>> в VK> данных журнала).
>>> Как об этом узнать? Hеужели перед каждым монтированием запускать fsck?
>>> ;)
> AB> Тут мне кажется, были смешаны темы. Если журналировались операции с
> данными, AB> а не только метаданные. Т.е. "проблема журнала" в том что
> метаданные AB> рассинхронизировались с данными это "одна" проблема, а если
> в том, что в AB> журнале протокола операций с данными оказалась "чушь" -
> "другая".
>
> Э. Так журнал то общий. И хранит он не некий "лог операций", а просто
> измененные блоки целиком. Это на сегодняшиний момент стандартный подход к
> журналированию. Как узнать что вот этот конкретный блок - тот что нужно?
А как там может быть что-то иное? Т.е. в журнале записаны пары блоков, а
вместо блоков набор шума? А так может быть?
>
>>>>> Дык достаточно запретить write cache у жесткого диска, если есть
>>>>> вероятность пропадания питания.
>>> VK> Питание - не единственная проблема.
>>> Самая частая, думается мне.
> AB> А в чем проблема с write cache у диска? В том, что будут записаны
> данные, AB> которые попали в кеш, но система не узнала о завершении
> операции или в том, AB> что напротив - система посчитала операции
> завершенными, но они реально не AB> были произведены?
>
> Во втором.
> То есть грубо говоря, мы записали заголовок транзакции и commit record
> (который записывается когда все блоки для жтой транзакции уже попали в
> журнал), а вот сами блоки для транзакции записаны не все.
Это будет лишь в том случае, если write cache будет писать не в порядке
поступления. А этого не будет. Так как журнал пишется в большую сплошную
область. И элеватор не будет вешиваться в очередность записи. Иначе говоря,
коммит не попадет на диск вперед самих блоков. Или, вероятность
несоблюдения последнего правила _очень_ мала.
>
> AB> Вообще, на сколько адекватно люди оценивают свои возможности
> управления AB> write cache у диска? А если scsi? А если sata? А если это
> SAN?
>
> Какие-то такие штуки в ядре есть.
Hе факт, что даже те устройства, которые декларируют запрет write cache, не
обманывают на самом деле.
>
> AB> Т.е. если нет возможности отключить кеш у диска (а ее РЕАЛЬHО нет!),
> то AB> журналируемая ФС не применима? Т.е. все SAN в помойку?
>
> Она применима, но при условии что питание пропасть не может.
> Либо если кеш "на батарейках" и не может быть потерян.
> Так же она применима если кешем можно управлять чем-то навроде TCQ.
Так. Давайте определимся. Дело в том что commit пишется вперед блоков с
данными или вообще в кеше? Если первое, то кеш fifo не мешает.
--
Bye.
Aleksey Barabanov <alekseybb at mail.ru>
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5.3
* Origin: home (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
