I’m redoing my home server. I’m moving from arch to fedora server to force myself to learn that stuff.

I also want to use the bcachefs subvolume and compression features. I am presented with a couple issues I need smarter people to explain to me though.

subvolumes: My understanding is subvolumes in bcachefs dont get mounted separately like you would expect. they are just folders that you can isolate a snapshot to. so I dont need to mount a subvolume, just mount the filesystem it exists in already and it comes along for the ride. but what happens if I want to rollback? Lets say I want to rollback to a previous snapshot on the / but not mess with anything in the subvolume /home/thatuser. wouldn’t rolling back to the previous root also rollback the subvolumes contained within? perhaps I should create a separate partition just for root afterall.

mount: I can mount with

mount -t bcachefs /dev/device1:/dev/device2:/dev/device3

and everything works. However, if I mount with

mount -t bcachefs UUID=(externalUUIDfromshow-super)

not all devices in the pool will attach. some stay detached. so how am I supposed to mount them all at boot? I can’t just refer to them by device path because if I add more drives later, those paths may change.

compression: the documentation is kind of out-of-sync on different sites but what I was able to piece together is you can set different rules for compression recursively for different directories/subvolumes like this…

sudo bcachefs set-file-option /mnt/tempy/ --compression=zstd:3 --background_compression=zstd:12

then read back what was already set with…

getfattr -d -m 'bcachefs_effective\.' /mnt/tempy

so while the above makes sense for a root or user home folder, for VM disk images, I might want to set…

sudo bcachefs set-file-option /mnt/tempy/vmstorage/ --compression=none --background_compression=none --nocow

or even do something similar without the nocow for media folders within the compressed home user folder…

sudo bcachefs set-file-option /mnt/tempy/home/thatuser --compression=zstd:3 --background_compression=zstd:12
sudo bcachefs set-file-option /mnt/tempy/home/thatuser/media --compression=none --background_compression=none

mount at boot: okay, I know I need the DKMS and userspace tools installed as separate packages since Kent was naughty and got his project booted out of the kernel. but I’m not entirely certain how to convey to fedora it needs to bundle those pieces with the initiramfs. I know arch uses something different from fedora to do that, with fedora using dracut. I need to learn how to use dracut.

install: this I have no idea what to do. Fedora’s anaconda expects something very different and will not eat what I’m trying to feed it. so I need to find a way to bootstrap a fedora server install on to this system. Supposedly theres a way to do that with DNF.

Anyway, could someone explain the subvolume puzzle to me and maybe give pointers on bootstrapping fedora server and teaching it to mount all the devices in the pool at boot?

  • Ghoelian@piefed.social
    link
    fedilink
    English
    arrow-up
    2
    ·
    2 days ago

    So why is btrfs bad? Is it just because oracle bad or is there an actual reason?

    Afaik btrfs was developed by a person at oracle, but not for or by oracle.

    • muusemuuse@sh.itjust.worksOP
      link
      fedilink
      English
      arrow-up
      3
      arrow-down
      1
      ·
      edit-2
      2 days ago

      They have performance issues as snapshots accumulate. Snapshots don’t fork predictably (filesystem devs expect one thing, sysadmins expect another.) RAID write holes still exist in configurations they dismiss as “exotic.” Use of oracle tech normalizes using their stuff in a community that knows better. Btrfs development has pretty much stagnated as there have been some optimizations but few long standing issues have actually been addressed. Btrfs has been pulled right out of distros that praised it before too. While that’s not as dramatic as Kent getting his ass yeeted from the kernel it’s still pretty high up there. Btrfs has made data vanish permanently in the past. Bcachefs has a reputation of hiding it from you until you coax it back out. It’s never really gone, it’s just inaccessible until a bug is fixed. And it always got fixed.

      The problem isn’t the filesystem. It’s the developer. It’s not enough that he’s right. He has to cooperate with others who are also right to be in the kernel and he just won’t do it. So now he is outside the kernel. The project will carry on but it’s going to be niche.