During install how do I setup a BTRFS over two nvme? I can select two dev in lvm but btrfs has no option to select more than one device.
It’s dangerous. If one of the two drives fails, all data is gone.
I am not familiar with the options of btrfs as I am not using it, but you can certainly create LVM volumes (which you do anyway should you select Encryption) and have the volume group (VG) span over two drives. Btrfs doesn’t even see them as two drives then, but as a single volume.
This would work, but I advise against it.
RAID 1 is redundant storage which allows for any number of devices where all but one can fail. It is very safe in that way.
So, you don’t want to span your pool over two drives (“stripe”) but mirror the two drives (“RAID1”)?
Sorry for misunderstanding your initial post.
install on a single btrfs drive and add the 2nd device later with btrfs command converting to a RAID1 setup.
Oh and you don’t really need LVM when handling btrfs devices.
4.2 MB for /boot?
3 Likes
ok it needed a bit of prep before anaconda partition editor was able to make sense of my aim but here we are
# lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1 vfat FAT32 EFI 9D76-93D5 579.5M 3% /boot/efi
├─sda2 ext4 1.0 8c189042-dd69-4ced-ada6-50edaf4b2d5c 1.3G 24% /boot
└─sda3 ext4 1.0 @root 5507e127-d8d0-4d9c-9740-9a3895c400cc 81.8G 23% /
sdb
├─sdb1 exfat 1.0 Ventoy 4E21-0000
└─sdb2 vfat FAT16 VTOYEFI 3105-B091
sdc vfat FAT32 USB4 2408-59E0
zram0 swap 1 zram0 943163d7-0b5e-4870-b23a-c5b2702ef08d [SWAP]
nvme0n1 btrfs 9824f397-8933-4c17-94fe-512528631323
nvme1n1 btrfs 9824f397-8933-4c17-94fe-512528631323 456.9G 4% /var/log
/opt
/var/cache
/var/lib/libvirt
/var/tmp
/home
and it seems to do raid
# btrfs fil df /home
Data, RAID1: total=21.00GiB, used=18.96GiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=1.00GiB, used=44.47MiB
GlobalReserve, single: total=21.77MiB, used=0.00B
and there is quite some room
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 114G 26G 82G 24% /
devtmpfs 7.8G 0 7.8G 0% /dev
tmpfs 7.8G 41M 7.8G 1% /dev/shm
efivarfs 128K 83K 41K 67% /sys/firmware/efi/efivars
tmpfs 3.2G 2.1M 3.2G 1% /run
tmpfs 1.0M 0 1.0M 0% /run/credentials/systemd-journald.service
/dev/sda2 2.0G 469M 1.4G 26% /boot
tmpfs 7.8G 2.9M 7.8G 1% /tmp
/dev/nvme1n1 477G 20G 457G 4% /home
/dev/nvme1n1 477G 20G 457G 4% /var/tmp
/dev/nvme1n1 477G 20G 457G 4% /var/lib/libvirt
/dev/nvme1n1 477G 20G 457G 4% /var/cache
/dev/nvme1n1 477G 20G 457G 4% /opt
/dev/nvme1n1 477G 20G 457G 4% /var/log
/dev/sda1 599M 20M 580M 4% /boot/efi
tmpfs 1.0M 0 1.0M 0% /run/credentials/systemd-resolved.service
tmpfs 1.6G 208K 1.6G 1% /run/user/1000
tmpfs 1.6G 160K 1.6G 1% /run/user/0
What is totally confusing is that anaconda at some point claims to have a 1TB device which would imply RAID0. Not what I want.
have you tried with iso netinstall and blivet-gui?
No, should I. What is blivet-gui’?
Btw really silly. I made quite a few captured instals but while cleaning up deleted the ones where anaconda failed.
this one worked 2025-11-30 14-38-22Fedora Budgie Anaconda error
and I filed a bugreports agains buzilla.redhat.com 2412715 – WebUI: TypeError: Cannot read properties of undefined (reading 'v')
This is your btrfs volume and 477G are available across ALL subvolumes.
try sudo btrfs fi usage /home, this should show both btrfs devices.
I don’t quite undestand the decision to use ext4 for / but otherwise this looks ok.
I’ve always had trouble with WebUI Anaconda. Blivet-gui is the interface present in Fedora 41 ws and earlier. I’ve always preferred Blivet-gui.
the reason is that I believe, perhaps wrongly, ext4 more robust.
e2fsck is amazing - it can fix quite a bit of damage. There’s a long history of ext[234]. And its metadata has fixed location so it’s possible to make many assumptions about what should be in missing or corrupt locations.
Btrfs has a harder time with repairs if something bad goes wrong. It’s not amazingly good or bad.
Btrfs is more sensitive if the drive doesn’t honor FLUSH or FUA, which are used to make sure data and metadata writes are on stable media before updating the super blocks. If those commands are ignored and there’s a crash, then the file system can be pretty badly screwed up. I’ve had some success with manual repair (using flags to point to specific trees that look like good candidates - determining that is itself a manual process) but it’s not certain and pretty tedious.
If the drive honors flush or fua, OR if there’s never a crash or power fail or forced power off - then Btrfs is as robust as ext4 or XFS. But with the added data integrity since all data blocks are checksummed, and verified on every read. In normal operation, corrupt data never makes it to user space. In that sense Btrfs can be fussier. ext4 and XFS have no way of knowing if data blocks are corrupt.
As for the installer, with the gtk-ui it was true that selecting multiple devices for installation would result in concatination whether LVM or Btrfs, because the mkfs.btrfs default is raid1 profile for metadata and single profile for data - creating a single large pool from two or more devices. The same happens with LVM except there isn’t duplicate filesystem metadata.
If this is not happening with web-ui then that might be a bug. It’s certainly a feature regression if confirmed.