> и просто отключаешь эту фичу и живешь счастливо (восстановив пул из бэкапа,
> потому что оно не отключается на существующем). Но, к сожалению, маловероятно.

Когда возникают вопросы вида "восстановив пул из бэкапа" я рад что все это - не у меня :))

> выбирают меньшее из зол (например, storage spaces ;-)

Кому попадья, кому свиной хрящик, как грится.

> безусловно отсутствие у btrfs полноценного гитхаба и списка открытых багов говорит о
> его пригодности к продакшну и проч,

У них нормальная багзила. Хорошо работает - берут в оборот не дожидаясь накопления 1К багов. Мля, когда тебе кило багов насыпали, глаза будут в кучку и ты не будешь знать за что схватиться. Но ты конечно можешь мне рассказать как это делать правильно. Есть только 1 нюанс - я в мегакорпах в R&D был и получше твоего в курсе, так что удачи.

> а не о том что линукс и его разработка давным-давно полная помойка застрявшая в начале 90х,
> где баги надо искать среди миллиарда писем в lkml оставленных без
> ответа или с парой тысяч комментариев не по теме.

Да вообщет там багзила есть. Для увеличения эффекта она дублирует и письмом в LKML. Но тебе то простительно не знать. Из тебя линукс разработчик, который -next от mainline отличить не может блин. Только и остается что на гитхабе колупаться, еще патчи начни через вебредактор им присылать(не помню, есть он уже на гитхабе?). Так победите! (самих себя, кстати)

А знаешь в чем разница? Я суммарно навесил - и мы потом сообща загасили - сколько-то десятков багов в Linux Kernel. Конкретно btrfs'ники были крайне эффективны. В том числе и через тот интерфейс. Так что все баги которые я им навешивал уже давно -> closed. Мне кажется такое состояние дел способствует чтобы их 1K не было. Впрочем они научились гонять дофейхоа тестов - а если этого мало оказалось - то - вот - в -rc толпа еще дополнительно тестирует более странные вещи.