First try with BTRFS, questions

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:

# <file system>                           <mount point>  <type>  <options>                                                            <dump>  <pass>
UUID=B58D-7F65                             /boot/efi      vfat    umask=0077                                                           0       2
UUID=22481939-43dd-47ea-9d8d-75ccd93af57b  /boot          ext4    defaults,noatime                                                     0       2
UUID=2c9558ee-53c5-402c-8b32-9ed387652595  /              btrfs   subvol=/@,defaults,noatime,space_cache,autodefrag,compress=lzo       0       1
UUID=2c9558ee-53c5-402c-8b32-9ed387652595  /home          btrfs   subvol=/@home,defaults,noatime,space_cache,autodefrag,compress=lzo   0       2
UUID=2c9558ee-53c5-402c-8b32-9ed387652595  /var/cache     btrfs   subvol=/@cache,defaults,noatime,space_cache,autodefrag,compress=lzo  0       2
UUID=2c9558ee-53c5-402c-8b32-9ed387652595  /var/log       btrfs   subvol=/@log,defaults,noatime,space_cache,autodefrag,compress=lzo    0       2
UUID=a49f5eec-82c0-4d3b-a3e8-1b7d3e772941   none          swap    defaults,noatime                                                     0       0
UUID=76c9bf53-88a4-4d70-8949-b23a590140a8  /media/data    ext4    defaults,noatime                                                     0       2
tmpfs                                      /tmp           tmpfs   defaults,noatime,mode=1777                                           0       0

And another question:
What to do to see the snapshots in the boot menu (made with timeshift)? Is it enough to install grub-btrfs?

I usually remove that option on an SSD.

After installing grub-btrfs, you should also override grub-btrfs.path by placing a copy of it in /etc/systemd/system

It should look something like this:

[Unit]
Description=Monitors for new snapshots
DefaultDependencies=no

[Path]
PathModified=/run/timeshift/backup/timeshift-btrfs/snapshots

[Install]
WantedBy=multi-user.target

Then enable it with

sudo systemctl enable --now grub-btrfs.path

That will make it so grub-mkconfig is run whenever timeshift takes a snapshot.

2 Likes

thanks @dalto :+1:t2:

1 Like

There isn’t an authoritative “do this” answer, at least I haven’t found one. From the horse’s mouth:

https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation

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.

4 Likes

@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:

[Unit]
Description=Monitors for new timeshift snapshots
DefaultDependencies=no
Requires=run-timeshift-backup.mount
After=run-timeshift-backup.mount
BindsTo=run-timeshift-backup.mount

[Path]
PathModified=/run/timeshift/backup/timeshift-btrfs/snapshots

[Install]
WantedBy=run-timeshift-backup.mount

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.

It can and it will work fine. However, since it is tied to run-timeshift-backup.mount which doesn’t exist at boot time you will likely get some harmless warnings in your logs.

OK, how do I modify it so it doesn’t stay tied to Timeshift?

That is literally what I did above. I started with that file and removed those references and then tied it to the multi-user.target because it has to be tied to something.

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.

Because that will basically mean you will be permanently off your snapshot which is probably not what you want.

Off the top of my head, there are some easy workarounds:

  • You could disable and stop that path unit whenever you boot off a snapshot.
  • You could unmount /boot when you boot off of a snapshot

A more permanent solution might be to override grub-btrfs.service so that it checks to see if you are booted off a snapshot before running grub-mkconfig

1 Like

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 :frowning: I started to like it.

It isn’t really a problem. The “problem” is really caused by grub not expecting someone to be booted into a root that isn’t the real root.

1 Like

OK, thanks

If you want, I can write that service override for you.

Oh, that would be a great help to me.

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

[Unit]
Description=Regenerate grub-btrfs.cfg

[Service]
Type=oneshot
# Set the possible paths for `grub-mkconfig`
Environment="PATH=/sbin:/bin:/usr/sbin:/usr/bin"
# Load environment variables from the configuration
EnvironmentFile=/etc/default/grub-btrfs/config
# 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'

Then either reboot or do this:

sudo systemctl daemon-reload
4 Likes

That’s it! Booting from a snapshot from the grub works without error message. Thanks for your effort! :beers:

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.