> Эта проблема решается банальной оптимизиацией кода и переписыванием некоторого функционала
> без изменения формата Btrfs.

Не все известные проблемы решаются так. По итогам эксплуатации и выявленных проблем некоторые структуры сами разработчики btrfs'а делая это сегодня сделали бы уже иначе.

В частности, если интересно, см их идеи на тему "extent tree v2" (нечто типа формата хранения v2). Оно даже где-то в работе, но поскольку там могут сменить формат несовместимо (в том смысле что "v1" драйвер на старых ядрах не сможет такое читать) - пользуясь случаем, вероятно, попробуют и еще ряд вещей починить. Так что это тоже не быстро будет наверное. А почему это надо? Оказалось что при массовой параллельной нагрузке и быстрых сторажах extent tree имеет недетскими проблемы с lock contention. Это убивает параллелизм операций и тормозит. Там, кстати, сбежаввший из редхата Басик как раз и зажигает :)

При том как вы понимаете, никто не будет выбрасывать всю инфраструктуру драйвера и РАДИКАЛЬНО перепахивать формат. Заткнут очевидные проблемы наиболее простыми (по кодингу) способами. Что логично, не стоит сильно ломать активно эксплуатируемую кодовую базу.

Кент же глядя на это все и будучи еще не замайнлайнен разумеется мог позволить себе редизайн некоторых вещей, даже если это и ломает совместимость - ему не с кем совместимость еще держать, так что может сделать "как лучше технически" раз 1 черт кодить от и до. В этом у него как у более позднего дизайна, совсем без требований совместимости, и ожиданий что это немедленно годно к эксплуатации - определенная фора. Пока еще может позволить себе достаточно резкие маневры если удачная идея пришла.

> Для этого не нужно создавать новую ФС, у которой найдутся свои проблемы и
> подводные камни, как только она станет популярной, как Btrfs.

Несомненно при эксплуатации bcachefs вылезут какие-нибудь еще проблемы, которые сейчас тематические лица не предусмотрели, а тестирование новой кодовой базы с такими фичами и вышибание багов займет нехилое время. И возможно по итогам его эксплуатации кому-то захочется сделать другой дизайн, next gen next gen'а. Где устранят какие-то еще слабые места. Даже те о которых мы сейчас еще и не знаем.

Это у шишкина все просто - развел теорий, практикой не проверял, и так то все ЗБС. А в реальном мире с реальными хотелками юзерей и реальными заскоками железа получается совсем не так как теоретические CSники себе это воображали, ну их барахло и работает совсем иначе чем они себе мнили в дофига случаев. По факту приходится делать странные костыли для затыкания порблем, пересматривать приоритеты, узнавать много нового об устройствах, их свойствах и отказах, и вообще сталкиваться с неидеальностью мира во весь рост. И без всего этого файлухи не особо нужны. Скажем "а что файлуха сделает на 1 бэд секторе". Или "а вот кернел ресетит девайс 2 минуты, это развал райда или нет? И если девайс вернется, то что?"