> Интересно. Я, конечно, не изучал устройство бтрфс так глубоко, поэтому полагал,CoW'ы next gen технология. С особенностями, сильными и слабыми (чудес не бывает) сторонами. На основе этого некоторые вещи делаются достаточно круто и неординарно. Ну, вот, типа снапшотов, или множественных ссылок на блоки. Но лучше понимать как это работает, чтобы не обломаться.
Скажем я могу из шаблона VM сделать 5 клонов, с как-бы независимыми дисками, сделав диску шаблона cp --reflink. Завершится за пару секунд, изначально будет 5 ссылок на 1 блоки оригинала. Они даже места не займут сразу. Пять виртуалок с дисками на 20 Гб будут жрать суммарно примерно те 20Гб на всех. А вот по мере их эксплуатации и расхождения состояния фс поддержит иллюзию что файлы и правда независимые, копируя нужные блоки в сторонку. Потому и copy-on-write. Если записей мало, оно так и будет почти как 1 виртуалка по весу. Если много - станет ближе к независимым копиям.
> что subvolum означает примкнутый - смонтированный иной раздел с бтрфс как дополнительное
> место к основному, прописанному в фстаб-е...
В случае btrfs означает супер-директорию которую можно независимо от остальных снапшотить.Просто точка входа в CoW иерархию пригодная для независимых снапшотов и монтирования по имени этого, как в примере с fstab. Снапшоты впрочем тоже subvolume, в этом полная симметрия. К управлению местом особого отношения не имеет. Поэтмоу удобно всех на 1 разделе держать, ну а нафиг вам лоскуты с прибитой на гвозди аллокацией места когда место можно делить на home и system динамически? При этом меньше риска промахнуться с оценками кому сколько. А добавление скажем нового девайса в пул может прибавить места всем и сразу. Без канители - ненапряжнй менеджмент.
> А здесь что получается - допустим, 1ое устройство делится логически на два
> раздела (допустим, для монтирования корня и домашней) и размеры логически имеют
> равные, но при исчерпании места, например в субволюм @ - возьмет ли драйвер фс
> свободное место из половины @home или это вообще ничего не означает,
Это означает что есть ФС. Свободное место в ней определяется выделенными ей устройствами и их размерами. А этой ФС может быть 1 или несколько subvolume которые делят между собой место на этой ФС "динамически", как файлы в разных дирах. Можно считать это директориями на стероидах, только снапшотить можно независимо, и, вот, референсить при монтировании, например. А чисто технически subvolume можно переименовывать, и даже с некоторых пор стирать, как обычные диры, так что только создание снапшота требует какие-то специальные команды. Жонглирование уже имеющимися может происходить в терминах иерархий. Просто желательно это уровнем выше делать, вне видимости этого для системы. Уровень менеджмента выше / решает эту проблему.
> а лишь только то, что и @ и @home берут места на первом устройстве до тех пор,
> пока оно не кончится??...
Если в одну и ту же ФС btrfs (с одним и тем же UUID) входит более 1 устройства, место доступное btrfs доступно всем subvolume входящим в этот btrfs. Один btrfs может распостраняться на несколько устройств, с той или иной схемой хранения. Если устройств более 1 то народ часто RAID хочет для повышения надежности, что логично. Но можно и просто место отрастить (e.g. RAID0) но при кончине любого из юзаемых устройств будет нехорошо, разумеется, если избыточной копии не было. В любом случае дотыкание очередного устройства добавляет места в пул на всю ораву (фс с данным UUID). Вы не создаете новый btrfs при этом, просто просите btrfs заюзать +1 девайс, он сам создаст на нем ... себя, именно тот UUID.
> Тогда возникает второй вопрос - именно добавление той командой иного устройства,
> например sdb (как целого, а не разделенного на разделы), позволит использовать
> субволюмам (подтомам, по-русски говоря) свободное место второго устройства имеенно
> также как и первого - т.е - сколько нужно @ и @home - столько и
> будет выделяться по надобности??...
Все так. Оба увидят все место доступное в ФС. Если в ФС более 1 устройства, получившееся свободное место доступно им всем. Поэтому дотыкание устройства добавляет места и системе и хомяку. Если использовать именно btrfs'ный вариант.
Это даже с RAID1 работает. Если у вас было 2 устройства по терабайту и вы третье добавили, ну, ок, теперь у вас RAID1 на условные полтора терабайта: суммарные 3 Тб деленые на 2. Вот прям так. И это будет видно всему что на этой ФС жило. Да, пардон, из-за этого ответ на вопрос "а сколько места реально есть" не всегда так тривиален как могло бы хотеться. Это порождает странные мифы и легенды.
> Если это так - то могу отдать должное разработчикам! Мысля более чем не плохая - так и до
> гениальности, имхо, недалеко!!!)...
Вы же не думали что они столько возились с новым дизайном по приколу? Этой штукой и правда удобно рулить и можно забыть безобразие которое было раньше как страшный сон :). Ну да, панацеи не бывает и за это есть свои особенности. Но почитать мануал на этот персональный глайдер все же стоит, чтобы не обнаружить что у вас ВНЕЗАПНО закончился кислород.
> А как тогда с рейдом будет обстоять дело? Допустим, если охота будет
> из второго устройства сделать именно скоростной рейд -
Добавить второй девайс в конфигурации RAID0? Так можно, но вылет любого из 2 естественно испортит ФС. Хотя возможны забавные комбо, когда метаданные RAID1 а данные RAID0. Вообще оно само начинает RAID1 на метаданных юзать если 2 или более устройств было, так то очень разумно, метаданные не очень много места занимают а вот их слет весьма фатален.
> скорость при записи и чтении?? Тогда я вообще сниму шляпу
> перед разработчиками!!!)
Ну вот насчет параллелинга операций там не все идеально. На самом деле такой дизайн может сильно больше того что реализовано в уровнях управления и абстракциях. Скажем, теоретически можно было бы хоть разный уровень RAID разным файлам (или дирам) заказывать, раз уж оно с смесью уровней живет. Просто нет уровня который бы занялся принятием решений "а как мы пишем блоки вот именно этого файла?!".
> П.Н. спасибо за наводку, буду изучать и пробовать внедрять!
Из интересных будущих разработок на тему в линуксе bcachefs еще делают, но он пока не в ядре. Авторы оного явно увлекались btrfs - только подумали как это еще и БЫСТРЫМ сделать. Btrfs не то что медленынй, но на современных суперскоростных SSD может и не быть чемпионом. Ну а сабж это лучшее что у BSDшников на тему есть. Чем оно и интересно. Есть ZFS еще но он здоровенный, прожорливый, с странностями дизайна. Первый блин. Который как известно, всегда немного комом.
