Подробности о файловой системе Reiser4 для Linux

Рзработчик Reiser4 Эдуард Шишкин ответил на вопросы пользователей этой широко популярной в узких кругах файловой системы.

Какова сейчас ситуация с Reiser4?

Продвижение Reiser4 в ядро Linux имеет сейчас низкий приоритет. Просто, потом нужно будет мгновенно реагировать на все изменения в VFS/block layer. А у меня не всегда есть такая возможность. В -mm ветке же никто от меня этого не требует. Если что-то ломается, Эндрю Мортон просто шлёт уведомление. А я, когда нахожу время, исправляю.

По поводу популярных прогнозов, что «Reiser4 в ядро не включат и она умрёт», хочу сказать, что не понимаю навязчивую идею «путёвки в жизнь», якобы даваемой включением проекта в основную ветку ядра Linux. Reiser4 — это результат 18-летних исследований в области хранения данных, не привязанный к конкретной операционной системе. Результат, над которым работало много ученых. Не включат в Linuxе — включат в другой ОС, где наши идеи покажутся интересными. На Linuxе свет клином не сошёлся…

Стоит ли сейчас рекламировать Reiser4?

Лучшая рекламная кампания — это объяснить людям, как она работает. Ибо все смотрят на её код, и никто ничего не понимает. Вот вам и Open Source. Каким образом это объяснять? Только статьями, публикуемыми в авторитетных изданиях. И уж, конечно, ни о какой Википедии не может быть и речи. Википедия хороша для освещения творчества художников эпохи Ренессанса. А страница вашего проекта здесь рискует превратиться в отхожее место для компетиторов.

Со своей стороны я собираюсь опубликовать пару статей. Первая будет собственно про модульную архитектуру, вторая будет целиком посвящена модулю «dancing tree» (единственному пока имеющемуся плагину интерфейса «TREE»). Это будет очень интересно: техника, применяемая в этом модуле является одной из самых изощрённых. Далее неплохо было бы объяснить, как работает менеджер транзакций и остальные плагины, но при желании это можно понять и из кода (чего не скажешь о дереве).

Что лично ты думаешь о BFS и BFQ планировщиках?

Если честно, я давно уже не слежу за планировщиками: на своём ноутбуке кроме текстового редактора и браузера мало что запускаю. Только помню, что появлению BFS предшествовала довольно неприятная история (кстати, характерная для модели разработки ядра Linux). А элеваторами Ханс раньше очень интересовался, постоянно поручал реализовывать разные свои идеи. Я лет десять назад тоже модифицировал какой-то элеватор по его заданию. Правда, лучше он от этого работать не стал. Может быть, потому, что меня не интересовали элеваторы…

Почему сырая и ненадёжная файловая система Ext4 была практически сразу принята в ядро?

Ну, же это логическое продолжение de facto стандартной файловой системы Linux Ext3. Было бы удивительно, если бы им тут был красный свет.

Большое количество файловых систем в Linux — это не опасно?

Разумеется, не это оправдано. В большой степени такому зоопарку способствует устаревшая концепция VFS, которая рассматривает файловую систему как непрозрачный монолитный модуль. Раньше просто не было такого количества ФС. А сейчас разве что только ленивый не поймёт, что многие из них делают то же самое. Давно пора извлечь какие-то выводы. У меня есть ряд предложений по улучшению ситуации (всё будет в статье).

Стоит ли разрабатывать Reiser4, ведь есть множество других файловых систем для Linux?

Одной сильной мотивации нет. Сначала хотелось, наконец, доделать прозрачную компрессию. Потом после её анонса в 2007 году возился с Reiser4 из-за нечего делать: долго не мог найти работу. Сейчас продолжаю интересоваться некоторыми аспектами той науки хранения данных, на которой основана Reiser4. Остальные локальные ФС мне не интересны.

Продолжаешь ли ты общаться с уголовником Гансом Рейзером?

Ганс в тюрьме полностью отошел от computer science, хотя и пытается оказывать посильную помощь, но для полноценного участия нужен компьютер, который ему иметь не положено. А так как Ханс не может сидеть без дела, то он обложился книжками и принялся за своё старое увлечение — физику. Вот, нашел какие-то нестыковки в специальной теории относительности, просит найти российского ученого, который бы отрецензировал его новую статью. Клянёт Америку, «страну адвокатов, где науку ни во что не ставят». О России вспоминает с теплотой. С интересом следит за инициативами министра Андрея Фурсенко, который по его мнению пытается возродить былой престиж советской науки и образования. Верит, что в его проекте найдется место и иностранцам, и говорит, что вообще готов перебраться в Россию и выучить, наконец, русский язык.

Как разработчик ReiserFS/ Reiser4 Ганс Рейзер убил свою жену из России

Много ли еще человек разрабатывают Reiser4?

Пока что я один. Все прежние разработчики ушли на заработки, а новых нет. Погрузиться в эту область непросто. Это целыми днями надо сидеть и корпеть за монитором. В цветущие годы обычно не до этого. Ну а когда человеку уже за тридцать, он хочет стабильной работы и денег. Где я ему их достану?

Появится ли Reiser4 на FreeBSD?

Вообще, портирование как таковое мне никогда не было интересно. Но я слышал, что FreeBSD — это операционная система, которая имеет академические корни (University of California, Berkeley). А это означает, что с большой долей вероятности мы найдём с разработчиками общий язык. Во всяком случае, там не будут при слове «алгоритм» смотреть на тебя с непониманием. В Linuxе же ключевым понятием является понятие патча. И существует комитет из определённых людей, которые решают (основываясь вероятно на собственной интуиции, а также в большой степени на умении автора патча «ладить» с командой разработчиков ядра), примут они этот патч в ядро, или нет. Мне такой подход не очень по душе: я закончил мехмат МГУ, а не МГИМО.

Насколько стабильна система Reiser4?

Общий комментарий: за последние четыре года я не помню, чтобы кто-то терял данные на Reiser4 разделе при исправно работающем железе. Ко мне обращалось несколько человек с жалобой на работу fsck. В конечном итоге все они получали и свои данные и работающий fsck.

Самое неприятное — это то, что может возникнуть необходимость отката на предыдущую версию ядра после апгрейда (я не очень хорошо тестирую патчи для очередной версии). Следующая неприятность — отсутствие утилиты дефрагментации. Также до сих пор живёт старый трудновоспроизводимый баг, приводящий к сообщениям о «key inconsistency». В любом случае, если вы решили связаться с Reiser4, то непременно нужно запастись терпением. Если возникли проблемы, то надо послать багрепорт в лист рассылки, или же прямо мне (если не владеете английским языком). При этом не надо думать, что я мгновенно их решу: на Reiser4 у меня есть время только после работы и выходные. Если я перестал отвечать на письма — не надо стесняться напомнить о себе еще раз. Ну а жаловаться на форумах — самый неэффективный способ решения проблем.

Планируется ли создать утилиту для дефрагментации Reiser4?

Да, планируется. Иметь такую утилиту важно. Менеджер транзакций Reiser4 использует смесь техник журналирования и copy-on-write. Последняя сама по себе уже означает фрагментацию. Для того, чтобы от неё избавиться, одиночного копирования может быть недостаточно: ведь свободное дисковое пространство тоже может быть фрагментировано. В общем случае утилита дефрагментации будет существенно улучшать ситуацию за несколько проходов дерева. С внешней фрагментацией можно бороться — это не есть приговор для ФС.

По поводу торрентов. Года три назад в Linuxе появился системный вызов fallocate(2), который призван предотвращать фрагментацию в подобных случаях. Приложение должно заранее указать смещение и размер куска в файле, а файловая система должна выделить под этот кусок (как можно менее фрагментированное) место на диске. Однако, Reiser4 пока этот системный вызов не поддерживает. Сделать такую поддержку несложно, но в ближайшее время мне, скорее всего, будет не до этого.

Возможен ли в будущем вынос плагинов Reiser4 в userspace?

Вынос отдельных плагинов в userspace лишен особого смысла. Как они будут между собой взаимодействовать? Каждый плагин выполняет какой-либо сервис и, в свою очередь, просит другие плагины о каком-либо сервисе. Представьте, что плагину X, работающему в составе ядра понадобился какой-либо оперативный сервис, а предоставляющий его плагин Y работает в userspace. Ничего ведь хорошего при этом не получится? Динамическая загрузка плагинов как модулей ядра полезна, однако это не есть интересный и животрепещущий вопрос. Ну, давайте сделаем их динамически загружаемыми…

Мнение о BTRFS?

Мне поручили исследовать btrfs на предмет её применимости в энтерпрайз-системах, ну я и нашёл сильную внутреннюю фрагментацию на тех моделях, где остальные ФС работают безупречно. Соответственно начал выяснять, ошибка это, или «фича». Правда, прошло уже пол-года а я до сих пор ничего вразумительного про алгоритмы btrfs так и не услышал. Какое тут может сложиться мнение? Понял только, что они хотят фичу «tail packing» файловой системы reiserfs, совершенно не понимая, как работают алгоритмы и структуры данных последней. Скажу только, что в B-деревьях понятие «tail packing» начисто лишено какого-либо смысла. И, более того, попытка размещать в таких деревьях айтемы переменного размера ведёт к неограниченной внутренней фрагментации. А Reiserfs не использует B-деревья и их общеизвестные модификации. Там применяются совсем другие алгоритмы (изобретение российских ученых, между прочим) — с них в начале 90-х началась история Namesys. И модифицировать их для балансировки «сверху вниз», как того требует дизайн btrfs, — задача не совсем тривиальная в отличии от классических B-деревьев.

Очень часто слышу о том, что маинтейнер btrfs Крис Мейсон, поработав в своё время в Namesys, как Дункан Маклауд позаимствовал оттуда весь позитивный опыт наработок. Я же пока что вижу только обратное. На ключах он почему-то сэкономил (ключ в btrfs — 136 бит, в Reiser4 — 192 бита), но терабайты дискового пространства (и оперативной памяти) пользователей неудачной балнсировкой под откос пустил. Дополнительные поля ключа — это возможность по-разному группировать данные и метаданные. И что, это всё не нужно??? А балансировка сверху вниз — так это вообще, по-моему, сплошной компромисс: фазу squeeze балансировки, а также компрессию и шифрование данных отложить наподобие техники «delayed allocation» нельзя. А потом, мне кажется, что эти ребята упрутся в проблемы с масштабируемостью из-за невозможности организовать приличную схему блокировок на таком дереве. Скажу только, что гораздо выгоднее распределить «работу по дереву» между бо́льшим количеством процессов, и пустить часть из них навстречу (снизу вверх), а не так, чтобы все они ломились в это дерево сверху через общий корень.

В общем, не знаю… Я, конечно, помогу, чем смогу, но тут такое дело: если проект основан на неудачных идеях, из него сложно сделать конфетку. К слову, вся история Namesys — это непрерывные контакты с академическими институтами (МГУ, Институт программных систем РАН в Переславле-Залесском). XFS — это тоже целая школа в Silicon Graphics. А Btrfs — это история чего? Пары низкоуровневых воркшопов? А как ещё назвать мероприятия, на которых анонсируются несуществующие фичи? В чудеса я давно перестал верить…

Какими станут файловые системы будущего?

Файловая система — это подсистема, управляющая ресурсом «дисковое пространство». И все её «фичи» должны быть направлены на эффективное управление данным ресурсом. А это значит, что будущее файловых систем за более прогрессивными алгоритмами, т.е. за теми, которые лучше справляются с этой задачей. Однако, появляются новые физические носители, технологии чтения-записи, некоторые перемещаются из userspace в ядро (атомарность, прозрачная компрессия, шифрование и пр.). Существующие файловые системы становятся морально устаревшими: их дешевле переписать заново, чем приспособить к нововведениям. Файловые системы должны уметь «встречать» такие фичи. Не переписывать же их каждый раз заново… А для этого они должны обладать соответствующей технической базой.

Попытка создания такой базы была предпринята в Reiser4: в отличии от своих предшественников она имеет полностью модульную структуру. В Reiser4 все реализации методов file_operations, inode_operations, address_space_operations — это всего лишь тонкие прослойки — диспетчеры, которые решают, какому плагину (модулю) передать дальше управление. А каждый модуль реализует какой-либо абстрактный класс (интерфейс) определённой подсхемы интерфейсов, отражающей некоторую концепцию хранения (мета)данных.

Попытаюсь на пальцах объяснить, как всё это работает. Допустим, вы хотите реализовать функциональность btrfs (снэпшоты и пр.). Как известно, эта ФС использует транзакционнаую модель «copy-on-write», реализованную на базе балансировки дерева «сверху вниз». В этом её основное отличие от того, что в настоящее время предлагает Reiser4. Следовательно, мы должны создать новый плагин «cow» интерфейса «TMGR» (transaction manager), а также новый плагин «multi-root-tree» интерфейса «TREE» для дерева-хранилища, обладающего семейством корней («историей») и балансируемого сверху вниз. При этом последнее нужно снабдить своей схемой блокировок. Что касается TMGR, — это абстрактный класс для управления объектами, которые в следующей статье именуются «particles» (понятие, дуальное примитиву «transcrash», статья находится здесь).

Если присмотреться к менеджерам транзакций разных файловых систем (на настоящий момент существует три типа таких менеджеров), то несложно подметить некоторые их общие черты. А именно, в интерфейсе TMGR можно выделить набор из следующих основных методов:

enter_context();
 
try_capture();
 
exit_context().

Первый и последний вызываются соответственно во время входа и выхода процесса из собственно файловой системы. Второй — во всех местах, где происходит модификация данных (страниц или буферов). Сейчас в Reiser4 работает один-единственный TMGR-плагин, назовём его «jcow» (симбиоз техник «journalling» и «copy-on-write» без сохранения истории), метод ->try_capture() которого добавляет блок в т.н. «атом» (специальное название для «particles» в Reiser4). А в нашем новоиспеченном плагине «cow» этот метод будет отпочковывать новый корень дерева-хранилища (в коде btrfs соответствующая функция зовётся btrfs_cow_block).

В качестве домашнего упражнения предлагаю понять, что именно в этом случае будет «атомами» (т.е. должно отправляться на диск целиком). За ликбезом можно обратиться к статье Охада Родеха «B-trees, shadowning, and clones».

Эти новые корни нужно уметь куда-то складывать и извлекать: если вы хотите фичу «writable snapshots», то они должны образовывать дважды индексированное множество. Но это не проблема. К примеру, в btrfs для этой цели используется отдельное «дерево корней».

Итого, нам нужно всего два новых плагина, чтобы получить функциональность btrfs. И действительно: а зачем нам что-то ещё? Плагины интерфеса FILE выбирают из дерева айтемы в соответствии с методами интерфейса TREE и не должны знать, как балансируется то или иное дерево. Плагины остальных интерфейсов (NODE, ITEM, и пр.) тоже остаются при деле: зачем нам менять формат узлов дерева для организации снэпшотов? Просто, наше «мультикорневое» дерево будет содержать разные внутренние узлы, ссылающиеся на одни и те же блоки.

Я не утверждаю, что программировать новые плагины интерфейсов TREE и TMGR — это работа для ленивых, но, поверьте, это намного проще, чем заново создавать файловую систему и сложнейшую утилиту fsck (которая для Reiser4 тоже, кстати, модульная), ибо самый интересный момент здесь состоит в том, что имеющиеся плагины остальных интерфейсов не нужно учить работать с новыми членами семьи, а это значит, что отпадает необходимость в написании и отладке кода, процентное содержание которого будет стремиться к 100% (при удачной организованной схеме интерфейсов вы успешно реализуете ещё не одну функциональность).

Точно так же, при помощи плагинов, можно организовать и управление логическими томами как в ZFS или btrfs. Однако, тут я должен предостеречь: это уже будет так называемое смешение уровней (layering violation). Дело в том, что в Linux управление томами осуществляется отдельной подсистемой (lvm), и попытка смешать её с файловой системой может окончиться плачевно: вас попросят эту функциональность убрать, и больше так не делать: здесь существует необъяснимая политика двойных стандартов: кому-то смешивать уровни дозволено (к примеру, btrfs), а в Reiser4 это делать не приветствуется. Во всяком случае, вспомнив шквал обвинений в адрес Reiser4 на тему layering violation, я не стал бы рисковать затраченными усилиями.

Подробности и остальные не менее интересные приложения модульной архитектуры можно будет найти в моей статье (пока еще не вышла, будет анонсирована в листе рассылки reiserfs-devel mailing list).

Итак, я бы обрисовал будущее локальных файловых систем в частности как «шлифовку» вот таких вот «внутренних» интерфейсов. На самом деле, если присмотреться, то можно заметить, что никакие они не внутренние. Это как в алгебре: если у вас какое-либо линейное пространство V распадается во (внутреннюю) прямую сумму подпространств, то можно пойти и по обратному пути: построить при помощи конструкции внешней прямой суммы пространство, которое будет изоморфно V. Ну, а раз они не внутренние, то это достояние уже всех файловых систем. Никаких проблем с VFS тут не возникает (подробнее об этом в статье). Вообще, здесь я усматриваю много аналогий между программными системами (в большей степени это относится к системам хранения данных) и такими понятиями гомологической алгебры, как модуль, градуировка, фильтрация, и др. которые мне кажутся очень полезными.

И последнее: про «фичи». Меня часто спрашивают о том, как написать плагин для Reiser4. Причем, ответный вопрос, а что же он у нас будет реализовывать, зачастую ставит вопрошавшего в тупик. Мне не нравится сама идея поставить на поток производство «фич» для файловой системы с модульной архитектурой. Это дисциплина, а не массовая индустрия развлечений. Никто же не ставит на поток доказательства математических теорем…

Я считаю, что сначала должна быть полезная идея из области хранения информации (к примеру, снэпшоты). Не думаю, что таких идей может быть слишком много. С такими идеями — добро пожаловать. Мы подумаем, как выразить её на языке вложений, добавим, если нужно, новые интерфейсы в общую схему и напишем соответствующие плагины.

К сожалению, «фичи» зачастую высасываются из пальца: закон рынка (что потребителя непременно нужно шокировать фичами) не обошел стороной и этот «святой» сектор: за отсутствием каких-либо идей в области хранения данных файловые системы начинают «кипятить океан» и заниматься остальными проплаченными, но совершенно ненужными вещами.

Ваша оценка: Нет Средняя оценка: 2.7 (3 votes)
a

Что за цензура на моем либератуме?! Требую вернуть весь срач все, что тут было обратно!

Ваша оценка: Нет
11
pomodor

Срач некрасивый какой-то получился. Давайте нагадим еще раз, но чтобы было красиво.

Ваша оценка: Нет
9
comrade

@

;-)

Ваша оценка: Нет
a

Не-не, Девид Блейн! Для ведения срача нужно настроение и качественный вброс.
Твой вброс был качественным, у меня, допустим, так не получится.

Ваша оценка: Нет
Отправить комментарий
КАПЧА
Вы человек? Подсказка: зарегистрируйтесь, чтобы этот вопрос больше никогда не возникал. Кстати, анонимные ссылки запрещены.
CAPTCHA на основе изображений
Enter the characters shown in the image.
Linux I класса
Linux II класса
Linux III класса
Счетчики
  • Самый популярный сайт о Linux и Windows 10
О Либератуме

Liberatum — это новости мира дистрибутивов Linux, обзоры, сборки, блоги, а также лучший сайт об Ubuntu*.