[sisyphus] Reiserfs4

[Rinat Bikov]

20 июля 2011 г. 15:51 Michael Shigorin написал:
> Извиняюсь за вторжение, но если хочется экстрима --
> думаю, сейчас конструктивнее тестировать btrfs...
http://habrahabr.ru/blogs/linux/108629/
— Каково твоё мнение о текущем положении дел с 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 — это история чего? Пары низкоуровневых воркшопов? А как ещё
назвать мероприятия, на которых анонсируются несуществующие фичи? В
чудеса я давно перестал верить…


-- 
С уважением, Ринат Биков.