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

Это не гибко. Любое изменение конфигурации == боль пониже спины. С факом мозга подбором винтов и их размеров, адскими временами рестрайпа, при том чаще всего оффлайнового и нуждой куда-то на это время деть кучу данных и прочее.

Идея btrfs: доткнуть диск и, может быть, сделать ребаланс чтобы он принял на себя более-менее пропорциональную часть нагрузки/восстановил слетевшее парити (если надо, актуально для degraded RAID), etc. Это просто, круто и логично. И рациональнее в плане расхода места в mixed конфигурациях собранных "по месту", из накопителей разного объема.

Эта конструкция не подразумевает что например RAID1 - группа дисков одинакового объема. Можно скажем воткнуть 1 большой винч и 2 половинной емкости и получить емкость 1 большого винча - парные блоки будут жить на парах накопителей. И критерий возможность выполнить запись в формате RAID1 - есть достаточное место на 2 дисках. Не обязательно одинаковых. Так можно сделать довольно необычные конфиги, типа RAID1 из 3 дисков - с емкостью 1.5 диска (при одинаковых дисках).

Т.е. в целом это все сделано с пониманием со стороны архитекта одной из проблем эксплуатационщиков: довольно сложно и неудобно обеспечивать ФС идентичные девайсы и круто перетрясать все при желании например изменить схему райда. Btrfs сделан так что позволит в общем случае произвольно доткнуть 1 или N дисков в пул. Любых. Которые у вас под рукой есть. И это даст еще эн места. Собственно диск можно и изъять, главное чтобы не стало меньше минимального числа дисков нужных для затребованной схемы и на оставшихся дисках хватало бы места. Ну то-есть из "RAID1 @ 3 диска" можно взять да и вынуть 1 диск. Если на оставшихся 2 места хватит. При этом btrfs уберет блоки с вынимаемого диска. А ребаланс удостоверится что у каждого блока есть пара на другом девайсе. При том в это время все будет работать, данные будут доступны, их не надо будет никуда удвигать на время перекраивания схема райда и прочее.

И я почему-то так считаю что в идеале управление сколь-нибудь заметным сторажем с несколькими дисками должно выглядеть именно как-то вот так.

> на то и LVM, и при разумном планировании вряд ли это
> составило бы хоть какую-то проблему.

Распланировать все на века - затея довольно сложная. А в btrfs фича в том что никого не заствляют это делать - можно малой кровью все переиграть. Без того гемора который характерен для райдов работающих целиком на блочном уровне.

> принимать решения - что куда влезет. А вариант "решаем по ходу",
> как видим, слишком усложняет жизнь.

Любой дизайн подразумевает некий tradeoff. В классических сисколах о такой крутизне не задумывались и поэтому такое в системных вызовах просто не предусмотрено. Да и классическая семантика POSIX - явно не предел мечтаний для интерфейса к дизайнам на основе CoW. Возможно иногда наступает пора признать что нужно что-то доработать и расширить. В том числе и системные вызовы. Или посчитать что админ должен посмотреть статистику по девайсам и врубить мозг, если он хочет впихнуть еще 1 терабайтный файл на стораж.

> Эх, взять бы эту btrfs, выкинуть всё кроме COW со снапшотами -
> глядишь, давно была бы полностью готова, протестирована и предсказуема

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

> во всех мыслимых ситуациях, уже б, пожалуй, ext4 подвинула. А так... Комбайны - зло.

И да и нет. Это дает ряд грабель. Но дает и ряд уникальных достоинств которые по иному просто и не получишь. Те же классические блочные райды - идут по пути наименьшего сопротивления и сделали ряд допущений. Удобных разработчикам, но геморных при эксплуатации. А тут - ровно наоборот. Не вижу почему так должно быть нельзя. С точки зрения эксплуатации я предпочту простой и гибкий стораж. Если разработчикам придется попахать - ОК. В моем понимании их цели того стоят.