#3639 PR open: Support a Btrfs filesystem created on top of multiple block devices¶
Labels: enhancement
svlv opened issue at 2026-09-16 12:12:¶
Pull Request Details:¶
-
Type: Enhancement
-
Impact: High
-
Reference to related issue (URL):
-
How was this pull request tested?
Changes were tested on Proxmox VE by backing up and restore VMs. The following configurations have been successfully backed up and recovered:
- Fedora Workstation 44 with Btrfs filesystem created on top of 3 partitions:
root@fedora44:~# lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1 vfat FAT32 06BA-FFB7 578.8M 3% /boot/efi
├─sda2 ext4 1.0 f03a1ce9-0503-45b7-b391-8015d6bc23c4 1.4G 18% /boot
└─sda3 btrfs fedora 888a6d32-dae2-47c2-9b5b-a3f7d6b06666 20.2G 29% /home
/
sdb
└─sdb1 btrfs fedora 888a6d32-dae2-47c2-9b5b-a3f7d6b06666
sdc
└─sdc1 btrfs fedora 888a6d32-dae2-47c2-9b5b-a3f7d6b06666
root@fedora44:~# btrfs filesystem show /
Label: 'fedora' uuid: 888a6d32-dae2-47c2-9b5b-a3f7d6b06666
Total devices 3 FS bytes used 8.41GiB
devid 1 size 5.41GiB used 8.00MiB path /dev/sda3
devid 2 size 8.00GiB used 1.51GiB path /dev/sdb1
devid 3 size 16.00GiB used 10.51GiB path /dev/sdc1
- openSUSE Leap 16.1 with different combinations of data and metadata profiles
leap16:~ # lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1 vfat FAT32 AD5D-2D30 504.5M 1% /boot/efi
├─sda2 btrfs sles16 f8abe312-ae4f-4115-8a8e-3603bba79604 11.1G 61% /var
│ /usr/local
│ /srv
│ /opt
│ /root
│ /home
│ /boot/grub2/x86_64-efi
│ /boot/grub2/i386-pc
│ /.snapshots
│ /
└─sda3 swap 1 cc512737-9cb1-4dfd-88a5-301572587ba7 [SWAP]
sdb
├─sdb1 btrfs sles16 f8abe312-ae4f-4115-8a8e-3603bba79604
├─sdb2 btrfs 13c94e66-6d78-4b81-b488-6bf6f5056f0c 1015M 0% /btrfs/raid1-mixed
├─sdb3 btrfs 13c94e66-6d78-4b81-b488-6bf6f5056f0c
├─sdb4 btrfs 0e7b889f-9b52-4af7-90bd-fe5dbedb84a5 759M 1% /btrfs/raid1c4
├─sdb5 btrfs 0e7b889f-9b52-4af7-90bd-fe5dbedb84a5
├─sdb6 btrfs 0e7b889f-9b52-4af7-90bd-fe5dbedb84a5
├─sdb7 btrfs 0e7b889f-9b52-4af7-90bd-fe5dbedb84a5
├─sdb8 btrfs 723c549a-fb38-4723-8dd8-f405b54e5ab5 759M 0% /btrfs/raid6+raid1c3
├─sdb9 btrfs 723c549a-fb38-4723-8dd8-f405b54e5ab5
├─sdb10 btrfs 723c549a-fb38-4723-8dd8-f405b54e5ab5
├─sdb11 btrfs 1d77cd00-91ce-48d8-9040-5df9b9ea3ec2 904.6M 1% /btrfs/single+dup
└─sdb12 btrfs 7a389820-3eee-477c-bb5f-ac88893bb508 504.5M 1% /btrfs/dup+single
# Eg, RAID6 is used for data and RAID1C3 for metadata
leap16:~ # btrfs filesystem df /btrfs/raid6+raid1c3
Data, RAID6: total=102.38MiB, used=0.00B
System, RAID1C3: total=8.00MiB, used=16.00KiB
Metadata, RAID1C3: total=256.00MiB, used=128.00KiB
GlobalReserve, single: total=5.50MiB, used=0.00B
-
Description of the changes in this pull request:
A list of device paths (
devices=<btrfs device path>), data profile (dprofile=<btrfs data profile>), and metadata profile (mprofile=<btrfs metadata profile>) are added todisklayout.conf. Filesystem dependencies are set for all devices in the group. This takes advantage of the fact that, to mount a Btrfs filesystem spanning multiple devices, any device from the group can be used
(long line shown wrapped here):
fs /dev/sda3 / btrfs
uuid=888a6d32-dae2-47c2-9b5b-a3f7d6b06666
label='fedora'
nodesize=16384
sectorsize=4096
features=block-group-tree,extref,free-space-tree,no-holes,skinny-metadata
devices=/dev/sda3,/dev/sdb1,/dev/sdc1
dprofile=single
mprofile=raid1
options=rw,relatime,compress=zstd:1,discard=async,space_cache=v2,subvolid=256,subvol=/root
codacy-production commented at 2026-09-16 12:13:¶
Up to standards ✅¶
🟢 Issues 0 issues
> > > **Results:** > `0` new issues > > [View in > Codacy](https://app.codacy.com/gh/rear/rear/pull-requests/3639/issues) >
NEW Get contextual insights on your PRs based on Codacy's
metrics, along with PR and Jira context, without leaving GitHub. Enable
AI
reviewer
TIP This summary will be updated as you push new changes.
jsmeix commented at 2026-09-16 12:36:¶
WOW!
svlv commented at 2026-09-17 14:16:¶
JFYI: I am planning to push some additional commits tomorrow with a few improvements.
svlv commented at 2026-09-18 13:08:¶
The following improvements that have been pushed are worth mentioning:
- Wipe all devices in a group. Previously only the mounted device was wiped.
- Handle cases where there are several profile directories in sysfs. This happens during a balance operation or if the operation is aborted. The Balance doc page.
jsmeix commented at 2026-09-18 13:15:¶
@svlv
could you explain why you need to introduce
the get_cleanup_command() function?
At first glance I fail to see the reason why
so currently it looks to me as if it was
an RFC 1925 item 6a implementation ;-)
svlv commented at 2026-09-18 13:24:¶
@jsmeix
could you explain why you need to introduce
the get_cleanup_command() function?
I need the underlying command to be parameterized with the device
path.
I was thinking about keeping the string and replacing the device keyword
with a parameter (something like ${cleanup_command//device/$device}).
But I finally decided to use a function to handle this parameterization.
Please let me know if there is a better or more preferable way to achieve this.
[Export of Github issue for rear/rear.]