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