> На ключах он почему-то сэкономил (ключ в btrfs — 136 бит, в reiser4 — 192 бита),Наверное, потому что когда чего-то много, логично это делать поменьше.
> но терабайты дискового пространства
Эпичный булшит. В типовых юзкейсах нет ничего и близко похожего на это.
> (и оперативной памяти)
Еще более эпический булшит, ибо работает даже на роутере с 500МГц процом и 64 мегах оперативы, при том в отличие от ZFS какого - по перфомансу скорее на EXT4 смахивает чем на слоупока.
> пользователей неудачной балнсировкой под откос пустил. Дополнительные поля ключа —
> это возможность по-разному группировать данные и метаданные.
С другой стороны btrfs c их block groups может в РАЗНЫЕ уровни RAID для данных и метаданных. Это имеет полезные применения. Рейзер о таком вообще думал? Ага, btrfs не мрет от 1 бэда на единственном винче под метаданными - он блок метаданных из второй копии достает. А рейзер в таких случаях имеет свойство чинить тома в вермишель, но вон там дескать можете заказать дата рекавери. Так то нормальный бизнес, но не для разработчика же ФС?! :)
> сплошной компромисс: фазу squeeze балансировки, а также компрессию и шифрование данных
> отложить наподобие техники «delayed allocation» нельзя.
А таки в btrfs это вынесено в фоновый ядерный воркер, они видимо были не в курсе что так нельзя, ну и сделали.
> А потом, мне кажется, что эти ребята упрутся в проблемы с масштабируемостью
> из-за невозможности организовать приличную схему блокировок на таком дереве.
Как ни странно - пальцем в небо. Правда наверное не на том дереве какое вы подумали, однако на очень быстрых сторажах типа оптанов одно из деревьев становится проблемой. На тему чего у них есть некие доработки лэйаута, условный "v2" btrfs'а (пока WIP и не в майнлайне).
Но основная их трабла - на супербыстрых сторажах и миллионах IOPS на ядро оверхед становится крайне критичен. Вообще всегда и везде. Btrfs не проектировали под ТАКИЕ реалии и снижение оверхеда по всей площади их проблема #1, пожалуй. Если посмотреть комиты в последних эн ядер... а, там же где-то и рефактор на io_uring есть. На него наверное всех перетащат постепенно.
Еще кстати из сравнимого можно глянуть на bcachefs. Он сразу делан с учетом того что оверхед должен быть как можно ниже. Но его проектировали, пардон, когда?!
А у шишкина есть некое vaporware. Обладателям оптанов вообще не сильно интересное - так что как оно там пашет на них - хрен его там знает, это возможно никто никогда не бенчмаркал вообще. К тому же кроме скорости применительно к ФС есть и много иных соображений.
> Скажу только, что гораздо выгоднее распределить «работу по дереву» между бо́льшим
> количеством процессов, и пустить часть из них навстречу (снизу вверх), а не так,
> чтобы все они ломились в это дерево сверху через общий корень.
Они сделали ... довольно забавный финт в V2. Деревьев может быть более одного, например. И тогда при операциях на разных деревьях взаимные блокировки не возникают и ничего не тормозят. Немного костыльненько, зато без радикального перекроя все и вся и проблему решает.
> дело: если проект основан на неудачных идеях, из него сложно сделать конфетку.
Оно сейчас вполне годно к продакшновой эксплуатации, а перфоманс если и икается кому то разве что обладателям оптанов.
> К слову, вся история Namesys — это непрерывные контакты с академическими институтами
> (МГУ, Институт программных систем РАН в Переславле-Залесском).
Софтострой не о крутой математике в чистом виде, он о том чтобы нормально сбалансировать всю штуку в целом. Чего вон те, из мгу и проч - вообще совсем без шансов. Они в лучшем случае придумают удачных алгоритмов, но вот в нормальную ФС пригодную для продакшна чистые математики это не отольют. Да и рейзер 3, единственный кого до прода допинали, отметился тем что порой выносил тома в вермишель с коментами девов - notabug.
> XFS — это тоже целая школа в Silicon Graphics.
А толку? По метаданным он дикий тормоз, ибо делался под видеомонтаж, там файлов немного, огромных, без кучи фрагментов. А если у вас не оно - тогда оно весьма печальное. К тому же редгад хотел натянуть сову на глобус и кой-как туда прикрутил CoW. Но CoW прикрученый сбоку работает все же не так хорошо как изначально заложенный в проекте.
А заодно -
1) Вот вам мсг что в 2030 ваши легаси тома станут тыквой.
2) Вот вам фига а не путь миграции старых сторажей, ога. Типа, пересоздайте.
3) Оно так и осталось тормоз по метаданным.
4) Продвинутую аллокацию и управление ей оно не умеет, так что вот вам пихтонрасовые сратисы и лоскутное одеяло. Могу себе представить что будет что будет если в этом месиве какая-то длительная операция вообще завалится. Btrfs в этом плане сильно более продуманная штука. И даже переживает смесь уровней RAID в "полуконвертированой" ФС.
5) Ах да, уменьшать размер фс XFS так и не научили. Поэтому можете забыть об идее вынуть подоткнутый на время стораж. Это вам не btrfs.
> А Btrfs — это история чего? Пары низкоуровневых воркшопов? А как ещё назвать мероприятия,
> на которых анонсируются несуществующие фичи? В чудеса я давно перестал верить…"
Все фичи которые ими анонсированы я почему-то смог использовать на практике. При том - с майнлайновым ядром. Сразу. Без выкрутасов и приключений.
> Поверю Михаилу.
Да хоть черту лысому, только у вон тех есть реально работающая ФС которой можно пользоваться, и это обслуживает 2 миллиарда рож на планете. А у этих концептуалов только концепции. Где-то сильно сбоку и явно не продакшнового качества. Такая разница.
