Ext4 vs. Btrfs performance on Qubes OS installs

Hmmm.
From top of my head, I thought it was two distincts drives. If you pass /dev/sda2 /dev/sda3 to disk unlock setup, this means you have two distinct LUKS partition passed, not sure that would be LVM.

Can you do me a favor and:

[user@dom0 ~]$ sudo pvs
  PV                                                    VG         Fmt  Attr PSize   PFree  
  /dev/mapper/luks-a4ba89e4-65a3-48f9-a045-d128c2a422cc qubes_dom0 lvm2 a--  464.74g <12.63g
[user@dom0 ~]$ sudo vgs
  VG         #PV #LV #SN Attr   VSize   VFree  
  qubes_dom0   1 207   0 wz--n- 464.74g <12.63g

Heads only cares about /boot (/dev/sda1 normally) and knowing which drives to add a LUKS additional keyslot (/dev/sda2 /dev/sda3) but doesn’t play with the content of those LUKS partition. As of today, even LVMs cannot be played with under Heads since thin-LVMs were not supported until now (under PR still, not merged because firmware space constraints)

So that is not answering if lvm+brtfs, but from my understanding, brtfs is not on top of LVM, but use brtfs to deal with snapshots, reverts etc.

I am interested because brtfs is reported to be faster, where lvm is known to be stucked to 512b sectors under that thread, where a PR was reated for Qubes OS to abstract that https://forum.qubes-os.org/t/ssd-maximal-performance-native-sector-size-partition-alignment

Highly doubt BRTFS is on top of LVMs, even less thin-LVMs as per your screenshot.

(EDIT: With LVM/Thin-LVM setup (default), this is one big fat LUKS container and different LVM pools under, not two LUKS partitions.)

1 Like