Call for testing BTRFS Assistant

Hello everyone.

I wanted to enlist some aid in testing a new application I developed for managing btrfs and snapper.

Originally, I built this functionality as an enhancement to Garuda Assistant but since it wasn’t really dependent on Garuda in any way, we decided to break it into it’s own application so it could be used across distros.

So, what is BTRFS Assistant? It is a GUI tool for managing btrfs and btrfs subvolumes as well as snapper. It allows for configuration and management of snapper as well as has the ability to restore snapshots.

If you want to make use of the snapshot restore functionality, there is one very important limitation. You must allow snapper to use a nested .snapshots subvolume(which it does by default). If you manually mount /.snapshots the restore functionality will not work because it will not be able to determine where it needs to restore to. This leads to a big advantage which is that you can use almost any subvolume scheme or naming convention you wish.

If you would be interested in helping out with testing, it is available in the AUR as btrfs-assistant-git. Please note, since this is still in testing, please don’t use it with critical data.

Thanks in advance and please feel free to ask questions.


Wow - thanks for the expanded release. Enough of this type of advance, and I might use btrfs elsewhere than on Garuda (with defaults)!

That is great Dalto… Perfect…
I would help but unfortunately I already changed my layout before installation… :frowning:

I have btrfs setup on two of my computers and they are working and taking snap shots. But i’ll be honest because i don’t use it I’m not that familiar with restoring a snapshot.

I have snapper installed with snapper gui also. My setup is probably the same as @mcury or it was originally.

I don’t even recall what is enabled or not.

[ricklinux@eos-kde ~]$ cat /etc/fstab | eos-sendlog
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1506    0    24  100  1482     99   6148 --:--:-- --:--:-- --:--:--  6275

[ricklinux@eos-kde ~]$ sudo btrfs subvolume list /
[sudo] password for ricklinux: 
ID 256 gen 163 top level 5 path @2021-10-22T01:24
ID 257 gen 55303 top level 5 path @home
ID 258 gen 54694 top level 5 path @cache
ID 259 gen 55303 top level 5 path @log
ID 260 gen 55120 top level 5 path @snapshots
ID 261 gen 31 top level 5 path @swap
ID 265 gen 29 top level 256 path @2021-10-22T01:24/var/lib/portables
ID 266 gen 30 top level 256 path @2021-10-22T01:24/var/lib/machines
ID 274 gen 55303 top level 5 path @
ID 278 gen 266 top level 260 path @snapshots/2/snapshot
ID 2185 gen 44518 top level 260 path @snapshots/345/snapshot
ID 2198 gen 46227 top level 260 path @snapshots/358/snapshot
ID 2234 gen 47561 top level 260 path @snapshots/370/snapshot
ID 2327 gen 49248 top level 260 path @snapshots/382/snapshot
ID 2346 gen 50655 top level 260 path @snapshots/394/snapshot
ID 2356 gen 52430 top level 260 path @snapshots/404/snapshot
ID 2368 gen 54216 top level 260 path @snapshots/416/snapshot
ID 2369 gen 54340 top level 260 path @snapshots/417/snapshot
ID 2370 gen 54419 top level 260 path @snapshots/418/snapshot
ID 2371 gen 54562 top level 260 path @snapshots/419/snapshot
ID 2372 gen 54673 top level 260 path @snapshots/420/snapshot
ID 2373 gen 54806 top level 260 path @snapshots/421/snapshot
ID 2374 gen 55011 top level 260 path @snapshots/422/snapshot
ID 2375 gen 55119 top level 260 path @snapshots/423/snapshot
[ricklinux@eos-kde ~]$ 

Edit: I would be willing to try it. But you’ll have to educate me because i still don’t have a strong understanding how this all works. Sure i can install it and get it working and i sort of understand it as i helped @mcury also in the beginning as well as yourself. But it seems maybe he understands it better than i do maybe? :thinking: I’m not sure because installing it and getting it working is sort of understanding a bit i guess. Maybe?

1 Like

The only thing is can’t handle is a hard mounted /.snapshots. If you already have one you can just remove it from /etc/fstab and move it to be nested.

If you are still using that method we discussed, it’s probably snapper-rollback…
To restore, you just need to sudo snapper-rollback 418 (if you want to restore snapshot number 418).

In case you want to delete @2021-10-22T01:24, you can boot into live USB, and issue:

  • Assuming /dev/sda2 is your btrfs root:
# mount /dev/sda2 /mnt -o subvolid=5
# btrfs subvolume delete @2021-10-22T01:24

Thanks Dalto, you taught me this part :slight_smile:

Yes…see i already forgot and i have reinstalled this so now i have to check. Maybe i don’t even have it installed?

Edit: Yes it’s installed.

If I knew about this before installing my system yesterday, I wouldn’t change the layout, so I could help…

Hmm, my ./snapshots is in fstab as per below… Just noticed the discard-async option, strange… Isn’t fstrim enabled by default now? Kind out of this topic, I’ll open a new one about the discard

UUID=70dc7d41-46da-4c17-b92a-51c98f0d731f /.snapshots btrfs subvol=/@snapshots,defaults,noatime,autodefrag,compress=zstd,discard=async,ssd 0 0

First, it matters not at all what the options are on that subvolume since it doesn’t have anything in it except other subvolumes. :slight_smile:

That being said, discard=async is a newer option that is more efficient than discard. That being said, if you prefer to use the fstrim timer only, that is also fine.

Hm, but all my subvolumes have the discard=async option in fstab.
So I’m not sure if I can use this option and the fstrim.service together?
Shouldn’t be one or the other?

You can, they will just both be doing trim operations. That being said, an extra trim once per week won’t hurt anything.

For me, the weekly trim job is enough but it is really a matter of personal choice and also depends on your use case. If your ssd is close to full than discard=async might be better for you.

1 Like

Thanks Dalto for clearing my doubts, I’ll stop polluting this topic, it’s a great tool you have here for all of us :slight_smile:
I’ll be thinking here about a system reinstall just to help, but as I just reinstalled EnOS/Windows yesterday, I’m kind of tired ehhe, maybe in a week :slight_smile:

I don’t mind either way, but why would using this tool require a re-install? It doesn’t require the default layout used by the installer.

I have installed it. Is there anything special i need to do after installing it? What settings do i enable?

Anyway, sorry for the pollution :slight_smile:
I’ll change ./snapshots to nested and remove from fstab to test

What is nested? Why?
Edit: Mine are okay i hope?

Default layout have snapshots inside /
We changed that to use snapper-rollback.
So, according to Dalto, to use this tool we need to remove snapshots from fstab, reboot, and run the snapper-config again, these are the steps I’ll take before installing this tool. At least this is what I understood from Dalto’s post…

Sorry i don’t understand this exactly? snapshots are in /. I don’t remember what i did for snapper-rollback. :wink:

No need to sorry rick, when we installed the system, we edited /etc/calamares/modules/mount.conf to include:

- mountPoint: /.snapshots
subvolume: /@snapshots

Then, as snapper create-config automatically creates a subvolume .snapshots with the root subvolume @ as its parent, that is not needed for the suggested filesystem layout, we deleted it so we could mount outside /
edit: basically we need to undo that, by removing snaphots from fstab, and just run snapper-config again, this is my understanding but I could be wrong or even jumping a few steps here…

I thought everything is inside / So the subvolumes @ aren’t inside?

Edit: Keep in mind i reinstalled it with one of the dev ISO so it should be the same as the latest ISO has it. I posted a link to fstab above.