Из-за того, что Дуард занятой человек, эпическое интервью растянулось на неопределенный срок.
Но, несмотря ни на что, разработчик reiser4 все же нашел время и ответил на вопросы уважаемого Хабра и ЛОР-сообщества.
Что из этого получилось — читайте под катом.
— Как обстоят дела с продвижением reiser4 на ядро? Никаких технических препятствий для этого я больше не вижу: все проблемы из знаменитого «списка для включения» решены.
Осталось только выяснить отношения с ВФС, а соответствующая статья к публикации пока не готова.
В целом, внедрение reiser4 в ядро Linux сейчас является низким приоритетом.
Проще говоря, тогда вам нужно будет мгновенно реагировать на все изменения на уровне VFS/блока.
Но у меня не всегда есть такая возможность.
В ветке -mm от меня этого никто не требует. Если что-то сломается, Эндрю Мортон просто отправит уведомление.
А когда нахожу время, исправляю.
По поводу популярных прогнозов о том, что «reiser4 не включится в ядро и он умрет», хочу сказать, что мне не понятна навязчивая идея «пуска в жизнь», якобы даваемого включением проекта в основную ветку.
ядра Linux. Reiser4 является результатом 18-летних исследований систем хранения данных и не привязан к конкретной операционной системе.
Результат, над которым работали многие учёные.
Если его не включат в Linux, то включат в другую ОС, где наши идеи покажутся интересными.
На линуксе свет клином не сошелся.
— Есть ли смысл проводить что-то вроде рекламной кампании о reiser4, чтобы улучшить его имидж? Лучшая рекламная кампания — объяснить людям, как это работает. Потому что все смотрят на его код и никто ничего не понимает. Вот и все об открытом исходном коде.
Как это можно объяснить? Только статьи, опубликованные в авторитетных изданиях.
И, конечно, ни о какой Википедии не может быть и речи.
Википедия хороша для освещения творчества художников эпохи Возрождения.
И страница вашего проекта здесь рискует превратиться в отхожее место для конкурентов.
Со своей стороны собираюсь опубликовать пару статей.
Первый будет посвящен собственно модульной архитектуре, второй будет целиком посвящен модулю «танцующее дерево» ( единственный доступный на данный момент интерфейсный плагин «TREE» ).
Это будет очень интересно: технология, использованная в этом модуле, одна из самых сложных.
Далее неплохо было бы объяснить, как работает менеджер транзакций и другие плагины, но при желании это можно понять и из кода ( чего нельзя сказать о дереве ).
— Что вы лично думаете о BFS ( планировщик процессора ), БФК ( Планировщик ввода-вывода )? Честно говоря, я давно не слежу за планировщиками: на ноутбуке кроме текстового редактора и браузера почти ничего не запускаю.
Просто помню, что появлению BFS предшествовала довольно неприятная история( кстати, характеристика модели разработки ядра Linux ).
Ганс раньше очень интересовался лифтами и постоянно поручал людям воплощать в жизнь различные его идеи.
Лет десять назад я тоже модифицировал по его инструкциям какой-то лифт. Правда, от этого он не стал лучше работать.
Может быть, потому, что меня не интересовали лифты.
— Как вы думаете, почему более грубая и ненадежная файловая система ext4 почти сразу была принята в ядро? Что ж, это логическое продолжение стандартной файловой системы Linux ext3. Было бы удивительно, если бы здесь был красный свет. — Как вы относитесь к такому огромному количеству ФС в ядре? Оправдано ли это? Конечно, это не оправдано.
Этому зоопарку во многом способствует унаследованная концепция VFS, которая рассматривает файловую систему как непрозрачный монолитный модуль.
Раньше такого количества ФС просто не было.
И сейчас только ленивый не поймет, что многие из них делают то же самое.
Пришло время сделать некоторые выводы.
У меня есть ряд предложений по улучшению ситуации( все будет в статье ).
— На каких выставках и форумах вы собираетесь выступать в этом и следующем году? Меня пока никуда не приглашали.
Сам я инициативу никогда не проявляю.
— Что мотивирует вас развивать reiser4? Ведь есть много других ФС.
Нет сильной мотивации.
Сначала я хотел наконец завершить прозрачное сжатие.
Потом, после его анонса в 2007 году, я возился с Reiser4, потому что делать было нечего: долго не мог найти работу.
Сейчас меня продолжают интересовать некоторые аспекты науки о хранении данных, на которых основан Reiser4. Остальные локальные файловые системы мне не интересны.
— Вы продолжаете неформально, «за кулисами» общаться с Гансом? Принимает ли он какое-либо участие в разработке? По-другому общаться уже невозможно.
Он полностью отошел от информатики, хотя и пытается оказать посильную помощь, но для полноценного участия ему нужен компьютер, которого у него быть не должно.
А так как Ганс не может сидеть без дела, он забросался книгами и занялся своим старым хобби – физикой.
Итак, он обнаружил некоторые несоответствия в специальной теории относительности и просит найти российского учёного, который сделал бы рецензию на его новую статью.
Он проклинает Америку, «страну юристов, где наука вообще не ценится».
Он с теплотой вспоминает Россию.
Он с интересом следит за инициативами министра Андрея Фурсенко, который, по его мнению, пытается возродить былой престиж советской науки и образования.
Он считает, что в его проекте есть место иностранцам, и говорит, что в целом готов переехать в Россию и выучить наконец русский язык.
— Какая ваша основная работа? Я работаю в отделе файловых систем Red Hat. — У вас есть достаточно времени, чтобы сделать reiser4? Условно говоря, этого достаточно, но только для поддержки: я обычно в курсе всех изменений, происходящих в VFS, блочном слое.
Для размещения рейзера4 обычно достаточно выходных.
Разработка означает программирование новых плагинов.
Это предполагает полную занятость, не меньше.
Те.
Это возможно только за зарплату, а платить за это никто пока не собирается.
— Сколько человек занимается поддержкой? Есть ли у вас преемник, если вам вдруг придется прекратить поддержку reiser4? Пока я один.
Все предыдущие разработчики вышли на работу, а новых нет. Нелегко погрузиться в эту область.
Приходится целый день сидеть и корпеть над монитором.
В цветущие годы на это обычно нет времени.
Ну а когда человеку уже за тридцать, ему хочется стабильной работы и денег.
Где я могу получить их для него? — Можно ли лицензировать код reiser4 для использования в проприетарной ОС? Я далек от таких вопросов.
Вы можете спросить Ганса, если вам очень интересно.
— Может ли reiser4 стать файловой системой по умолчанию в одном из следующих выпусков RHEL? Это скорее вопрос к моему руководителю: я не могу обсуждать планы Red Hat. Скажу лишь, что я еще никому ничего не предлагал и меня никто ни о чем не спрашивал.
— Есть ли планы портировать reiser4 на FreeBSD? Возможно, вам стоит подумать о создании порта с помощью FUSE? Что вы думаете о политике принятия изменений в ядре? В общем, портирование как таковое мне никогда не было интересно.
Но я слышал, что FreeBSD — это операционная система, имеющая академические корни ( Калифорнийский университет, Беркли ).
Это значит, что с большой долей вероятности мы найдём общий язык с разработчиками.
В любом случае, когда вы услышите слово «алгоритм», на вас не посмотрят с непониманием.
В Linux ключевой концепцией является концепция патча.
И есть комитет из определённых людей, которые решают( основываясь, вероятно, на собственной интуиции, а также во многом на умении автора патча ладить с командой разработчиков ядра ), примут они этот патч в ядро или нет. Мне такой подход не очень нравится: я закончил МГУ, а не МГИМО.
— С какими подводными камнями может столкнуться в повседневной работе тот, кто хочет попробовать reiser4? Как вы оцениваете его стабильность? Общий комментарий: за последние четыре года я не припомню, чтобы кто-нибудь терял данные на разделе reiser4 при исправном оборудовании.
Ко мне обратилось несколько человек с жалобами на работу fsck. В конечном итоге все они получили свои данные и рабочий fsck. Самое неприятное, что после обновления может потребоваться откат на предыдущую версию ядра( Я не очень хорошо умею тестировать патчи для следующей версии.
).
Следующая неприятность – отсутствие утилиты дефрагментации.
Еще существует старая, трудно воспроизводимая ошибка, вызывающая сообщения о «несогласованности ключей».
В любом случае, если вы решите обратиться в reiser4, вам обязательно придется набраться терпения.
Если у вас возникли проблемы, вам нужно отправить отчет об ошибке в список рассылки или напрямую мне ( если ты не говоришь по-английски ).
При этом не надо думать, что я их решу моментально: на reiser4 у меня есть время только после работы и в выходные.
Если я перестал отвечать на письма, не постесняйтесь лишний раз напомнить мне о себе.
Что ж, жалобы на форумах — это самый неэффективный способ решения проблем.
— Есть ли планы по созданию утилиты дефрагментации? Например, при использовании reiser4 на разделе с торрентами на файл размером 700 МБ приходилось более 11 000 фрагментов, и никакое копирование не могло снизить эту цифру хотя бы до нескольких сотен.
В то же время наблюдались заметные негативные последствия для производительности.
Да, это запланировано.
Наличие такой утилиты важно.
Менеджер транзакций Reiser4 использует сочетание методов журналирования и копирования при записи.
Последнее само по себе уже означает фрагментацию.
Для того чтобы избавиться от него, одной копии может быть недостаточно: ведь свободное место на диске тоже может быть фрагментировано.
В целом утилита дефрагментации существенно улучшит ситуацию за несколько проходов по дереву.
С внешней фрагментацией можно бороться – это не смертный приговор для ФС.
По поводу торрентов.
Около трех лет назад в Linux появился системный вызов Fallocate(2), предназначенный для предотвращения фрагментации в таких случаях.
Приложение должно заранее указать смещение и размер фрагмента в файле, а файловая система должна выделить для этого фрагмента ( как можно меньше фрагментированных ) дисковое пространство.
Однако reiser4 пока не поддерживает этот системный вызов.
Оказать такую поддержку несложно, но в ближайшее время у меня, скорее всего, на это не будет времени.
— Есть ли проблемы с конкретным железом при использовании reiser4? Я не слышал о таких.
Похоже на всеядное существо.
— Будет ли поддержка reiser4 для grub2 реализована самими разработчиками reiser4? Я надеюсь, что так и будет. Это кропотливая работа, но она гарантированно увенчается успехом.
Есть патч для grub-0.97. На его основе можно чудесным образом организовать поддержку reiser4 для grub2. Недостаток существующего патча в том, что загрузка не может пройти этап 1_5 по той причине, что соответствующий бинарник слишком велик и не помещается в отведенные ему 62 сектора.
А невозможность загрузиться через stage1_5 означает, что каждый раз, когда дефрагментатор работает на вашем разделе, вам нужно переустанавливать grub. Поддержка reiser4 для grub2 должна быть сделана хорошо.
Модуль загрузки btrfs с мультиустройств умещается в 62 сектора.
Почему reiser4 туда не влезет? — Возможен ли в будущем перенос плагинов в пользовательское пространство? Есть ли вообще такие планы? Есть ли какие-либо планы по созданию инфраструктуры, которая сможет загружать плагины как в пространство ядра, так и в пространство пользователя? Перемещение отдельных плагинов в пользовательское пространство не имеет особого смысла.
Как они будут взаимодействовать друг с другом? Каждый плагин выполняет какую-то услугу и, в свою очередь, запрашивает какую-то услугу у других плагинов.
Представьте, что плагину X, работающему как часть ядра, нужен некий оперативный сервис, а плагин Y, который его предоставляет, работает в пользовательском пространстве.
Ничего хорошего из этого не выйдет, не так ли? Динамическая загрузка плагинов как модулей ядра полезна, но это не интересная и не актуальная проблема.
Что ж, давайте сделаем их динамически загружаемыми.
— Стоит ли задуматься о написании набора тестов, которые различными способами проверят ФС на прочность и покажут проблемы? Например, это может быть набор Perl-скриптов, которые будут осуществлять агрессивную параллельную запись, чтение и удаление, покажут соответствие считанных данных записанным данным, а также проверят структуру файловой системы на наличие проблемных мест. Пройти такие тесты – мечта многих.
Чтобы через полчаса их запуска можно было уверенно сделать следующий релиз.
Скажу только, что здесь все очень сложно.
Написание комплексных тестов для выявления проблемных мест в программных продуктах — очень сложная задача.
И тестер в основном сосредоточится на регрессе других подсистем ядра.
И либо исправьте их, либо ждите, пока их исправит кто-то другой.
— Как zfs/btrfs повлиял на reiser4? Ни за что.
reiser4 частично находился под влиянием разработки xfs ( метод «отложенного распределения» ).
В основном они использовали собственные разработки.
— Вы принимаете непосредственное участие в разработке btrfs? Частично за счет работодателя.
Я сделал поддержку btrfs в grub-0.97 ( Наши дистрибутивы не работают с grub2 ).
Я не знаю, что еще назначат. Вполне возможно, что это модная функция «дедупликация данных».
— Каково ваше мнение о нынешнем положении дел с btrfs по результатам недавней нашумевшей переписки с Мейсоном? Почему «пресловутый»? Нормальная рабочая обстановка.
Мне поручили исследовать применимость btrfs в корпоративных системах, и я обнаружил сильную внутреннюю фрагментацию в тех моделях, где другие файловые системы работают безупречно.
Соответственно, я начал выяснять, баг это или «фича».
Правда, прошло уже полгода, а я до сих пор ничего вразумительного про алгоритмы btrfs не услышал.
Какое мнение здесь можно составить? Я только понял, что им нужна функция «хвостовой упаковки» файловой системы reiserfs, не до конца понимая, как работают алгоритмы и структуры данных последней.
Скажу лишь, что в B-деревьях понятие «упаковка хвостов» совершенно лишено всякого смысла.
И, более того, попытка разместить в таких деревьях элементы переменного размера приводит к неограниченной внутренней фрагментации.
Рейсерфс не использует B-деревья и их известные модификации.
Они используют совершенно разные алгоритмы ( изобретение русских учёных, кстати ) - с них в начале 90-х началась история Namesys. И модифицировать их для нисходящей балансировки, как того требует конструкция btrfs, — не совсем тривиальная задача, в отличие от классических B-деревьев.
Очень часто слышу, что мейнтейнер btrfs Крис Мейсон, поработав в Namesys, как и Дункан Маклауд, позаимствовал оттуда весь положительный опыт. Пока я вижу только обратное.
Почему-то сэкономил на ключах( ключ в btrfs 136 бит, в reiser4 192 бита ), но терабайты дискового пространства ( и ОЗУ ) пользователи были сорваны из-за неудачной балансировки.
Дополнительные ключевые поля предоставляют возможность по-разному группировать данные и метаданные.
И что, всё это не нужно??? А балансировка сверху вниз — это вообще, на мой взгляд, полный компромисс: фазу сжатия балансировки, а также сжатие и шифрование данных нельзя откладывать, как технику «отложенного распределения».
И потом, мне кажется, у этих ребят возникнут проблемы с масштабируемостью из-за невозможности организовать на таком дереве достойную схему блокировки.
Скажу только, что гораздо выгоднее распределить «деревянные работы» между большим количеством процессов, и пустить в работу часть из них( вниз до ), а не для того, чтобы они все вломились в это дерево сверху через общий корень.
В общем, не знаю.
Я, конечно, помогу, чем смогу, но вот в чем дело: если проект основан на неудачных идеях, сделать из него конфетку сложно.
Кстати, вся история Namesys – это постоянные контакты с академическими учреждениями ( МГУ, Институт программных систем РАН в Переславле-Залесском ).
XFS — это тоже целая школа в Silicon Graphics. А Btrfs — это история чего? Пара низкоуровневых мастер-классов? Как еще можно назвать мероприятия, на которых анонсируются несуществующие функции? Я давно перестал верить в чудеса.
— Каким вы видите будущее ФС? Какой функционал у них будет? Файловая система — это подсистема, которая управляет ресурсом дискового пространства.
И все его «функции» должны быть направлены на эффективное управление этим ресурсом.
Это значит, что будущее файловых систем за более совершенными алгоритмами, т.е.
за теми, кто лучше справляется с этой задачей.
Однако появляются новые физические носители, технологии чтения-записи, некоторые переходят из пользовательского пространства в ядро( атомарность, прозрачное сжатие, шифрование и т. д. ).
Существующие файловые системы устаревают: дешевле переписать их с нуля, чем адаптировать под нововведения.
Файловые системы должны «соответствовать» таким функциям.
Не переписывайте их каждый раз.
А для этого у них должна быть соответствующая техническая база.
Попытка создать такую базу данных была предпринята в reiser4: в отличие от предшественников она имеет полностью модульную структуру.
В reiser4 все реализации методов file_operations, inode_operations,address_space_operations представляют собой лишь тонкие слои — диспетчеры, которые решают, какой плагин( модуль ) передать управление дальше.
И каждый модуль реализует некий абстрактный класс (интерфейс) определенной подсхемы интерфейса, отражающий некоторую концепцию хранения ( мета )данные.
Попробую объяснить на пальцах, как все это работает. Допустим, вы хотите реализовать функциональность btrfs ( снимки и т. д. ).
Как известно, в данной ФС используется транзакционная модель «копирование при записи», реализованная на основе балансировки дерева сверху вниз.
В этом главное отличие от того, что предлагает Reiser4 на данный момент. Поэтому мы должны создать новый плагин «коровьего» интерфейса «TMGR» ( менеджер транзакций ), а также новый плагин «multi-root-tree» интерфейса «TREE» для дерева хранения с семейством корней ( "история" ) и сбалансирован сверху вниз.
При этом последний должен быть оснащен собственной схемой блокировки.
Что касается TMGR, то это абстрактный класс для управления объектами, которые в следующей статье называются «частицами» ( понятие, двойственное примитивному «транскрашу», статья Здесь ).
Если присмотреться к менеджерам транзакций разных файловых систем ( В настоящее время существует три типа таких менеджеров.
), легко заметить некоторые их общие черты.
А именно, в интерфейсе TMGR можно выделить набор следующих основных методов:
- Enter_context();
- попробовать_захват();
- выход_контекст().
Второе — во всех местах, где происходит модификация данных ( страницы или буферы ).
На данный момент в reiser4 работает только один плагин TMGR, назовем его «jcow» ( симбиоз техник «журналирования» и «копирования при записи» без сохранения истории ), метод -> try_capture() который добавляет блок в т.н.
«атом» ( специальное название для «частиц» в reiser4 ).
А в нашем недавно созданном плагине «корова» этот метод создаст новый корень дерева хранения ( в коде btrfs соответствующая функция называется btrfs_cow_block ).
В качестве домашнего упражнения предлагаю разобраться, что именно в данном случае будут «атомами» ( те.
необходимо отправить на диск целиком ).
Для получения образовательной информации вы можете обратиться к статье Охада Родеха «B-деревья, затенение и клоны».
Эти новые корни необходимо иметь возможность где-то добавлять и извлекать: если вам нужна функция «снимков с возможностью записи», тогда они должны образовывать набор с двойным индексированием.
Но это не проблема.
Например, btrfs использует для этой цели отдельное «корневое дерево».
В общей сложности нам нужно всего два новых плагина, чтобы получить функциональность btrfs. И действительно: зачем нам еще что-то? Плагины интерфейса FILE выбирают элементы из дерева в соответствии с методами интерфейса TREE и не требуют знания того, насколько сбалансировано то или иное дерево.
Плагины для других интерфейсов ( УЗЕЛ, ПРЕДМЕТ и т. д. ) тоже остаются в деле: зачем нам менять формат узлов дерева для организации снимков? Проще говоря, наше «многокорневое» дерево будет содержать разные внутренние узлы, ссылающиеся на одни и те же блоки.
Я не говорю, что программирование новых плагинов интерфейса TREE и TMGR — это работа для ленивых, но поверьте, это гораздо проще, чем заново создавать файловую систему и сложнейшую утилиту fsck ( который для reiser4 тоже модульный, кстати ), ведь самое интересное здесь то, что существующие плагины других интерфейсов не нужно учить работать с новыми членами семейства, а значит, нет необходимости писать и отлаживать код, процент которого будет стремиться к 100 % ( при удачно организованной схеме интерфейса вы успешно реализуете не один функционал ).
Точно так же с помощью плагинов можно организовать управление логическими томами как в ZFS или btrfs. Однако тут должен предупредить: это уже будет так называемое смешение уровней( нарушение многослойности ).
Дело в том, что в Linux управление томами осуществляет отдельная подсистема ( лвм ), а попытка смешать его с файловой системой может закончиться катастрофой: вас попросят удалить этот функционал, и больше этого не делать: существует необъяснимая политика двойных стандартов: кому-то разрешено смешивать уровни( например, бтрфс ), а в reiser4 это не поощряется.
В любом случае, помня шквал обвинений в адрес reiser4 на тему многослойного нарушения, я бы не стал рисковать затраченными усилиями.
Подробности и другие не менее интересные применения модульной архитектуры можно найти в моей статье ( еще не выпущен, будет объявлен в списке рассылки reiserfs-devel ).
Итак, я бы охарактеризовал будущее локальных файловых систем именно как «шлифовку» таких «внутренних» интерфейсов.
На самом деле, если присмотреться, то можно заметить, что они вовсе не внутренние.
Это как в алгебре: если у вас есть линейное пространство V, оно разбивается на ( внутренний ) является прямой суммой подпространств, то можно пойти обратным путем: используя конструкцию внешней прямой суммы, построить пространство, которое будет изоморфно V. Ну а раз они не внутренние, то это свойство всех файловые системы.
Никаких проблем с VFS здесь нет( подробнее об этом в статье ).
Вообще здесь я вижу много аналогий между программными системами( это в большей степени относится к системам хранения данных ) и такие понятия гомологической алгебры, как модуль, градуировка, фильтрация и т. д., которые кажутся мне очень полезными.
И последнее: об «особенностях».
Меня часто спрашивают о том, как написать плагин для reiser4. Более того, ответ на вопрос, что он будет у нас реализовывать, часто смущает вопрошающего.
Мне не нравится сама идея ставить на поток производство «фич» для файловой системы с модульной архитектурой.
Это дисциплина, а не индустрия массовых развлечений.
Никто не выдвигает доказательств математических теорем.
Я считаю, что сначала должна быть полезная идея из области хранения информации( например, снимки ).
Я не думаю, что таких идей может быть много.
Такие идеи приветствуются.
Подумаем, как это выразить на языке вложений, добавим при необходимости в общую схему новые интерфейсы и напишем соответствующие плагины.
К сожалению, «особенности» часто берутся из воздуха: закон рынка ( что потребитель непременно должен быть шокирован возможностями ) этот «святой» сектор тоже не остался в стороне: при отсутствии каких-либо идей в области хранения данных файловые системы начинают «кипятить океан» и заниматься другими платными, но совершенно ненужными делами.
Теги: #linux #настройка Linux #Reiser4 #fs #эдвард шишкин
-
Проверка Сложности Пароля В Python
19 Oct, 24 -
Google Хочет Опередить Патентных Троллей
19 Oct, 24 -
Реклама Компьютерной Игры Guitar Hero 5
19 Oct, 24 -
Квинтура Идет В Школу
19 Oct, 24
