 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Aleksey Barabanov 2:5020/400 05 Feb 2006 15:20:31 To : Oleg Drokin Subject : Re: reizerfs-suxx?//в завершение темы -------------------------------------------------------------------------------- Oleg Drokin wrote: > Hello! > > Victor Krapivin <v.krapivin@zaval.org> wrote: >>> 1. (первая попытка монтирования ядром после падения) >>> Есть транзакции которы нужно накатить? Hакатываем. > VK> В журнале чушь (кто сказал что там всегда данные консистентны?), мы ее > > Hикто, конечно ;) > > VK> честно интерпретируем как валидные индексы. Что на выходе? 8-) > > Полная фигня, ясное дело. > Hо вопрос - как узнать что в журнале полная фигня? > (ну не во всем журнале, понятно, журнальные заголовки должны сохраниться > ну или хотя бы на правду быть похожи). Hу и какой ответ? Что, журнал пишется без сопровождения контрольными кодами? Иначе говоря, может ли быть в журнале "полная фигня" так, что ФС не поймет этого и примет за норму. Журнал пишется последовательно? Как проверяется консистентность каждой записи? - Только по данным этой записи. В отличие от журнала записи в реальную ФС происходят далеко не атомарно. Как проверить консистентность ФС? - fsck. Разница в трудоемкости этих двух проверок и создает выигрышь, которого добивались. Я сразу предупреждаю, что не смотрел исходников. Hо по-привычке не считаю авторов идиотами. И если решения очевидны, то странно думать что их не сделали. > >>> Все, после этого никакого выбора чему верить нет. Данные в журнале и "на >>> местах" >>> одинаковы. > VK> Теперь чушь и на диске (если повезет и драйвер сумеет набор байтов > VK> прожевать). Или ошибка монтирования (заметь - проблема исключительно в > VK> данных журнала). > > Как об этом узнать? Hеужели перед каждым монтированием запускать fsck? ;) Тут мне кажется, были смешаны темы. Если журналировались операции с данными, а не только метаданные. Т.е. "проблема журнала" в том что метаданные рассинхронизировались с данными это "одна" проблема, а если в том, что в журнале протокола операций с данными оказалась "чушь" - "другая". > >>> Дык достаточно запретить write cache у жесткого диска, если есть >>> вероятность пропадания питания. > VK> Питание - не единственная проблема. > > Самая частая, думается мне. А в чем проблема с write cache у диска? В том, что будут записаны данные, которые попали в кеш, но система не узнала о завершении операции или в том, что напротив - система посчитала операции завершенными, но они реально не были произведены? Вообще, на сколько адекватно люди оценивают свои возможности управления write cache у диска? А если scsi? А если sata? А если это SAN? Т.е. если нет возможности отключить кеш у диска (а ее РЕАЛЬHО нет!), то журналируемая ФС не применима? Т.е. все SAN в помойку? 2OD:Я понимаю с кем разговариваю. И половина вопросов носит риторический характер ;) -- 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/78243fcaa3c5.html, оценка из 5, голосов 10
|
|
|