Недавно со мной связался Эдуард Шишкин и попросил опубликовать интервью (что я с радостью и делаю) в формате вопрос-ответ.

С первым интервью (2010-го года) можно ознакомиться здесь.

— Для начала напомни, пожалуйста, читателям, где и кем ты работаешь.

Я работаю в должности Principal Storage Architect в компании Huawei Technologies, German Research Center. В отделе виртуализации занимаюсь разными аспектами хранения данных. Моя деятельность не связана с конкретной операционной системой.

— Коммитишь ли ты сейчас в основную ветку ядра?

Очень редко, и только если это требует мой работодатель. Последний раз года три назад я посылал патчи, позволяющие повысить пропускную способность для хранилищ, расшаренных на хостах по протоколу 9p (другое название этого дела - VirtFS). Здесь надо сделать одно важное замечание: хоть я и давно работаю рядом с Линукс, его фанатом я никогда не являлся, то есть, "дышу ровно", как впрочем и ко всему остальному. В частности, если я заметил какой-то изъян, то могу указать на него максимум один раз. А так, чтобы потом за кем-то ходить и уговаривать - такого не будет.

— Помнится, в прошлый раз, десять лет назад, ты довольно критически отзывался о стиле разработки ядра. Поменялось ли с твоей (или, возможно, корпоративной) точки зрения что-либо, сообщество стало более отзывчивым или нет? Если нет, кто, по-твоему, в этом виноват?

Я так и не увидел каких-либо сдвигов в лучшую сторону. Основная проблема сообщества - это подмена науки политтехнологиями, персональными отношениями, мнением большинства, популизмом, советами "внутренних голосов", гнилыми компромиссами, всем чем угодно кроме науки. Computer science, как ни крути, прежде всего точная наука. И если кто-то начинает провозглашать для 2x2 своё значение, отличное от 4, под флагом "Linux way", либо под каким другим, то кроме вреда это вряд ли что принесёт. Все беды прежде всего от некомпетентности и необразованности тех, кто принимает решения. Если руководитель некомпетентен, он не способен принять объективное адекватное решение. Если он к тому же и бескультурный, он не способен найти компетентного специалиста, который даст ему правильный совет. С большой вероятностью выбор падёт на мошенника, говорящего "с виду правильные вещи". Вокруг некомпетентных лидеров-одиночек всегда складывается коррумпированное окружение. Причём, история не знает исключений на этот счёт, и сообщество - ярчайшее тому подтверждение.

— Как ты оцениваешь прогресс в разработке Btrfs? Эта ФС избавилась от детских болезней? Как ты её для себя позиционируешь — как ФС «для дома» или и для корпоративного применения тоже?

Не избавилась. Всё то, о чём я упоминал 11 лет назад, актуально и поныне. Одна из проблем Btrfs, делающая последнюю непригодной для серьёзных нужд, - это проблема свободного места. Я уж не говорю о том, что пользователю предлагается бежать в магазин за новым диском в ситуациях, когда любая другая ФС показала бы ещё уйму свободного места на разделе. Невозможность завершить операцию над логическим томом по причине нехватки свободного места - это тоже не самое страшное. Хуже всего то, что непривилегированный пользователь почти всегда может за достаточно короткое время в обход любых дисковых квот лишить всех свободного места. Выглядит это так (проверено для ядра Linux 5.12). На свежеинсталлированной системе запускается скрипт, который в цикле создаёт в домашней директории файлы с определенными именами, записывает в них данные по определенным смещениям и затем удаляет эти файлы. Через минуту работы этого скрипта ничего необычного не происходит. Через пять минут порция занятого места на разделе слегка увеличивается. Через два-три часа она достигает 50% (при начальном значении 15%). А после пяти-шести часов работы скрипт валится с ошибкой "нет свободного места на разделе". После этого вы уже не в состоянии записать на ваш раздел даже 4К файл. Происходит интересная ситуация: вы ничего на раздел в итоге не записали, а всё свободное место (порядка 85%) куда-то улетучилось. Анализ раздела, подвергнутого такой атаке, покажет множество узлов дерева, содержащих всего один айтем (объект, снабженный ключом), размером несколько байт. То есть, контент, который ранее занимал 15% дискового пространства оказался равномерно "размазанным" на весь раздел так, что новый файл записать уже некуда, ибо его ключ больше всех существующих, а свободные блоки на разделе закончились. Причем это всё происходит уже на базовой конфигурации Btrfs (безо всяких снапшотов, сабвольюмов и пр.), и не имеет значения то, как вы решили хранить тела файлов в той ФС (как "фрагменты" в дереве, или же как экстенты неформатированных блоков) - конечный результат будет один и тот же.

Подвергнуть такой атаке остальные файловые системы из апстрима вам не удастся (что бы вам там ни говорили). Причину проблемы я уже давно объяснил: это полное извращение в Btrfs понятия B-дерева, что делает возможным его спонтанное или намеренное вырождение. В частности, при некоторых нагрузках ваша ФС в процессе эксплуатации будет непрерывно "разваливаться" и сама, без посторонней помощи. Понятно, что всевозможные "поджимающие" фоновые процессы спасут дело только на индивидуальных десктопах. На коллективных же серверах злоумышленник всегда будет в состоянии их "опередить". Системный администратор даже не сможет определить, кто именно над ним издевался. Быстрее всего исправить эту проблему в Btrfs можно лишь восстановив структуру регулярного B-дерева, т.е. заново перепроектировав дисковый формат и переписав существенную часть кода Btrfs. Это займёт 8-10 лет вместе с отладкой при условии что разработчики чётко следовали оригинальным статьям по соответствующим алгоритмам и структурам данным, а не играли в "испорченный телефон", как это принято (и поощряется) в "Linux way". Сюда ещё надо прибавить время, необходимое разработчикам на то, чтобы понять всё это. Вот тут уже сложнее. Во всяком случае, 10 лет на понимание им не хватило. Ну, а до этого можете не уповать на чудо. Оно не произойдёт в виде опции монтирования "про которую мы с вами не знали", или в виде патча, который приготовить "всего-то делов". Для каждого такого скоропалительного "исправления" я предъявлю новый сценарий вырождения. B-деревья - это одна из моих излюбленных тем, и должен сказать, что вольности в обращении с собой эти структуры не терпят!

Как я для себя позиционирую Btrfs? Как нечто, что именоваться файловой системой категорически не может, не говоря уже об использовании. Ибо по определению ФС - это подсистема ОС, ответственная за эффективное управление ресурсом "дисковое пространство", чего в случае c Btrfs мы не наблюдаем. Ну, представьте, что вы пришли в магазин купить часы, чтобы не опаздывать на работу, а там вместо часов вам впарили электрогриль с таймером на 30 минут максимум. Так вот - с Btrfs ситуация ещё хуже.

Просматривая листы рассылок, я часто сталкиваюсь с утверждением, что эффективно управлять дисковым пространством уже не актуально по причине дешевизны накопителей. Это полнейший бред. Без эффективного менеджера дискового пространства ОС станет уязвимой и непригодной к использованию. Вне зависимости от того, какой ёмкости диски стоят на вашей машине.

— Хотелось бы попросить прокомментировать прекращение поддержки Btrfs в RHEL.

Тут особо нечего комментировать, всё предельно ясно. Она же была у них "technology preview". Вот, и не прошла это самое "preview". Не висеть же вечно этому ярлыку! А запустить ущербный by-design продукт с полной поддержкой они не могут. RHEL - это энтерпрайз, то есть прописанные товарно-денежные отношения. Red Hat не может издеваться над пользователями, как это происходит в листе рассылки Btrfs. Просто представьте ситуацию: клиент, заплативший свои кровные за диск и ещё вам за поддержку, хочет понять, куда делось его дисковое пространство, после того, как он ничего не записал. Что вы ему на это ответите? Далее. В число клиентов Red Hat входят известные крупные банки, биржи. Представьте, что будет, если они подвергнутся DoS-атакам, основанным на упомянутой уязвимости в Btrfs. Как вы думаете, кто за это ответит? Тем, кто собрался ткнуть пальцем в строчку лицензии GPL, где написано, что автор ни за что не отвечает, сразу скажу: "спрячьте её подальше!" Ответит Red Hat, причём так, что мало не покажется! Но я знаю, что Red Hat-у такого рода проблемы не грозят, учитывая их особенно сильную команду QA-инженеров, с которыми мне довелось плотно поработать в своё время.

— Почему некоторые компании продолжают поддерживать Btrfs в своих энтерпрайз-продуктах?

Заметьте, что приставка "энтерпрайз" в названии продукта мало о чём говорит. Энтерпрайз - это мера ответственности, заложенная в договорные отношения с клиентом. Я знаю только один энтерпрайз, основанный на GNU/Linux - это RHEL. Всё остальное, с моей точки зрения, лишь выдаётся за энтерпрайз, но таковым не является. И, наконец, если на что-либо есть спрос, то всегда будет и предложение (в нашем случае это упомянутая "поддержка"). Спрос же бывает абсолютно на всё, в т.ч. и на непригодный к использованию софт. Как он формируется такой спрос, и кто его подпитывает - это уже другая тема.

Так что, я бы не стал делать какие-то выводы после того, как Facebook по слухам развернул Btrfs на своих серверах. Более того, адреса тех серверов я бы порекомендовал тщательно хранить в тайне по вышеупомянутым причинам.

— Почему в последнее время очень много усилий приложено к вылизыванию кода XFS? Ведь изначально это — сторонняя ФС, да и ext4 давно стабильна и имеет преемственность от предыдущих таких же стабильных версий. Какой интерес у Red Hat'а к XFS? Есть ли смысл активно разрабатывать две похожие по предназначению ФС — ext4 и XFS?

Уже не помню, чем это мотивировалось. Вполне возможно, что инициатива шла от клиентов Red Hat. Я помню, что проводились исследования такого рода: на некоторых файловых системах из апстрима создавалось гигантское количество объектов на хай-енд накопителях нового поколения. По результатам XFS повела себя лучше ext4. Вот её и стали продвигать как наиболее перспективную. В любом случае, я бы не искал тут чего-то сенсационного. По мне, так сменили шило на мыло. Разрабатывать ext4 и XFS нет смысла. Как параллельно, так и любую из них на выбор. Из этого ничего хорошего не получится. Хотя, в природе часто встречаются ситуации, когда потенций для роста много, а объёма куда расти нет. В этом случае возникают разные причудливо-уродливые новообразования, на которые все показывают пальцем ("О, смотри, чего только в этой жизни не увидишь!").

— Считаешь ли ты вопрос о layer violation исчерпанным (в негативном смысле) с появлением функций шифрования в ext4, F2FS (не говоря уже о RAID в Btrfs)?

Вообще, введение каких-либо уровней и принятие решения о их ненарушении - это обычно вопрос политики, и я не берусь тут что-либо комментировать. Объективные же аспекты нарушения уровней мало кому интересны, но мы можем рассмотреть некоторые из них на примере нарушения "сверху", а именно, реализацию в ФС функциональности, уже имеющейся на block layer. Такое "нарушение" оправдано всего лишь за редким исключением. Для каждого такого случая вы сначала должны доказать две вещи: что это действительно нужно, и что дизайну системы при этом не будет причинён ущерб. Скажем, зеркалирование, которое традиционно являлось занятием для block layer, имеет смысл реализовать на уровне файловой системы. По разным причинам. Например, на дисковых накопителях имеет место "тихая" порча данных (bit rot). Это когда устройство исправно работает, но данные блока неожиданно повреждаются под воздействием жесткого гамма-кванта, испущенного далёким квазаром и т.п. Хуже всего, если этим блоком оказался системный блок ФС (суперблок, bitmap-блок, узел дерева-хранилища и т.д), ибо это непременно приведёт к kernel panic. Заметьте, что зеркала, предлагаемые block layer (т.н. RAID 1) от этой проблемы не спасут. Ну, действительно: кто-то же должен проверять контрольные суммы и считывать реплику в случае неудачи? Кроме того, имеет смысл зеркалировать не тупо все подряд, а только метаданные. Некоторые важные данные (к примеру, исполняемые файлы критических приложений) можно хранить на правах мета-данных. В этом случае они получают такие же гарантии сохранности. Защиту же остальных данных имеет смысл поручить другим подсистемам (возможно, даже пользовательским приложениям) - мы предоставили для этого все необходимые условия. Такие "экономные" зеркала вполне имеют право на существование и эффективно их организовать можно только на уровне файловой системы. В остальном же layering violation - это захламление подсистемы дублированным кодом ради каких-то микроскопических выгод. Яркий тому пример - это реализация RAID-5 средствами ФС. Такие решения (собственные RAID / LVM в файловой системе) убивает последнюю в архитектурном плане. Здесь ещё нужно отметить, что layering violation "поставлено на поток" разного рода маркетинговыми мошенниками. За отсутствием каких-либо идей, в подсистемы добавляется функциональность давно уже реализованная на соседних уровнях, это выдается за новую черезвычайно полезную фичу и активно проталкивается.

Reiser4 же обвинили в нарушении уровней "снизу". Исходя из того, что файловая система не монолитная, как все остальные, а модульная, было сделано ничем не обоснованное предположение, что она занимается тем, чем должен заниматься уровень выше (VFS).

— Можно ли говорить о смерти ReiserFS v3.6 и, например, JFS? Последнее время им в ядре почти не уделяется внимания. Они морально устарели?

Здесь надо определить, что значит смерть программного продукта. С одной стороны, они с успехом используются (их для этого и создавали, в конце концов) - значит живут. С другой стороны, не скажу за JFS (мало знаю), а вот ReiserFS (v3) очень трудно приспособить к новым тенденциям (проверено на практике). Значит, разработчики в дальнейшем будут уделять внимание не ей, а тем, которые легче приспособить. С этой стороны получается, что, увы, мертва в архитектурном плане. Понятием "морально устаревший" я бы вообще не манипулировал. Оно хорошо применимо, например, к гардеробу, но никак не к программным продуктам. Есть понятие уступать и превосходить в чем-либо. Совершенно точно могу сказать, что ReserFS v3 сейчас во всём уступает Reiser4, но на некоторых типах рабочей нагрузки превосходит все остальные ФС из апстрима.

— Известно ли тебе о разработке ФС Tux3 и HAMMER/HAMMER2 (ФС для DragonFly BSD)?

Да, известно. В Tux3 меня когда-то заинтересовала технология их снимков (т.н. "версионные указатели"), но в Reiser4 мы, скорее всего, пойдём другим путём. Я давно думаю о поддержке снимков (snapshots) и ещё не определился с тем, как их реализовать для простых Reiser4 томов. Дело в том, что новомодная техника "ленивых" счётчиков ссылок, предложенная Охадом Родехом, работает лишь для B-деревьев. У нас их нет. Для тех структур данных, которые используются в Reiser4, "ленивые" счётчики не определены - для их введения необходимо решить определённые алгоритмические проблемы, за что пока никто не брался.

По HAMMERу: читал статью от создателя. Не заинтересовало. Опять же, B-деревья. Эта структура данных безнадёжно устарела. Мы отказались от неё ещё в прошлом веке.

— Как ты оцениваешь нарастающую востребованность в сетевых кластерных ФС по типу CephFS/GlusterFS/etc? Означает ли эта востребованность сдвиг приоритетов разработчиков в сторону сетевых ФС и недостаточность внимания к локальным ФС?

Да, такой сдвиг приоритетов произошел. Разработка локальных ФС стагнировала. Увы, сделать что-то существенное для локальных томов сейчас довольно сложно и далеко не всем под силу. Вкладываться в их разработку никто не хочет. Это примерно так же, как попросить коммерческую структуру выделить деньги на математические исследования - вас без энтузиазма спросят, а как на новой теореме можно будет заработать. Теперь локальная ФС - это нечто, что магически появляется "из коробки" и "всегда должно работать", а если не работает, то вызывает безадресное ворчание навроде: "да, что они там себе думают!". Отсюда недостаток внимания к локальным ФС, хотя работы в той области ещё невпроворот. И да, все повернулись к распределённым хранилищам, которые строятся на базе уже существующих локальных ФС. Это сейчас очень модно. Словосочетание "Big Data" у многих вызывает выброс адреналина, ассоциируясь с конференциями, воркшопами, большими зарплатами и т.п.

— Насколько разумным в принципе выглядит подход, при котором сетевая ФС реализуется в пространстве ядра, а не в пространстве пользователя?

Очень разумный подход, который до сих пор нигде не был реализован. Вообще, вопрос о том, в каком пространстве надо реализовывать сетевую ФС - это "палка о двух концах". Ну, давайте рассмотрим на примере. Клиент записал данные на удалённой машине. Они упали в её page cache в виде грязных страниц. Это работа для "тонкого шлюза" сетевой ФС в пространстве ядра. Дальше операционная система рано или поздно попросит записать те страницы на диск для их освобождения. Тогда в дело включается IO-forwarding (отправляющий) модуть сетевой ФС. Он определяет на какую серверную машину (server node) эти страницы попадут. Потом эстафету принимает сетевой стек (а он, как мы знаем, реализован в пространстве ядра). Далее, server node принимает тот пакет с данными или метаданными и даёт указание backend storage - модулю (т.е. локальной ФС, которая работает в пространстве ядра) записать всё это хозяйство. Итак, мы свели вопрос к тому, где должны работать "отправляющий" и "принимающий" модули. Если какой-либо из тех модулей работают в пространстве пользователя, то это неминуемо приведёт к переключению контекстов (из-за необходимости пользования сервисами ядра). Число таких переключений зависит от деталей реализации. Если таких переключений много, то будет падать пропускная способность хранилища (производительность ввода-вывода). Если ваш backend storage составлен из медленных дисков, то значительного падения вы не заметите. Но если у вас диски быстрые (SSD, NVRAM и т.д), то переключение контекстов уже становится "бутылочным горлышком" и, сэкономив на переключении контекстов, производительность можно увеличить в разы. Стандартный путь такой экономии заключается в переносе модулей в пространство ядра. К примеру, мы выяснили, что перенос 9p-сервера из QEMU в ядро на хост-машине приводит к трёхкратному приросту производительности VirtFS. Это, конечно, не сетевая ФС, но суть вещей вполне отражает. Обратная сторона такой оптимизации - это проблемы с переносимостью. Для кого-то последняя может оказаться критичной. К примеру, GlusterFS вообще не имеет модулей в составе ядра. Благодаря этому она сейчас работает на многих платформах, в том числе и на NetBSD.

— Какие концепции локальные ФС могли бы позаимствовать у сетевых и наоборот?

Сейчас сетевые ФС, как правило, есть надстройки над локальными ФС, поэтому я не совсем понимаю, как можно у последних что-то позаимствовать. Ну, действительно, рассмотрим компанию из 4 сотрудников, в которой каждый занимается своим делом: один распределяет, другой отправляет, третий получает, четвертый хранит. И вопрос, а что же компания может позаимствовать от её сотрудника, который хранит, звучит как-то некорректно (то, что можно было от него позаимствовать она уже давно имеет).

А вот локальным ФС есть чему поучиться у сетевых. Во-первых, у них стоит поучиться агрегировать логические тома на высоком уровне. Сейчас т.н. "передовые" локальные ФС агрегируют логические тома исключительно при помощи технологии "виртуальных девайсов", заимствованной из LVM (тот самый заразный layering violation, который сначала был реализован в ZFS). Иначе говоря, происходит трансляция виртуальных адресов (номеров блоков) в реальные и обратно на низком уровне (т.е. после того, как файловая система издала запрос ввода-вывода). Заметьте, что добавление и удаление устройств в логические тома (не зеркала), скомпонованные на block layer ведёт к проблемам, о которых поставщики подобных "фич" скромно умалчивают. Я говорю о фрагментации на реальных устройствах, которая может достигать чудовищных значений, в то время, как на виртуальном устройстве у вас всё замечательно. Однако виртуальные устройства мало кого интересуют: всем интересно, что у вас происходит на реальных устройствах. Но ZFS-подобные ФС (также как и любые ФС в связках с LVM) работают только с виртуальными дисковыми устройствами (выделяют виртуальные дисковые адреса из числа свободных, дефрагментируют эти виртуальные устройства и т.д.). А что происходит на реальных устройствах они даже понятия не имеют! Теперь представьте, что на виртуальном устройстве у вас фрагментация равна нулю (то есть, у вас там живёт всего один гигантский экстент), вы добавляете диск в ваш логический том, а затем удаляете другой случайный диск из вашего логического тома с последующей перебалансировкой. И так вот много раз. Нетрудно сообразить, что на виртуальном устройстве у вас по-прежнему будет жить тот самый единственный экстент, но вот на реальных устройствах вы ничего хорошего уже не увидите. Хуже всего то, что вы даже не в состоянии исправить эту ситуацию! Единственное, что тут можно сделать - это попросить файловую систему дефрагментировать виртуальное устройство. Но она вам скажет, что у вас там всё замечательно - есть один только экстент, фрагментация равна нулю, а лучшего и быть не может! Итак, логические тома, скомпонованные на блочном уровне, не предназначены для многократного добавления/удаления устройств. По-хорошему, нужно только один раз скомпоновать логический том на блочном уровне, отдать его файловой системе, и потом ничего уже больше с ним не делать.

Кроме того, связка независимых подсистем ФС+LVM никак не позволяет учитывать разную природу накопителей, из которых агрегируются логические тома. Действительно, предположим, скомпоновали вы логический том из НЖМД и твердотельных устройств. Но тогда первые потребуют дефрагментации, а вторые - нет. Для вторых нужно издавать discard-запросы, а для первых - нет, и т.п. Однако в указанной связке такую избирательность проявить достаточно сложно. Заметьте, что после создания в файловой системе своего собственного LVM, ситуация сильно лучше не становится. Более того, этим вы фактически ставите крест на перспективе когда-либо её улучшить в будущем. Это очень плохо. На одной и той же машине могут жить накопители разного типа. И если не файловая система будет их различать, то кто тогда?

Еще одна проблема подстерегает т.н. "Write-Anywhere" файловые системы (сюда же входит и Reiser4, если во время монтирования вы задали соответствующую транзакционную модель). Такие файловые системы должны предъявить беспрецедентные по своей мощи средства дефрагментации. А низкоуровневый менеджер томов тут не помогает, а только мешает. Дело в том, что с таким менеджером ваша ФС будет хранить карту свободных блоков только одного девайса - виртуального. Соответственно, дефрагментировать вы сможете только виртуальный девайс. Это значит, что дефрагментатор ваш будет долго-долго пахать на огромном едином пространстве виртуальных адресов. И если у вас много пользователей, делающих случайные перезаписи, то полезный эффект от такого дефрагментатора сведётся к нулю. Система ваша неминуемо начнёт тормозить, и вам останется лишь сложить руки перед неутешительным диагнозом "broken design". Несколько дефрагментаторов, работающих на одном и том же пространстве адресов будут только мешать друг другу. Совсем другое дело, если для каждого реального устройства вы поддерживаете свою карту свободных блоков. Это позволит эффективно распараллелить процесс дефрагментации. Но сделать это можно, лишь обладая высокоуровневым менеджером логических томов. Локальных ФС с такими менеджерами ранее не существовало (по крайней мере, я о них не знаю). Такими менеджерами обладали только сетевые ФС (например GlusterFS). Другой очень важный пример - утилита проверки целостности тома (fsck). Если для каждого подтома у вас хранится своя независимая карта свободных блоков, то процедуру проверки логического тома можно эффективно распараллелить. Иначе говоря, логические тома с высокоуровневыми менеджерами лучше масштабируются.

Кроме того, с низкоуровневыми менеджерами томов вы не сможете организовать полноценные снимки (snapshots). С LVM и в ZFS-подобных ФС вы можете делать только локальные снимки, но никак не глобальные. Локальные снимки позволяют моментально откатывать только регулярные файловые операции. A операции с логическими томами (добавление / удаление устройств) вам никто там не откатит. Давайте рассмотрим это на примере. В некоторый момент времени, когда у вас имеется логический том из двух устройств А и В, содержащий 100 файлов, вы делаете снимок S системы и затем создаете ещё одну сотню файлов. После этого вы добавляете к вашему тому устройство С, и наконец откатываете вашу систему к снимку S. Вопрос: сколько файлов и устройств содержит ваш логический том после отката к S? Файлов, как вы уже догадались, будет 100, но вот устройств будет 3 - это те же устройства A, B и C, хотя, на момент создания снимка в системе было всего два устройства (A и B). Операция добавления устройства C не откатилась, и если вы сейчас удалите устройство C из компьютера, то это закорраптит ваши данные, так что перед удалением вам нужно будет сначала провести дорогостоящую операцию удаления устройства из логического тома с перебалансировкой, которая раскидает все данные с устройства C на устройства A и B. А вот если бы ваша ФС поддерживала глобальные снимки, такая перебалансировка бы не потребовалась, и после моментального отката к S вы бы могли смело удалить устройство C из компьютера. Итак, глобальные снимки хороши тем, что они позволяют избежать дорогостоящего удаления (добавления) устройства из логического тома (в логический том) c большим количеством данных (разумеется, если вы не забыли "сфотографировать" свою систему в нужный момент). Напомню, что создание снимков и откат файловой системы к оным - моментальные операции. Может возникнуть вопрос: а как вообще такое возможно - моментально откатить операцию с логическим томом, которая заняла у вас три дня? А вот возможно! При условии, что ваша ФС правильно спроектирована. Идея таких "3D-снапшотов" у меня возникла три года назад, а в прошлом году я запатентовал эту методику.

Следующее, чему стоит поучиться локальным ФС у сетевых - это хранить метаданные на отдельных устройствах точно так же, как сетевые ФС хранят их на отдельных машинах (так называемые метадата-серверы). Есть приложения, работающие в основном с метаданными, и эти приложения можно значительно ускорить, разместив метаданные на дорогостоящих высокопроизводительных накопителях. Со связкой ФС+LVM проявить такую избирательность вам не удастся: LVM не знает, что там на блоке, который вы ему передали (данные там или же метаданные). От реализации в ФС собственного низкоуровневого LVM большого выигрыша по сравнению со связкой ФС+LVM вы не получите, а вот что у вас получится очень хорошо - так это захламить ФС так, что потом станет невозможно работать с её кодом. ZFS и Btrfs, поспешившие с виртуальными девайсами, - это всё наглядные примеры того, как layering violation убивает систему в архитектурном плане.Итак, к чему я всё это? Да к тому, что не нужно городить в файловой системе свой собственный низкоуровневый LVM. Вместо этого нужно агрегировать устройства в логические тома на высоком уровне, как это делают некоторые сетевые ФС с разными машинами (storage nodes). Правда, делают они это отвратительно по причине применения плохих алгоритмов. Примеры совершенно ужасных алгоритмов - это транслятор DHT в файловой системе GlusterFS и так называемый CRUSH map в файловой системе Ceph. Ни один из тех алгоритмов, что я видел, не устроил меня в плане простоты и хорошей масштабируемости. А потому пришлось вспоминать алгебру и изобретать всё самому. В 2015 году, экспериментируя с расслоениями над хэш-функциями, я придумал и запатентовал то, что меня устраивает. Сейчас могу сказать, что попытка реализовать всё это на практике оказалась успешной. Никаких проблем с масштабируемостью в новом подходе я не вижу. Да, каждый подтом потребует в памяти отдельную структуру типа суперблока. Это что, очень страшно? Вообще, я не знаю, кто собирается "кипятить океан" и создавать логические тома из сотен тысяч и более устройств на одной локальной машине. Если кто-нибудь мне это объяснит, буду очень благодарен. А пока что для меня это маркетинговый булшит.

— Как повлияли изменения в подсистеме блочных устройств ядра (например, появление blk-mq) на требования к реализации ФС?

Никак не повлияли. Уж не знаю, что там должно такого случиться на block layer, что пришлось бы проектировать новую ФС. Интерфейс взаимодействия этих подсистем очень беден. Со стороны драйверов на ФС влиять должно только появление накопителей нового типа, к которым будет подстраиваться сначала block layer, а потом уже ФС (для reiser4 это будет означать появление новых плагинов).

— Означает ли появление новых типов носителей (например, SMR, или повсеместное распространение SSD) принципиально новые вызовы для проектирования ФС?

Да. И это нормальные стимулы для развития ФС. Вызовы могут быть разные и совершенно неожиданные. К примеру, я слышал о накопителях, где скорость операции ввода-вывода сильно зависит от размера куска данных и его смещения. В Линуксе, где размер ФС-блока не может превышать размер страницы, такой накопитель по умолчанию не проявит свои полные возможности. Однако, если ваша ФС правильно спроектирована, то есть шанс много ещё чего из него "выжать".

— Сколько людей сейчас работает с кодом Reiser4 кроме тебя?

Меньше, чем хотелось бы, но и острой нехватки ресурсов я не испытываю. Темпы развития Reiser4 меня более чем устраивают. "Гнать лошадей" я не собираюсь - это не та область. Здесь "тише едешь - дальше будешь!" Современная ФС - это самая сложная подсистема ядра, неправильные решения в дизайне которой могут перечеркнуть последующий многолетний труд людей. Предлагая волонтёрам что-то реализовать, я всегда гарантирую, что усилия непременно приведут к корректному результату, который может быть востребован для серьёзных нужд. Как вы понимаете, таких гарантий не может быть много и сразу. В то же время я терпеть не могу "деятелей", которые бесстыдно пиарят "фичи" заведомо непригодного для использования софта, обманывая сотни пользователей и разработчиков, да при этом сидят и улыбаются на кернел саммитах.

— Выражала ли какая-нибудь компания готовность поддержать разработку Reiser4?

Да, такие предложения были, в т.ч. и от крупного вендора. Но, для этого мне надо было переезжать в другую страну. К сожалению, мне уже давно не 30 лет, я не могу сорваться и уехать вот так вот по первому свисту.

— Каких функций не хватает в Reiser4 сейчас?

Не хватает функции "растяжения" (resize) для простых томов по аналогии с той, что имеется в ReiserFS(v3). Кроме того, не помешали бы файловые операции с флагом DIRECT_IO. Далее, хотелось бы уметь сегрегировать том на "семантические подтома", которые не имеют фиксированного размера, и которые можно монтировать как самостоятельные тома. Эти задачи хороши для начинающих, желающих попробовать себя в "настоящем деле". И, наконец, хотелось бы иметь сетевые логические тома с простой реализацией и администрированием (современные алгоритмы уже позволяют это сделать). А вот чего в Reiser4 точно никогда не будет - так это RAID-Z, скрабов, кэшей свободного пространства, 128-битных переменных и прочей маркетинговой ерунды, возникшей на фоне дефицита идей у разработчиков некоторых ФС.

— Всё ли то, что может понадобиться, может быть реализовано плагинами?

Если говорить только в терминах интерфейсов и плагинов (модулей), которые их реализуют, то не всё. Но если ввести ещё и отношения на этих интерфейсах, то помимо всего прочего у вас возникнут понятия высших полиморфизмов, которыми уже можно обойтись. Представьте, что вы гипотетически заморозили объектно-ориентированную систему времени выполнения, поменяли значение instruction pointer, чтобы он указывал на другой плагин, который реализует тот же интерфейс X, а потом разморозили систему, так чтобы она продолжила выполнение. Если при этом конечный пользователь не заметит такой "подмены", то мы говорим, что система обладает полиморфизмом нулевого порядка в интерфейсе X (или система гетерогенна в интерфейсе X, что то же самое). Если теперь у вас не просто набор интерфейсов, а ещё имеются и отношения на них (граф интерфейсов), то можно ввести полиморфизмы и более высоких порядков, которые будут характеризовать гетерогенность системы уже в "окрестности" какого-либо интерфейса. Такую классификацию я когда-то давно ввёл, но опубликовать, к сожалению, так и не получилось. Так вот, при помощи плагинов и таких вот высших полиморфизмов можно описать любую известную фичу, а также "предсказать" те, которые никогда даже не упоминались. Строго доказать это мне не удалось, но и контрпримера я тоже пока не знаю. Вообще, вопрос этот напомнил мне "Эрлангенскую Программу" Феликса Клейна. Он в своё время пытался представить всю геометрию разделом алгебры (конкретно, теории групп).

— Теперь к главному вопросу — как обстоят дела с продвижением Reiser4 в основное ядро? Были ли публикации по архитектуре этой ФС, о которых ты говорил в прошлом интервью? Насколько вообще с твоей точки зрения этот вопрос актуален?

Вообще, мы в течение трёх лет просили о включении в основную ветку. Последний комментарий Рейзера в публичном треде, где был сделал запрос на включение так и остался без ответа. Так что все дальнейшие вопросы - не к нам. Я же лично не понимаю, зачем нам "вливаться" в конкретную операционную систему. На Линуксе свет клином не сошёлся. Так что, есть отдельный репозиторий, в котором будут несколько веток-портов под разные ОС. Кому нужно - можете клонировать соответствующий порт и делать с ним всё что заблагорассудится (в рамках лицензии, разумеется). Ну, а если это кому-то не нужно, то это не мои проблемы. На этом вопрос о "продвижении в основное ядро Линукс" я предлагаю считать исчерпанным.

Публикации по архитектуре ФС актуальны, но я пока что находил время только на свои новые результаты, которые считаю более приоритетными. Ещё дело в том, что я математик, а в математике любая публикация - это сводка теорем и их доказательств. Публиковать там что-либо без доказательства - это признак дурного тона. Если же я строго докажу или опровергну какое-нибудь утверждение по архитектуре ФС, то получатся такие нагромождения, через которые будет довольно сложно продраться. Кому это нужно? Наверно, поэтому всё продолжает оставаться в своём старом виде - исходный код и комментарии к нему.

— Что существенно нового появилось в Reiser4 за последние несколько лет?

Материализовалась, наконец, долгожданная стабильность. Одной из последних сдалась ошибка, приводившая к "неудаляемым" директориям. Трудность была в том, что она проявлялась только на фоне коллизий хэшей имён и при определённом расположении директорных записей в узле дерева. Однако, для продакшена я Reiser4 по-прежнему рекомендовать не могу: для этого надо провести определённую работу при активном взаимодействии с администраторами продакшн-систем.

Удалось, наконец, реализовать свою давнюю задумку - разные транзакционные модели. До этого в Reiser4 работала только одна жестковкодированная модель Макдональда-Рейзера. Это создавало проблемы в дизайне. В частности, в такой транзакционной модели невозможны снимки (snapshots) - их будет портить компонента атома под названием "OVERWRITE SET". Сейчас Reiser4 поддерживает три транзакционные модели. В одной из них (Write-Anywhere) в атомную компоненту OVERWRITE SET входят только системные страницы (образы дисковых битовых карт и т.п.), которые "фотографированию" не подлежат (проблема курицы и яйца). Так что снимки теперь можно реализовать в лучшем виде. В другой транзакционной модели все модифицированные страницы попадают только в OVERWRITE SET (то есть, это по сути чистое журналирование). Эта модель для тех, кто жаловался на быструю фрагментацию Reiser4 разделов. Теперь в этой модели ваш раздел будет фрагментироваться не быстрее чем с ReiserFS (v3). Все три существующие модели за некоторыми оговорками гарантируют атомарность операций, однако пригодиться могут также и модели с потерей атомарности и с сохранением лишь целостности раздела. Такие модели могут оказаться полезными для всевозможных приложений (базы данных и т.п.), которые уже взвалили на себя часть подобных функций. Добавить эти модели в Reiser4 очень легко, но я этого не делал, ибо меня никто не просил, а лично мне это не нужно.

Появились контрольные суммы метаданных и недавно я дополнил их "экономичными" зеркалами" (пока нестабильный материал). В случае провала проверки контрольной суммы какого-либо блока Reiser4 немедленно считывает соответствующий блок с девайса-реплики. Заметьте, что ZFS и Btrfs так не могут: не позволяет дизайн. Там вы должны запустить специальный фоновый сканирующий процесс под названием "скраб" и ждать, когда он доберётся до проблемного блока. Такие мероприятия программисты образно называют "костылями".

И, наконец, появились гетерогенные логические тома, предлагающие всё то, чего ZFS, Btrfs, block layer, а также связки FS+LVM в принципе дать не могут - это параллельное масштабирование, O(1)-аллокатор дисковых адресов, прозрачная миграцией данных между подтомами. Для последней также имеется пользовательский интерфейс. Теперь наиболее "горячие" данные вы без труда можете переместить на самый высокопроизводительный накопитель вашего тома. Кроме того, имеется возможность экстренно сбрасывать на такой накопитель любые грязные страницы, и, тем самым, значительно ускорить приложения, часто вызывающие fsync(2). Отмечу, что функциональность block layer, называемая bcache, совершенно не предоставляет такой свободы действий. Новые логические тома основаны на моих алгоритмах (есть соостветствующие патенты). Софт уже достаточно стабилен, вполне можно попробовать, замерить производительность и т.п. Единственное неудобство - пока нужно вручную обновлять конфигурацию тома и где-то ёё хранить.

Реализовать свои задумки мне удалось пока что процентов на 10. Однако, удалось то, что я считал наиболее трудным - это "подружить" логические тома с флаш-процедурой, которая выполняет все отложенные действия в reiser4. Это всё пока в экспериментальной ветке "format41".

— Проходит ли Reiser4 тесты xfstests?

По крайней мере, у меня прошла, когда я готовил последний релиз.

— Возможно ли в принципе с помощью плагинов сделать Reiser4 сетевой (кластерной) ФС?

Можно, и даже нужно! Если на основе правильно спроектированной локальной ФС создать сетевую, то результат будет очень впечатляющим! В современных сетевых ФС меня не устраивает наличие уровня backend storage, который реализуется при помощи любой локальной ФС. Существование этого уровеня совершенно неоправдано. Сетевая ФС должна нарямую взаимодействовать с block layer, и не просить локальную ФС создать ещё какие-то там служебные файлы! Вообще, деление файловых систем на локальные и сетевые - это от лукавого. Оно возникло от несовершенства алгоритмов, которыми пользовались тридцать лет назад, и вместо которых до сих пор ничего не было предложено. Это же является причиной появления массы ненужных софтверных компонет (различных сервисов и т.д). По-хорошему, должна быть только одна ФС в виде модуля ядра и набора пользовательских утилит, инсталлируемых на каждой машине - узле кластера. Эта ФС одновременно и локальная и сетевая. И ничего лишнего!

— Если с Reiser4 в Linux'е так ничего и не получится, хотелось бы предложить ФС для FreeBSD (цитата из прошлого интервью: «…FreeBSD … имеет академические корни… А это означает, что с большой долей вероятности мы найдём с разработчиками общий язык»)?

Итак, как мы только что выяснили, с Линуксом у нас всё уже прекрасно получилось: под него есть отдельный работающий порт Reiser4 в виде мастер-бранча нашего репозитория. Про FreeBSD я и не забыл! Предлагайте! Готов плотно поработать c теми, кто хорошо знает внутренности FreeBSD. Кстати: что мне очень нравится в их сообществе - там решения принимаются обновляемым советом независимых экспертов, не имеющим ничего общего с губонадувательством одной бессменной персоны.

— Как ты оцениваешь сообщество пользователей Linux сегодня? Стало ли оно более «попсовым»?

Мне по роду своей деятельности оценить такое достаточно трудно. Ко мне в основном приходят пользователи с багрепортами и просьбами починить раздел. Пользователи как пользователи. Кто-то подкован больше, кто-то меньше. Ко всем отношение одинаковое. Ну, а если пользователь игнорирует мои указания, то тут уж извините: игнор будет введён и с моей стороны.

— Возможно ли спрогнозировать развитие файловых систем на ближайшие пять-десять лет? Какие, по-твоему, основные вызовы могут стоять перед разработчиками ФС?

Да, сделать такой прогноз несложно. В апстриме давно уже нет никакого развития файловых систем. Создаётся лишь видимость такового. Разработчики локальных ФС упёрлись в проблемы связанные с неудачным дизайном. Здесь нужно сделать оговорку. Т.н "хранение", "вылизывание" и портирование кода я за развитие и разработку не считаю. А недоразумение под названием "Btrfs" к разработкам не причисляю по причинам, которые я уже объяснил. Каждый патч лишь усугубляет её проблемы. Ну, и всегда находятся разного рода "евангелисты", у которых "всё работает". В основном, это школьники и студенты, прогуливающие лекции. Вы только представьте: у него работает, а у профессора нет. Это какой же выброс адреналина! Наибольший же вред с моей точки зрения приносят "умельцы", бросившиеся с энтузиазмом "привинчивать" чудо-фичи Btrfs к всевозможным прослойкам типа systemd, docker, и т.п. - это уже напоминает метастазы.

Давайте теперь попробуем сделать прогноз на пять-десять лет. Что мы будем делать в Reiser4 я вкратце уже перечислил. Основным вызовом для разработчиков локальных ФС из апстрима станет (да, уже стало) невозможность заниматься приличным делом за зарплату. Без каких-либо идей в области хранения данных они будут продолжать пытаться патчить эти несчастные VFS, XFS и ext4. Особенно комично на этом фоне выглядит ситуация с VFS, напоминающая остервенелую модернизацию ресторана в котором поваров нет, и не предвидится. Теперь код VFS безо всяких условий залочивает одновременно несколько страниц памяти и предлагает нижележащей ФС оперировать над ними. Это было введено для повышения производительности Ext4 на операциях удаления, но, как нетрудно понять, такой одновременный лок совершенно несовместим с продвинутыми транзакционными моделями. То есть, добавить поддержку какой-то умной ФС в ядре вы уже просто так не сможете. Я не знаю, как дело обстоит в остальных областях Linux, но что касается файловых систем, какое-либо развитие здесь вряд ли совместимо с политикой, проводимой Торвальдсом на деле (академические проекты изгоняются, а мошенникам, не имеющим понятия, что такое B-дерево, выдаются бесконечные кредиты доверия). Поэтому тут был взят курс на медленное загнивание. Его, конечно же, изо всех сил будут пытаться выдать за "развитие". Далее, "хранители" файловых систем, поняв, что на одном лишь "хранении" много не заработаешь, будут пробовать себя в более прибыльном бизнесе. Это, как правило, распределенные файловые системы и виртуализация. Возможно, куда-то ещё будут портировать модную ZFS там, где её ещё нет. Но она, как и все ФС из апстрима, напоминает новогоднюю ёлку: если сверху ещё что-то из мелочи повесить можно, то глубже уже не подлезешь. Я допускаю, что построить серьёзную энтерпрайз-систему на базе ZFS можно, но поскольку мы сейчас обсуждаем будущее, то мне остаётся с сожалением констатировать, что ZFS в этом плане безнадёжна: своими виртуальными девайсами ребята перекрыли себе и будущим поколениям кислород для дальнейших разработок. ZFS - это вчерашний день. А ext4 и XFS - уже даже не позавчерашний.

Отдельно стоит сказать про нашумевшее понятие "Linux file system of next generation". Это полностью политический и маркетинговый проект, созданный для возможности, так скажем, "столбить будущее файловых систем" в Linux за конкретными персонажами. Дело в том, что это раньше Linux был "just for fun". А сейчас это прежде всего машина для зарабатывания денег. Они делаются на всём, на чём только можно. К примеру, создать хороший программный продукт очень трудно, но смышленые "разработчики" давно уже сообразили, что напрягаться-то вовсе и не нужно: успешно продавать можно и несуществующий софт, анонсированный и распиаренный на всевозможных публичных мероприятиях - главное, чтобы в презентационных слайдах было побольше "фич". Файловые системы подходят для этого как нельзя лучше, ибо на результат можно смело выторговывать лет десять. Ну, а если кто-то потом будет сетовать на отсутствие этого самого результата, то он же в файловых системах просто ничего не смыслит! Это напоминает финансовую пирамиду: на вершине располагаются заварившие эту кашу авантюристы, и те немногие, кому "повезло": они "сняли дивиденды", т.е. получили деньги на разработку, устроились менеджерами на высокооплачиваемую работу, "засветились" на конференциях, и т.п. Далее идут те, кому "не повезло": они будут подсчитывать убытки, расхлебывать последствия развертывания в продакшн непригодного программного продукта ", и т.д. Их гораздо больше. Ну, и в основании пирамиды - огромная масса разработчиков, "пилящих" никчёмный код. Они - в самом большом проигрыше, ибо впустую потраченное время не вернёшь. Такие пирамиды чрезвычайно выгодны Торвальдсу и его приближенным. И чем этих пирамид больше - тем для них лучше. Для подпитки таких пирамид в ядро может быть принято всё что угодно. Разумеется, на публике они утверждают обратное. Но я сужу не по словам а по поступкам.

Так что, "будущее файловых систем в Линукс" - это очередной сильно распиаренный, но мало пригодный к использованию софт. После Btrfs с большой вероятностью место такого "будущего" займёт Bcachefs, представляющая собой ещё одну попытку скрестить Linux block layer с файловой системой (дурной пример заразителен). И что характерно: там те же проблемы, что и в Btrfs. Я давно это подозревал, а потом как-то не удержаляся и заглянул в код - так и есть! Авторы Bcachefs и Btrfs, создавая свои ФС, активно пользовались чужими исходниками, мало что в них понимая. Ситуация очень напоминает детскую игру "испорченный телефон". И я примерно представляю, как будет происходить включение этого кода в ядро. Собственно "грабли" никто не увидит (на них все будут наступать потом). После многочисленных придирок к стилю кода кода, обвинению в несуществующих нарушениях, и пр. будет делаться заключение о "лояльности" автора, о том, насколько он хорошо "взаимодействует" с остальными разработчиками, и как успешно всё это потом можно будет продавать корпорациям. Конечный же результат никого не заинтересует. Лет двадцать назад, может быть, бы и заинтересовал, но сейчас вопросы ставятся по-другому: получится ли это раскрутить так, чтобы ближайший десяток лет определённые люди оказались трудоустроены. А задаваться вопросом о конечном результате, увы, не принято.

А вообще, я бы настоятельно не рекомендовал начинать изобретать свою файловую систему "с нуля". Ибо даже существенных финансовых вложений будет недостаточно, чтобы лет за десять получить что-то конкурентоспособное. Разумеется, я говорю о серьёзных проектах, а не о тех, которые предназначены для "проталкивания" в ядро. Так что, более эффективный способ заявить о себе - это присоединиться к реальным разработкам, например к нам. Сделать это, разумеется, непросто - но так дело обстоит с любым проектом высокого уровня. Сначала нужно будет самостоятельно одолеть задачку, которую я предложу. После чего, убежденный в серьёзности ваших намерений, я начну помогать. Традиционно мы используем только собственные наработки. Исключение составляют алгоритмы компрессии и некоторые хэш-функции. Мы не отправляем разработчиков колесить по конференциям, а потом не сидим и не комбинируем чужие идеи ("авось, чего и получится"), как это принято в большинстве стартапов. Все алгоритмы мы разрабатываем сами. В настоящий момент меня интересуют алгебраические и комбинаторные аспекты науки хранения данных. В частности, конечные поля, асимптотика, доказательство неравенств. Для простых программистов тоже найдётся работа, однако должен сразу предупредить: все предложения "посмотреть на другую ФС и сделать так же" отправляются в игнор. Туда же пойдут патчи, направленные на более тесную интеграцию с Linux по линии VFS. Итак, у нас нет граблей, а есть понимание, куда надо двигаться, и есть уверенность, что это направление правильное. Такое понимание не пришло в виде манны небесной. Я напомню, что позади 29-летний опыт разработок, две файловые системы написанные "с нуля". И столько же утилит восстановления данных. А это очень много!

• https://sourceforge.net/projects/reiser4/files/

• https://github.com/edward6/reiser4