New iSO BTRFS newbie here

Hello EOS team, thanks very much for this new ISO, decided to give it a try but now using BTRFS.
This is my first time using this filesystem (I have a NAS that uses it, but everything was installed automatically, so I’m still pretty new to it).

I have a few questions
1 - Do I need to install fstrim?
2 - Are the snapshots created automatically or I should do something to create it
3- Is there an app or something to manage the snapshots, like create a snapshot or restore from it, maybe navigate through the files?
4- Anything I should do to optimize or to avoid problems ?

How my fstab is right now, using XFCE version, online install, manual partitioning.

UUID=3F6E-428A                            /boot/efi      vfat    umask=0077 0 2
UUID=54471866-fe87-4ed9-897d-9032d888dcc3 /              btrfs   subvol=/@,defaults,noatime,space_cache,autodefrag,compress=lzo 0 1
UUID=54471866-fe87-4ed9-897d-9032d888dcc3 /home          btrfs   subvol=/@home,defaults,noatime,space_cache,autodefrag,compress=lzo 0 2
UUID=54471866-fe87-4ed9-897d-9032d888dcc3 /var/cache     btrfs   subvol=/@cache,defaults,noatime,space_cache,autodefrag,compress=lzo 0 2
UUID=54471866-fe87-4ed9-897d-9032d888dcc3 /var/log       btrfs   subvol=/@log,defaults,noatime,space_cache,autodefrag,compress=lzo 0 2
UUID=0bcda331-2ec8-46d1-b6dc-afafcc0c79b3 swap           swap    defaults,noatime 0 0
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0
#manual entries
UUID=e60ff1d0-35a4-47d3-b722-5bd1409ab0ce /run/media/marcelo/ext4 ext4 nodev,nosuid,noexec,rw,auto,nouser,async,noatime 0 2

Hello @mcury
You can use snapper and set it up to take snapshots. I’m not an expert on the subject but i do have it set up on a couple of mine recently. I use to have btrfs using timeshift and snapshots which i’m sure you can do also. I originally set mine up with the quick copy & paste method on the wiki by @2000. I wanted to try something different now so snapper was easy to set up once i wrapped my head around how different aspects of it work. @pebcak has done a lot with it also. Probably more than i have. Both @dalto & @pebcak helped me a lot gain some understanding. I probably have mine set up differently also as i am using snap-pac.

1 Like

You could do either of the following two things:

There are two ways how to apply the discard:

-o discard during normal operation on any space that’s going to be freed, enabled by mount option discard

on demand via the command fstrim 

-o discard can have some negative consequences on performance on some SSDs or at least whether it adds worthwhile performance is up for debate depending on who you ask, and makes undeletion/recovery near impossible while being a security problem if you use dm-crypt underneath (see ), therefore it is not enabled by default. You are welcome to run your own benchmarks and post them here, with the caveat that they’ll be very SSD firmware specific.



A Btrfs filesystem is able to free unused blocks from an SSD drive supporting the TRIM command. Starting with kernel version 5.6 there is asynchronous discard support, enabled with mount option discard=async. Freed extents are not discarded immediately, but grouped together and trimmed later by a separate worker thread, improving commit latency.

I have discard=async in mount options for the subvolumes in /etc/fstab.

Edit: corrected the link to BTRFS Wiki

1 Like

Thanks @ricklinux, installed snapper and I’m already reading the manpage about it.
It’s not going to be easy as it was when I was using timeshift hehe :slight_smile:

Thanks @pebcak, the fstrim command is an option that I used to have when I was using EXT4, so I’ll probably stick to it, not using any disk-crypt, I’ll just install fstrim and enable it according to the EOS wiki page. It seems that this discard=async works like the discard option in fstab for EXT4 filesytems

With the EnOS’ installer’s setup of the BTRFS subvolumes, you could use Timeshift as well to snapshot the root suvolume @. You could then install grub-btrfs to have them added to your Grub boot option to choose from, in case you would need to rollback your system.


Either timeshift or snapper are the biggest options. timeshift is both very simple and very limited. snapper is much more feature-rich and also more complicated

Alternatively you can take snapshots manually with the btrfs command.

I use snapper personally.


grub-btrfs would be nice to have indeed, just boot to a previous snapshot… I’ll definitely take a look at it too =) thanks

Thanks everyone, already learning how to accomplish it
I should probably be learning this in a VM environment, but now that is too late, but I have old backups here that I can restore if my BTRFS adventure fails hehe



Is btrfs stable enough and recommended to use ?

I heard that is slower than ext4. Atm I am on ext4 but curious about btrfs, only because of backups :slight_smile:

It’s not a seven headed monster it seems…

1 - sudo snapper -c root create-config /
2 - sudo systemctl enable snapper-timeline.timer
3 - sudo systemctl start snapper-timeline.timer
4 - sudo systemctl enable snapper-cleanup.timer
5 - sudo systemctl start snapper-cleanup.timer
6 - sudo snapper -c home create-config /home
7 - sudo snapper -c log create-config /var/log
8 - sudo snapper -c cache create-config /var/cache

Access for non-root users:
sudo nano /etc/snapper/configs/config
chmod a+rx .snapshots/
chown :users .snapshots

sudo nano /etc/snapper/configs/root
change the snapshot limits if you want, running defaults here

Didn’t change anything here too yet

Now I’ll repeat step 1 to create a snapshot for each subvolume
Then I’ll read more about snap-pac, thanks @ricklinux for that, and about grub-btrfs, thanks @pebcak for that.
Then, I’ll try to restore a snapshot to see what happens… =)

Edit: Added items in bold text


I’m not the expert on this and i took my cues from others with way more knowledge. But i also have done some things a little differently than maybe they would because they understand it better and maybe don’t want some things? So I also installed grub-btrfs so that the snapshots are visible in grub. Maybe i don’t need it but i did it anyway. So the i enabled snapper-timeline.timer and snapper-cleanup.timer. I also enabled grub-btrfs.path for the grub entries to show in the grub menu when grub is updated. I also added snapper-gui which is in the AUR. Maybe it’s overkill but because i don’t totally have a grasp on everything it is just easier to have some alternatives to look at. Every time i have to remember what the commands are because i never write anything down. :upside_down_face: I reinstall a lot and test stuff and that’s how i get more familiar. Reading the Arch wiki is hard sometimes to get it right.

Edit: I also didn’t do this.

Access for non-root users:
sudo nano /etc/snapper/configs/config
chmod a+rx .snapshots/
chown :users .snapshots

1 Like

I’m thinking about this “Access for non-root users”… Since it’s optional, I could remove it, but as I’m still learning about how BTRFS works in general, I’m still kind of studying all the possible options.

What I did now is to:

By default, updatedb (see mlocate) will also index the .snapshots directory created by snapper, 
which can cause serious slowdown and excessive memory usage if you have many snapshots. You can prevent updatedb from indexing over it by editing: 
PRUNENAMES = ".snapshots

I’m reaching the point in which I’ll try to restore the snapshot, but I’m still with some doubts about it.
It seems that there is an option to use a directory, and other to use a mount point, still trying to understand this step…

1 Like

Brtrs is so much faster than ext4

Just try it

I wrote instructions on how to do that recently. Let me dig them up.

Not really…

1 Like

Ya …i don’t have a great grasp of everything either and I’m okay with that. Understanding how to get it installed and working is hard enough. Then i have to figure out how to use it. Especially if i have to do everything manually.

1 Like

Exactly, when things go south, we need to be ready =)

Here is one way to recover using snapshots. To do this, you will either need to be booted into a different subvolume/snapshot or off an ISO. Basically the volume you want to recover can’t be mounted.

I will assume the snapshot is number 1, it is the @ subvolume and the root of the btrfs device is mounted at /mnt. However, it could be anywhere.

First rename the old root subvolume and put a r/w snapshot on top of it.

sudo mv /mnt/@ /mnt/@old
sudo btrfs subvolume snapshot /mnt/@old/.snaphots/1/snapshot /mnt/@

If you are booted into a snapshot, then you would reboot at this point. If not, you can do the following and reboot after.

sudo mv /mnt/@old/.snapshots /mnt/@/.

The above command moves your “.snapshots” subvolume of out of the oldroot into the new. Lastly, you can optionally remove the old subvolume if you don’t need it anymore

sudo btrfs subvolume delete /mnt/@old

That is really all there is to it. You might consider trying it out in a VM first so you are comfortable with it.

Alternative methods:

  • You can move the snapshot instead of taking a snapshot but that has the disadvantage of not being able to recover that snapshot again.
  • You can mount the snapshot and the subvolume and use rsync to move the data

Ohk, but you have to agree on this,

System backups (snapshot) are done within half second

This is so lighting fast

You cant do this on ext4

Sure, with btrfs you are trading a small amount of performance and reliability for a whole bunch of cool features.

What snapshots are r/w that you would put on top of it? What does on top it mean? Replace?

Edit: For me this is the part that is very confusing. (restoring)

Basically you move the old one and put the new one where it used to be. Maybe “on top of it” isn’t the right phrase because it isn’t there anymore.