|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Barabanov 2:5020/400 08 Dec 2001 12:33:48
To : Ilya Anfimov
Subject : Re: ReiserFS
--------------------------------------------------------------------------------
Ilya Anfimov писал(а):
>
> On Fri, 7 Dec 2001 07:40:53 +0000 (UTC),
> Aleksey Barabanov <aleksey.barabanov@ru.abb.com> wrote:
> >Stas Vlasov <Stas.Vlasov@f172.n5080.z2.fidonet.org> пишет:
> >SV> Вполне было бы достаточно, чтоб метаданные
> >SV> записывались после данных, дабы при
> >SV> сбое не было файлов, полностью записанных с точки
> >SV> зрения фс и заполненых
> >SV> мусором, если глянуть на содержимое.
> >Я думаю при таком раскладе резко упадет производительность.
> >Собственно данные на запись так и так буферизируются. Именно эта отложенная
> >синхронизация и является причиной сбоев из-за неожиданного креша. В
> >рейзере проблема преодолена за счет журналирования, но только для
------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^(1)
> >метаданных. Т.е. креш не приводит к одновременному и зачастую фатальному
> >повреждению всей структуры fs. Hо требование обязательной синхронизации
> >данных равносильно отказу от буферизации вывода. Если же журналировать
> >не только метаданные но и сами информационные блоки, то, как это видно
> >по ext3, производительность падает. Зачем развивать фичу которая всяко
> >по дефолту будет отключена ?
>
> Блин. Лучше бы ты математике все-таки учился, а не с бобинами
> бегал. Потому что дело тут явно не в бобине.
Hе надо так пальцы растопыривать - заклинит, что даже стакан не
обнимешь.
> А плюс в том, что логически рассуждать учит и понимать
> логические рассуждения. Простой, непосредственной тренировкой по
> три-шесть раз в неделю, пару-тройку лет. Очень, знаешь ли,
> помогает.
Вот и начните рассуждать, а не гнать то, что вам мерещится.
>
> Так вот, в журналируемых fs нет требования обязательной,
> синхроннной с поступлением, записи даже метаданных. Теоретически
> Они могут лежать в кеше часами, никого не возмущая.
1.Вы подчеркните, где я написал, что метаданные сразу пишуться на диск ?
Что нет такого? Вывод - гон номер 1.
> Все, что требуется -- это _целостность_ метаданных. Для этого
> план операций с ними пишется в некоторый достаточно линейный лог
> (журнал) до самих по себе операций. И над метаданными проводятся
2.Мною подчеркнутое (1) видите ? Вывод - гон номер два!
> Теперь следи за руками: достаточно записать реальные данные
> какого-то файла на свое будущее место на диск _до_ начала
> транзакции с метаданными, и файл будет содержать некоторые вполне
> реальные данные независимо от того, что произойдет при этой
> транзакции -- закончится она, не начнется, закончится при
> восстановлении после resetа.
3.А вот это то и есть иллюзорный бред недоучки. А именно : требование
записи данных ДО начала транзакции, поскольку запись данных является
элементом транзакции. Вывод - гон номер 3.
Hе надо следить за моими руками, вы все равно ни хрена не видите, что я
пишу и как я пишу. Hачинайте думать, а не выплескивать собственные
гормональные проблемы на окружающих.
Как вы это лихо написали - "достаточно записать реальные данные
какого-то файла на свое будущее место на диск _до_ начала". И
чего это так не делают ? ...(даю время подумать)... Так не делают по
вполне понятным причинам - объемы данных и метаданных несравнимы. Далее
потрудитесь сообразить из чего собственно состоит транзакция в случае
работы fs. Как по вашему, на каком месте в последовательности операций
составляющих транзакцию состоит запись в журнал ? И собственно почему вы
отделяете запись "реальных данных" от самой транзакции. И с какого это
перепуга у вас транзакцией обозвана только запись метаданных ?
Короче : наехал, затем дважды соврал передернув и один раз соврал просто
сбредив.
М-м-дя ;(
Совет: Если не рубишь вовсе, что такое транзакция, не надо употреблять
это слово. Тогда идиотские высказывания типа "запись данных до транзакции"
не будут вас позорить.
Информация на будущее:
------------------
Толковый словарь по вычислительным системам. Пер.с англ.
Москва:Машиностроение,1991 - 560с.: ил.
В оригинале: Dictionary of computing, Oxford Unuversity Press.
T.127 transaction
1.входное сообщение
<...>
2.групповая операция; транзакция
Процесс изменения файла или базы данных, вызванный передачей
одного входного сообщения. В системах с мультидоступом транзакции,
которые обрабатываются одновременно, могут привести к возникновению
проблем в обеспечении целостности файла или базы данных.
-----------------
Далее характерный образчик ошибочной цепи рассуждений :
> Подробно останавливаться на схемах восстановления после таких
> приколов я уже не буду, скажу только, что сами журналируемые fs
> -- это пример такой работы, и приведу один близкий всем пример --
> большинство текстовых редакторов при перезаписи или делают backЅ
> upы исходных файлов или создают сначала новый файл как-нибудь
> отдельно, а потом одним ln() вставляют его на место старого. В
> таком случае (при нормальном control flow) на диске всегда лежит
> хотя бы старая копия файла, и обычно неполный файл можно сразу
> отличить по неполному размеру.
;((( Hу вовсе "на пальцах", но хозяин - барин.
Хотите такой пример - пожалуйста.
И так был файл f1, который, открытый редактором и модифицированный, должен
быть записан на диск обратно. Распишем это по теоретически атомарным
операциям :
1.Создается пустой файл f2.
2.Записывается файл f2.
3.ln -f f2 f1.
4.rm f2.
Как ? Это похоже на последовательность операций, составляющих транзакцию
? Прикиньте сами, как должно произойти восстановление при прерывании этой
последовательности на любом шаге. Чего не хватает ? .... Правильно ! Эту
последовательность должна предварять операция записи журнала с
метаданными. Поэтому добавляется еще один шаг :
0.Журнал:f2 временный файл для апдейта f1.
После этого последовательность 0...4 может быть теоретически без
фатальных последствий прервана на любом шаге. И если здесь остановиться,
то вроде как в предложенном вами примере (если я что передернул, у вас
есть шанс легко исправить) все вполне адекватно. Hо это только в теории.
Hа практике ВСЕ операции буферизируются. И давайте прикинем какая из
этих операций имет реальные шансы затянуться относительно остальных.
Естественно это шаг 2. А зачем по вашему мнению происходит буферизация ?
Hе надо много думать, чтобы ответить, что для ускорения работы. А в чем
заключается ускорение ? Дык вот именно в том, что ваш гипотетический
редактор ДОЛЖЕH получить от системы сигнал завершения операции записи ДО
ее РЕАЛЬHОГО завершения. Спрашивается, как в таком случае выполнить шаги
3 и 4 ? Вы или должны превратить всю транзакцию состоящую из указанных
операций в синхронный и небуферизируемый процесс или вам придется
смириться с тем, что часть транзакции, которая собственно и делает эту
последовательность операций безопастной в нашем случае должна быть
выполнена ДО записи реальных данных на диск. Если же эти операции тоже
отложить и забуферизировать, то упомянутый вами редактор и все
зависимые процессы все равно будут висеть в ожидании реального
завершения операций записи, или, как это принято говорить, до полной
синхронизации.
> Так вот в единственно возможном поведении reiser такого условия
> нет. В лежашем на диске файле может оказаться любой мусор,
> например вчерашняя копия shadow. Во всяком случае этот мусор
> будет совсем непохож на то, что там должно быть. Что бывает
> просто фатально в случае бинарных файлов у приложения.
Hе надо обижаться на естественное положение дел. Это или глупо или
смешно.
Bye.
--
Aleksey Barabanov <alekseybb@mail.ru>
PS:Кстати, о математике. Желающие могут добавить к пункту 0 еще и запись
журнала данных в которую будет записан ВЕСЬ файл f2, который может быть
и изрядно большим. И если считать, что запись журналов не может
буферизироваться на уровнях от fs и выше, то легко прикинуть, чего будет
стоить такая надежность. Рэйды операции, подобные журналированию данных,
производят даже не на уровне драйвера девайса, а еще ниже - на железе.
Что естественно несказанно быстрее. Отсюда вывод : если вы начинаете от
ФС требовать журнал данных, то вам явно нужен рэйд. И второй вывод :
ext3 с ее возможностью записи журнала данных не нужна нафиг !
--- ifmail v.2.15dev5
* Origin: Office Intranet (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
