> А как теперь, если появился новый носитель, теперь можно добавить, например к
> корню, новый раздел как дополнительный - команда btrfs device add, как японял, добавит,

Абсолютно. После add просто эн места появляется. Очень приколько так RAID'ы отращивать, никаких приключений с добавлением строго по N устройств 1 размера и прочим имением мозга когда приходится в угаре искать вот именно подходящий накопитель а вокруг пять "неподходящих" болтается. Просто добавляем что есть и готово.

В терминах BTRFS допустим RAID1 это "положи блоки на 2 разные устройства". При этом разные блоки могут лежать на разных устройствах и их парах, в любом случае при отказе вон того устройства для всех его блоков найдутся те же блоки на каких-то других устройствах в ФС. Это не есть глупый блочный RAID с 1:1 по пространству на зеркалах, более продвинутое гранулярное нечто. Оно даже частично конвертированое и со смесью уровней вполне себе живет, позволяя на лету сменить уровень RAID если достаточно места и устройств для новых требований. А при обломе конверсии на середине еще и нормально относится к смеси уровней. Просто продолжает с места облома. Можно даже не делать конверсию а просто запросить чтобы от сих новые блоки писали с другой схемой. Старые останутся с предыдущей и будут в таком виде пока кто-то не перезапишет это по какой-то причине.

Все что при вон том важно (для примера RAID1) - чтобы было 2 хоть какие-то устройства и свободное место на них. Добавление +1 устройства очевидно позволяет использовать и его место для тех целей, с уточнением что на других должно быть какое-то свободное место. Иначе в какой-то момент место на этом девайсе будет, но куда определять вторую копию блока?! Поэтому после добавления устройства нехило сделать и ребаланс для более равномерного использования устройств, но это не есть абсолютное требование для того чтобы оно работать начало.

> а в fstab-е автоматически добавится или командами subvolum придется
> прописывать для постоянного добавления нового раздела?...

Btrfs после попытки монтирования куска ФС сам остальные девайсы попробует найти.

> Как проще сделать конвертацию раздела /home с фс ext4,

Честно говоря не понимаю смысл в разделах когда хочется рулить пространством глобально и удобно, они только мешают этому - в btrfs нет причин делать home и os разными разделами.Просто скопировать хомяка, лучше в отдельный subvolume, и нахрен разделы, отдать место btrfs'у. Если раздел /home был опосля / то / реально увеличить в хвост и отдать место btrfs'у потом, но перетряс разделов довольно опасная операция, бэкапы ценного и таблиц разделов мастхэв. После отращивания раздела btrfs потом можно увеличить на добавочное место. Вот что-что а убавить или скостить размер ФС в нем легко.

Лично мне нравится как убунта btrfs раскладывает: раздел 1 на все, однако в ФС есть subvolume @ для / и @home для /home. Настоящий корень иерархии btrfs в не монтируется, вместо этого делают как-то типа (это fstab):

LABEL=system  /               btrfs   defaults,noatime,subvol=@     0       1
LABEL=system  /home           btrfs   defaults,noatime,subvol=@home 0       2

Можно UUID= (нужной фс) с тем же эффектом. Сие подразумевает ФС с лэйблом system и что на ней в топе иерархии есть subvolume'ы @ и @home. Место делится на обоих, а снапшотить "ос" и "хомяк" можно независимо.

Настоящая иерархия с @ и @home окажется на уровень выше / и когда хочется снапшот делать, логично временно замаунтить без subvol= уже и вот там их раскладывать. Чтобы это вообще не влияло на нормальный вид ос.

Subvolube в btrfs это нечто типа более мощной версии директории, разные subvolume можно снапшотить независимо друг от друга. Поэтому откат снапшота сводится к по сути операциям с "директориями". Если был @snapshot1 и @ и в @snapshot1 была система, нечто типа mv @ @old; mv @snapshot1 @ - и после этого ребут, приведет к перезагрузке в систему из @snapshot1. Можно поубивать ненужные снапшоты. Просто rm или миднайтом уже в современных кернелах. А весь пойнт - снапшот изначально реюзает блоки оригинала и поэтому хотя ведет себя как отдельная дира с копией ОС, места занимает мало (только отличия состояний).

> если добавить также как к корню (он-то уже на btrfs) новый раздел с нового устройства,
> но так, чтобы "главным" оказался именно старый раздел /home?

Там не интересно кто главный, если сделать как убунта придумала, цепляя с явным указанием subvolume. Топ иерархии при этом перестанет быть виден в системе и станет уровнем выше / - это теперь уровень менеджмента, можно версиями систем и хомяков рулить. Включая текущий. Ну типа как в виртуалке где есть гипервозор, у него свои понятия относительно снапшотов, можно вернуться на какой-то из них и все будет в виде как на момент снапшота.

> sda1  ext4      1.0    
> 1,5G    44%  /boot
> sda2  btrfs          
>   50,9G    57% /
> sda3  ext4      1.0    
> 18,4G    76% /home

Я бы в топе btrfs сделал @ под систему и удвинул систему туда. Потом @home и мувнул home туда, потом прописал вон то. А, если @ и @home не нравятся: это лишь дефолтовые убунтуйские названия, поскольку я спер идею у них то и названия взял как там было. Но названия любые могут быть, главное не запутаться что есть что - на вид в файловом менеджере дира и subvolume ничем особо не отличаются.

А потом если не сыкотно - снести sda3, отрастить sda2 до конца, и его место будет доступно "btrfs вообше" которого можно будет ресайзнуть по размеру. Его динамически поделят между собой и @ и @home. Редактирование разделов требует аккуратного исполнения т.к. технически при этом sda2 на время удаляется но тут же создается с тем же началом (важно!), но размером уже крупнее. Я так делал, работает, но требует аккуратности. Ну и бэкапы при желании такое провернуть мастхэв, особенно таблиц разделов - в файлик на отдельном накопителе, на случай если номер не получился и захочется вернуть как было.

На самом деле проще всего посмотреть как нечто типа убунты себя на btrfs ставит, и потом спереть идею если хотелось не убунту.