Hi all, I am switching from a MacBook Pro to a Framework 16 and plan to install Fedors43 KDE Plasma as my primary driver. I am familiar with Linux, but am unsure about the BTRFS partitioning. My laptop will come with a 2TB SN850X NVMe (primary) and a 2TB SN770M NVMe (secondary).
I have no intention to use Windows. My main-use will be development (Java and other languages), productivity. The secondary drive I want to use as a playground (distro hopping) but also as a backup device (in addition I wll backup to a Synology).
Do I need to manually partition the 2TB SN850X NVMe or will Fedora43 take care of it? I initially think of partitioning like this, but would like your opinion / suggestions:
I’ve done many similar configurations for development/productivity use cases. I have always focused on installing to the primary drive, then configuring the secondary drive. There are more risks when you depart from the default configuration process, the Live USB environment is slower and lacks some tools you may want, and I usually need to have the system running quickly.
You may not want dedicated swap unless you need hybernation — most of my development work involved batch processing workflows with testing that ran for hours, even days, on 2010 hardware so systems were never idle.
1GB ext4: /boot
=> about 500MB used on my all AMD setups, with three kernels. My systems were all installed with F42 or F41, but there was an issue with firmware files increasing the size of the initramfs files recently, which caused the default size to be increased to 2GB.
A single LUKS+btrfs partition, with subvolumes for / and /home
=> I never liked having to determine how large my / could get beforehand. Subvolumes on a single large btrfs volume let me dynamically share the space between them without the anxiety of one filling up too soon and having to re-allocate space.
I haven’t used swap space for a long time. For me, using up all RAM and having the system rely on swap is a last resort and I would much rather find out what is using all the RAM and return the system to normal operation. Swap on ZRAM is sufficient for me for that purpose. But it also helps that my machines usually have quite a bit more RAM than I need day to day, which might not be a great idea with current DRAM prices.
I described my partition setup, how much space is used on /boot with my all-AMD systems, and I mentioned that the new default for /boot is 2GB. I wasn’t recommending 1GB, sorry if I didn’t make that clear.
Though, depending on what (if any) GPU @magicdude4eva is going to use in the Framework 16, the additional space for Nvidia firmware in the initramfs may not be needed and the 2GB may end up mostly empty.
This is OK. We could go around in circles about the future if you need such a large EFI System partition, but it doesn’t hurt.
I personally wouldn’t separate these things (separate partitions, separate file systems). I would use the remainder for all three, and then you won’t run into the problem of having undersized root or swap partitions.
If you use the default installation partitioning, you will get a single Btrfs, with /root and /home on subvolumes named root and home. You can mount the top-level of the Btrfs post-installation, and you’ll see what appears to be two directories, root and home, in that top-level mount. They’re actually subvolumes. You can create another subvolume, e.g. swap, and then run chattr +C on it to make sure everything created in it is nodatacow. Like swapfiles.
You can then update your /etc/fstab and specify subvol=swap gets mounted to /var/swap (this is what I do, so I know it works, I haven’t tried /swap but I see no reason why it would be a problem).
That way if I snapshot the root subvolume, it doesn’t snapshot anything of the other subvolumes. I split out /var/tmp so it does use relatime for systemd tmpfiles cleanup which is based on atime. Log files I don’t care to snapshot or restore if I do a rollback for some reason. Swap for libvirt images, and flatpaks. Also FWIW, snapshot and send-receive of flatpaks can be used to replicate a pile of flatpaks to other systems.
I do also have some nested subvolumes in the user directory to separately handle their replication for backup reasons. The one nested subvolume I’ll mention, in case you want to avoid snapshot and backing it up is ~/.cache
I don’t keep a separate subvolume for Trash because as it turns out this results in a move that is expanded into a copy + delete original. That’s because subvolumes have their own fd’s, their own inode pools, and are separate (file) b-trees - so it’s up to the DE whether the copy will be made efficient using reflink. So it still might be valid but would take some testing to make sure the behavior is optimal.
Uhhh yeah this might be possible point of confusion. So the / line in /etc/fstab is unique in that it applies to a remount. By default in Fedora the root file system is mounted ro, and then later at switchroot, it is remounted rw. And it is the fstab options for / that are used for that remount. And it is allowed to add or subtract compression during remount.
Compression mount option on Btrfs is file system wide. It looks like it’s per subvolume the way anaconda adds the compression option on each subvolume’s mount point line in fstab. But it’s really a noop. There is no harm leaving them alone. I just removed them because I’m easily distracted.
The omission of compression options for additional mounts does not undo the compression option, because these additional mounts are not remounts. But they are pretty much bind mounts. And therefore you can have different VFS options, and things like rw, ro, and atime options are VFS options, not Btrfs specific.
For what it’s worth, I rarely need to use btrfs snapshots for rollback system issues. Those issues are sufficiently rare that I’d have to imagine scenarios and categories for them.
It’s worth checking out dnf history and dnf history rollback mainly because this is a universal approach regardless of file system and layout.
Another consideration for booting read-only snapshots to contend with the inability to write is adding a volatile overlay, e.g. add systemd.volatile=overlay This will use memory as the writeable layer, and overlayfs as the mechanism. I find that the process that insists on writing, or else misbehavior, is going to change over time. And those writes are invariably not that important for troubleshooting, so clobbering this with a disposable overlay is a tidy work around for that, that also meets a best practices for troubleshooting of “limits writes as much as possible until fully understanding the problem”.
I have also found fstab=no useful as a medium sized hammer for making sure I can boot just the root file system (with writeable overlay), because it reduces the complexity of assembling the system. Yes, the ensuing desktop functionality is reduced, but the major gain is to not have to do the troubleshooting from a dracut shell.
The carve outs I’ve made with subvolumes are merely optimizations, they’re not requirements by any means.
Uhhh yeah this might be possible point of confusion. So the