I installed EOS with btrfs for the first time last night (separate partition for /boot in ext4). After mounting my data disk and editing the /etc/fstab I noticed the autodefrag options for the subvolumes. Isn’t that rather destructive on an SSD? I only ask because it was always said that an SSD should not be defragmented because of the limited write cycles. Here is my fstab:
There isn’t a classic fragmentation penalty caused by moving the head on SSDs. On the other hand BTRFS’ internals may require more processing overhead to process very fragmented files.
Personally I leave in on on a “normal” desktop system. If you don’t buy bottom of the barrel SSDs the overprovisioning should be more than enough. Doing some napkin math (bytes written, manufacturer specs) on my currently three year old SSD exclusively run on btrfs it calculates to 18 years MTTF. Good enough.
@dalto: Update: I finally found the time to follow your instructions. grub-btrfs installed and enabled via systemctl. After that grub.btrfs.path in /etc/systemd/system/ looked like this without any further change from me:
Description=Monitors for new timeshift snapshots
Since it worked as desired after reboot and the EndeavourOS snapshots were displayed in the grub, I didn’t change anything either. What do you think, can grub.btrfs.path stay like this? Please excuse my questions and cautious approach.
BTW…there is a potential issue you should be aware of with this setup.
Because you have a separate /boot when you boot off a snapshot, if you take a snapshot in that situation, it will cause grub-mkconfig to run and it will probably be successful because /boot is writable.
This will cause it to update your kernel command line to reference the snapshot instead of your real root.
I only begin to understand the connection. Why is there a problem with not referencing the root directory and how can I set this up or work around it better? I can not do without the separate /boot, because it MUST remain writable.
I can see this separate /boot partition is doing more harm than good. That’s probably why it is not created during the automatic partitioning. What would be the alternative for me? Without separate /boot I could not use GRUB_SAVEDEFAULT=true and would have to manually select the older LTS kernel every time I boot. I can’t believe this is supposed to be the normal case. If so, I’d rather stay away from btrfs for now. What do other users do if they do not want to boot permanently with the mainline kernel? This shows me that btrfs is far from mature I started to like it.
I don’t have a machine with timeshift and grub-btrfs so you should test this.
Just save this file as /etc/systemd/system/grub-btrfs.service
# Set the possible paths for `grub-mkconfig`
# Load environment variables from the configuration
# Regenerate just '/boot/grub/grub-btrfs.cfg' if it exists and is not empty, else regenerate the whole grub menu
ExecStart=bash -c 'findmnt -nlo options / | grep -v timeshift-btrfs && grub-mkconfig -o /boot/grub/grub.cfg'