|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Ilya Anfimov 2:5020/400 07 Dec 2001 22:44:18
To : Aleksey Barabanov
Subject : Re: Re[2]: ReiserFS
--------------------------------------------------------------------------------
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> мусором, если глянуть на содержимое.
>Я думаю при таком раскладе резко упадет производительность.
>Собственно данные на запись так и так буферизируются. Именно эта отложенная
>синхронизация и является причиной сбоев из-за неожиданного креша. В
>рейзере проблема преодолена за счет журналирования, но только для
>метаданных. Т.е. креш не приводит к одновременному и зачастую фатальному
>повреждению всей структуры fs. Hо требование обязательной синхронизации данных
>равносильно отказу от буферизации вывода. Если же журналировать не
>только метаданные но и сами информационные блоки, то, как это видно по
>ext3, производительность падает. Зачем развивать фичу которая всяко по
>дефолту будет отключена ?
Блин. Лучше бы ты математике все-таки учился, а не с бобинами
бегал. Потому что дело тут явно не в бобине.
Основной плюс в математике даже не тот, что ты научшься брать
какие-нибудь поверхностные интегралы или решать дифуры. Хотя дело
тоже полезное. Особенно знать, что вот такие дифуры решаются,
такие решаются скорее численно, а эти вообще являются некорректно
поставленной задачей и их решение -- мартышкин труд.
Hо на это можно и какого-нибудь специалиста-решателя дифуров
где-нибудь одолжить.
А плюс в том, что логически рассуждать учит и понимать
логические рассуждения. Простой, непосредственной тренировкой по
три-шесть раз в неделю, пару-тройку лет. Очень, знаешь ли,
помогает.
Так вот, в журналируемых fs нет требования обязательной,
синхроннной с поступлением, записи даже метаданных. Теоретически
Они могут лежать в кеше часами, никого не возмущая.
Все, что требуется -- это _целостность_ метаданных. Для этого
план операций с ними пишется в некоторый достаточно линейный лог
(журнал) до самих по себе операций. И над метаданными проводятся
операции только после гарантированной записи журнала на диск.
Таким образом, любую операцию над (реальными, не в журнале)
метаданными, которая уже начата, можно будет завершить даже после
reset. Журнал же этот по своей структуре и благодаря небольшим
усилиям разработчиков трудно исковеркать до неузнаваемости -- в
процессе работы с ним просто нет состояния, когда было бы
непонятно, что делать дальше и что вообще происходит. И важна в
журналировании не одномоментность записи в журнал или
непосредственно в структуры fs, а запись в журнал _до_ начала
записи в рабочие структуры с метаданными.
Теперь следи за руками: достаточно записать реальные данные
какого-то файла на свое будущее место на диск _до_ начала
транзакции с метаданными, и файл будет содержать некоторые вполне
реальные данные независимо от того, что произойдет при этой
транзакции -- закончится она, не начнется, закончится при
восстановлении после resetа.
При некоторых усилиях со стороны разработчиков файл в любом
случае будет в каком-то состоянии, в котором он был в некоторый
момент работы приложения. Hа что прилично написанные системы
должны рассчитывать -- действительно, мало ли. И
восстанавливаться в таких случаях, прикидывая заранее свой conЅ
trol flow, последовательность состояний своего файла на диске и
что можно потом с этим делать. И reset мог приключиться и
SIGKILL неожданно прийти.
Подробно останавливаться на схемах восстановления после таких
приколов я уже не буду, скажу только, что сами журналируемые fs
-- это пример такой работы, и приведу один близкий всем пример --
большинство текстовых редакторов при перезаписи или делают backЅ
upы исходных файлов или создают сначала новый файл как-нибудь
отдельно, а потом одним ln() вставляют его на место старого. В
таком случае (при нормальном control flow) на диске всегда лежит
хотя бы старая копия файла, и обычно неполный файл можно сразу
отличить по неполному размеру.
Так вот в единственно возможном поведении reiser такого условия
нет. В лежашем на диске файле может оказаться любой мусор,
например вчерашняя копия shadow. Во всяком случае этот мусор
будет совсем непохож на то, что там должно быть. Что бывает
просто фатально в случае бинарных файлов у приложения.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
