Обсуждение участника:Guzenkov (KQvr';yuny rcgvmuntg&Guzenkov)

Reiser4

Здравствуйте. На ВП:СО возник вопрос, касающийся одной Вашей старой правки. Я не смог сходу найти ответ. Похоже, что где-то необходимо уточнить определение. --fcxSanya 20:21, 14 марта 2010 (UTC) Спасибо. Я пересмотрел правку и вспомнил, что писал под впечатлением многостраничного описания с namesys.com, который увы сейчас не доступен. Согласно http://lwn.net/Articles/14035/ reiser4 является журналирумой фс, хотя журналирование осузествляется нетрадиционно. Вот цитаты из приведенной выше ссылки:

Reiser4 promises a high-performance journaling filesystem with highly efficient handling of small files and a plugin architecture which encourages experiments with interesting new semantics.

"Wandering logfiles" take some techniques from log-structured filesystems to provide journaling without (always) writing data to the disk twice. In many cases, Reiser4 can write "journal" data to a disk block, then atomically swap the journal block into the file itself. The journaling code can overwrite or replace blocks, depending on which technique would provide better layout on the disk.

Я написал письмо Эдуарду Шишкину, который собственно является главным разработчиком системы. Вот его ответ:

Привет, Сергей.

Хороший вопрос. И да, и нет :) Это вопрос терминологии.

Reiser4 - файловая система с менеджером транзакций, который
следит за сохранением целостности файловой системы. Менеджер
транзакций позволяет не восстанавливать эту целостность каждый
раз при помощи fsck, когда происходит сбой в работе операционной
системы.

Журналирование (logging) - это название простейшей модели
менеджера транзакций. Это когда на блочном устройстве из разряда
хранения "persistent storage" выделяется фиксированная служебная
облать - "журнал". И все записи на диск проходят через этот журнал,
т.е. всё пишется порциями (логами, транзакциями) в два приема:
сначала в журнал, затем та же порция записывается на диск.
Эти порции составляются с тем требованием, чтобы запись каждой
порции на диск не нарушала целостности файловой системы.
Ну а если произошел сбой, то при монтировании поврежденной
файловой системы действуем в зависимости от обстановки. Если
сбой произошел в момент записи в журнал - то ничего не делаем:
недописанная транзакция просто игнорируется. Если сбой
произошел во время записи на диск, то мы, подстрахованные
журналом, находим в нем и дописываем прерванную транзакцию.
Файловые системы, имеющие такую модель менеджера транзакций
(журналирование) - это reiserfs, ext3, jfs, xfs.

Журналирование имеет существенный недостаток - двойные
записи снижают производительность. Поэтому также существует
альтернативная модель менеджера транзакций COW (copy on write).
В такой модели журнала нет, запись на диск осуществляется
всего один раз, но при этом всегда на новое место. Обновление
указателей на новые данные завершает "транзакцию". Такая модель
обладает "памятью". Освобождение старых блоков происходит в
зависимости от размера "памяти", который можно задавать.
Преимущества этой модели - возможность создания "снимков"
(snapshots), глубокой интеграции файловой системы с RAID-
менеджерами, высокая производительность (в отличие от модели
с журналом пишем всего один раз). Недостатки - большая
фрагментация из-за того, что всегда пишем на новое место.
Файловые системы с моделью COW - это WAFL, ZFS, Btrfs.

Модель менеджера транзакций Reiser4 использует комбинацию
обоих этих подходов (logging и COW). Атомарность - это усиленное
требование к "порциям записи" (в Reiser4 они называются атомы).
Кроме сохранения целостности файловой системы на техническом
уровне, они еще гарантируют и целостность файловой системы для
приложений (файловая система может исправно работать с точки
зрения драйвера, но приложение может обнаружить разрушение
данных. Подробнее в http://lwn.net/2001/1108/a/reiser4-transaction.php3 )

Итак, атомы в Reiser4 распадаются на две части: одна должна быть
перезаписана с помощью журнала (OVERWRITE SET) другая пишется
на новое место с обновлением указателей (RELOCATE SET).
Принцип деления на такие части следующий: если блок атома имеет
"грязного" родителя в дереве, то отправляйся в RELOCATE SET, иначе -
в OVERWRITE SET.

Вот и гадай после этого, reiser4 - это journalling file system, или нет :)

В Namesys долго думали над тем, какую модель использовать. Причем,
это не только, что касается менеджера транзакций. Выход был найден -
плагинная архитектура. Если сильно приспичит, то можно добавить
другой менеджер не переписывая при этом файловую систему заново.

— Эта реплика добавлена участником Guzenkov (о • в) 02:17, 19 марта 2010 (UTC)

Так может просто уберём строчку "Reiser4 не применяет журналирование, все операции в ней атомарны." из статьи Файловая система, чтобы не вводить никого в заблуждение? В этой статье нужна общая классификация, а технические детали пусть будут в более специализированных статьях (ReiserFS и Reiser4). --fcxSanya 07:04, 21 марта 2010 (UTC)

Сделано --Guzenkov 10:32, 23 марта 2010 (UTC)

Хорошо, спасибо за сотрудничество :) --fcxSanya 16:40, 23 марта 2010 (UTC)