> Теоретик? Покажите команды для настройки такой схемы "индивидуально для каждого файла".

Их нет. Пока. Но архитектурно так можно. Если посмотреть на то как btrfs вообще сделан и как он выделяет пространство. Отсюда вытекает ряд, казалось бы, странностей.

> Для теоретиков: нет, различные уровни RAID для разных subvolume не поддерживаются и
> возможно будут введены в очень далёком будущем.

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

Это выглядит как-то так: в ФС есть некие наборы chunks. Chunks могут быть с разными вариантами избыточности. Даже сейчас, btrfs оперирует несколькими наборами chunks с разными настройками - системные данные, метаданные и данные это группы chunk-ов с отдельными настройками избыточности.

Место на дисках выделяется как правило в юнитах равных chunk-у. На уровне архитектуры ФС нормально относится к тому факту что на дисках будет лежать произвольная смесь chunks с той или иной степенью избыточности. Такая ситуация возможна уже сейчас - при конвертации уровней RAID на ходу будет происходить именно это. При этом данные остаются доступны, etc.

> RAID выбирается на всю файловую систему целиком. Ну или покажите нам тайные
> параметры "btrfs subvolume create"

Могу показать balance, который на ходу делает restripe chunk-ов по фильтру, что демонстрирует замашки авторов. И кстати subvolume как таковой - вообще лишь очередная иерархия и не имеет ничего общего с блочным разделом. А так - да, у них пока не все что позволяет их архитектура реализовано в утилитах настройки и отдельных закоулках логики ФС.

Но даже сейчас - см. например как btrfs относится к ситуации когда есть 3 диска одинакового размера и запросили RAID1. Как это с точки зрения ФС? Раз просят RAID1 значит запись должна попасть на 2 разных девайса. В результате заняты будут все 3 девайса, а емкость будет 1.5 емкости девайса. Не очень похоже на то что мог бы сделать с 3-я дисками обычный RAID1, правда?

> LVM + любая ФС. ZFS. То о чем вы говорите не является
> каким-то нововведением.

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

LVM, ZFS - они сделаны с допущением что схема райда выбирается 1 раз и на века и не может быть разной. Мэйсон низко не летает и решил сделать интереснее. Технически оно вполне может оперировать разными уровнями райда для разных объектов. Пока это не используется в полную силу. Но дизайн позволяет.

> Мы же уже определились - одна ФС, одна схема.

Это не так. Даже прямо сейчас возможны (и практикуются) нарушения этого допущения. Например в однодисковой конфиге данные по дефолт убудут лежать как "no raid" а метаданные и системные области - "DUP" (зеркалирование путем размещения в 2 разных местах накопителя). Уже 2 разные схемы размещения. А при создании райдов и ребалансе можно это переиграть. Это пока очень базово, но это не отменяет того что дизайн может намного больше. И вот такие странности - следствие гибкого дизайна с большим запасом на перспективу.

> Она стала известна после создания ФС или изменения с последующей ребалансировкой.

Это частный субсет возможностей дизайна который реализован прямо сейчас. И даже сейчас оно вполне себе оперирует разными схемами хранения блоков. Данные, метаданные и системные блоки могут лежать в разных схемах хранения уже сейчас.

> Так что известно какую и как это согласовывается с реалиями на девайсах.

Это не так. Даже сейчас.

> Вы не поверите но все это можно сделать с помощью LVM +
> ext*/xfs/jfs/raiserjs, zfs, geom, да черт возьми даже в Windows 2000

Можно. Только btrfs сможет все это регулировать пообъектно и не через ж...у. С перспективами гранулярного администрирования и неспешной перебазировки онлайн, с произвольной смесью уровней которая допускается комбинацией девайсов и свободным местом на них. Именно поэтому есть некоторые непонятки с свободным местом - в общем случае заранее неизвестно в какой схеме будут выделены следующие блоки. Поэтому нельзя сказать сколько и чего влезет.

> с помощью динамических дисков и точек повторной обработки!

А еще можно изловчиться правой пяткой почесать левое ухо. А попробуйте хотя-бы копирование с референсом (cp --reflink ...) изобразить по людски? На btrfs так можно сделать пять копий допустим виртуалки, изначально будут занимать места как 1 копия, а дальше - в зависимости от отличий. Этакий дедуп сразу на старте. А покажите такое на нтфс?

> И вот неожиданность именно Btrfs всё это знает. И свободное место и
> запрашиваемую схему.

Это не так. Свободное место - знает. Схему - нет. Даже сейчас используется несколько схем которые не обязаны совпадать.

> RAID, сколько subvolums и снепшотов и df и btrfs fi df
> выводят информацию по ФАЙЛОВЫМ СИСТЕМАМ а не отдельным файлам.

btrfs fi df выводит видение btrfs'ом групп chunk-ов для которых уже что-то где-то когда-то было выделено. А просто df - выводит <нечто>. Просто потому что должен что-то выводить. Я не понимаю какой физический смысл может нести единая цифирь при такой архитектуре. Легаси подходы просто не заточены на ТАКОЙ подход.

Еще есть btrfs filesystem show. Он как я понимаю показывает как раз состояние дел по девайсам. Как вы понимаете, на девайсе может и не быть chunks по всей площади, что однако не означает что нельзя создать новый chunk и заюзать его.

> Только df выводит сколько место используется и сколько свободно для ФС.

Для btrfs он выводит некую сферическую фигню в вакууме, просто потому что там надо что-то вернуть. Физический смысл этой цифири при таком дизайне мне не очевиден. А еще там между прочим есть сжатие, при том заранее неизвестно на сколько сожмется. И референс блоков (некоторые называют это дедупликацией), которые делают понятие свободного места еще более интересной величиной. Например я могу сделать кучу копий файла через reflink. При этом изначально занимаемое место близко к размеру 1 файла, независимо от числа копий (плюс-минус метаданные). А дальше зависит от фактических отличий (некоторые называют это коэффициентом дедупликации). И даже в обычных ФС есть например sparse файлы, где логическое пространство и физически занимаемое место - 2 большие разницы. По поводу чего рассказы о свободном месте и "влезет ли вон тот файл" на самом деле далеки от тривиальных. Особенно для btrfs.

> А btrfs fi df выводит такую хрень, как сколько места заюзано по
> Data, System, Metadata и не в состоянии сказать, а сколько примерно
> ещё свободного места есть в системе.

Он выводит состояние по уже занятым областям накопителей которые btrfs "приватизировал" в chunk-и и расписывает какие группы chunk-ов с какой избыточностью вообще в ФС есть. Это полезно для тех кто понимает как работает btrfs-овская аллокация пространства (ну и смесь уровней избыточности). А вы видимо хотите нечто типа btrfs filesystem show...

> Конечно, сколько ФС заюзала под свои метаданные мне знать нужней
> объема свободного места.

Это тоже достаточно актуальные величины для конкретно этого аллокатора. Они позволяют понимать внутреннее состояние аллокатора, чем он по факту оперирует и какое там состояние дел.

> именуете "subvolums" (вы неверно приписали это свойство btrfs).

Технически, subvolume - всего лишь "еще одна иерархия". С рядом индивидуальных настроек. Оно не имеет ничего общего с блочными разделами и прочим.

> И почему то ей доисторического сискола хватает. И она в состоянии вывести
> объем свободного места, причем правильно.

Потому что там обычый архаичный подход к райдам, не имеющий ничего общего с btrfs. В btrfs все это архитектурно сделано намного интереснее. Откуда и странности с свободным местом. Потому что оно подразумевает произвольную смесь уровеней избыточности.

> И судя по вашим утверждениям о RAID на файл вы не особо хорошо знакомы
> не с внутренним устройством btrfs, ни с её практическим применением.

Скорее слишком много смотрел на ее архитектуру и поэтому грань между тем что оно может архитектурно и тем что уже сделано начала размываться.