> Конкретизируй, в каких?Основное применение - если добавили в пул новый диск и хочется снести на него часть нагрузки. Ну еще для воссоздания копии raid-1 после изъятия сдохшего диска. Это штатные применения. Еще - как побочный эффект может освободить некоторый объем свободного места, но это костыль и обычно имеет смысл в кривых случаях и не должно требоваться в нормальной ситуации.
Возможен также реверсный балансу процесс: можно запросить изъятие диска из пула, при этом будет проход по back references - блоки с указанного диска будут убраны на другие диски, если там есть достаточно места. После этого диск не будет содержать ни 1 блока данных и метаданных и его можно безболезненно изъять из пула. Свободное место доступное btrfs в пуле сократится на размер изъятого диска, что логично. А в ZFS штатно backrefs нет и поэтому удвинуть "вот эти блоки с вот этого диска" простыми и очевидными методами - вообще опаньки, т.к. нет простого метода понять к кому они относились и пометить перемещение, чтобы блоки искали в новом месте. Я так понимаю что человеческого изъятия диска из пула в ZFS до сих пор нет? (не очень понимаю как это можно культурно делать при дисковой механике где это заранее не предусмотрели)
Вообще, https://btrfs.wiki.kernel.org/index.php/FAQ#What_does_.22bal...
Там же рядом рассказано почему все так сложно с свободным местом ;). Даже сами разработчики согласны с тем что это не круто, но - вы готовы предложить алгоритм, готовый столкнуться с пообъектным RAID-ом? Заранее неизвестно какой RAID для какого объекта могут попросить, что доставляет.
> Подтома, subvolume.
А, ты про них. Там скорее проблема в мелком стораже - дефолты btrfs не заточены на всякие карты памяти в пару гигз. Для любителей утонченных извращений сделали mixed mode который не страдает от гранулярности выделения чанков на данные/метаданные. Но все это актуально для мизерных носителей, когда гранулярность аллокации чанков сравнима с размером носителя. Актуально при размерах всей ФС порядка несколько Гб. На более крупных ФС оно по идее и без этого должно быть в более-менее нормальном состоянии с точностью до крох, которые мало что решают.
> Места для новых метаданных не было зарезервировано - нельзя создать подтом.
Ты думается не о том, а о выделении чанков на данные/метаданные, на мелком носителе гранулярность выделения может быть сравнима с размером носителя и может выйти дурная ситуация когда все чанки с данными или метаданными заняты, а противоположных типов чанков не хватило и вроде как места еще немного есть, но создать файл не выйдет из-за невозможности записать данные или метаданные. Но это актуально только для мелких носителей. Для больших носителей (на что btrfs в основном и заточен) - неточность в стыковке размера данных и метаданных будет в пределах погрешности.
А подтома в btrfs штука своеобразная. Это некая административная единица, подддерево которое может иметь ряд настроек отличных от остальных и ведет себя как отдельная независимая точка входа в новую ФС, по типу "/" в плане следования иерархии, снапшотирования и прочее. Но все эти "новые ФС" шарят на все и всяя пространство единого глобального пула свободного места.
> Ну а зачем ты в теме про ZFS пишешь про Btrfs?
Это не я начал. А пишу потому что анноит читать тормозизмы и/или явную дезу.
