Btrfs Assistant 1.0 is coming, testers needed

[adb76]

Coming from Garuda Linux I directly installed Btrfs Assistant on my fresh EOS installation

I now have the version 1.6.3 installed. It works as expected incl. the rollback, automated snapshots etc. The only question I have is, why the “Created” timestamp differs from the real date / timestamp when the rollback snapshots were created:

According to the name of the snapshot, you can see that I have rollbacked today the root (/) and the /home Subvolumes at 12:31 / 12:32 but the “Created” column shows a totally different date from 19th / 20th?! Is this something were I have to change the configuration or just a “bug” in the tool?

Kind regards,

André

[dalto]

@adb76

Is this something were I have to change the configuration or just a “bug” in the tool?

Perhaps neither? The “created” column is localized and displayed for your timezone. The backup name probably isn’t.

[adb76]

@dalto

Perhaps neither? The “created” column is localized and displayed for your timezone. The backup name probably isn’t.

My timezone is GMT+1 and I did the rollback for / and home directly after each other - so it is strange why there should be a difference of more than one day between the two “created” timestamps.

Not that I misinterpreted it: the Created column shows the timestamp of the date / hour when the rollback snapshot is taken - right?

[dalto]

Oh…you are probably right.

The backups aren’t snapshots. So the created timestamp isn’t when the backup was taken.

[anon50380917]

Is brfsmaintenance necessary for the Assistant to upgrade the old snapshots by itself?

Edit: I just see that an additional subvolume @ was created here by itself. Is that correct?

[dalto]

@anon50380917

Is brfsmaintenance necessary for the Assistant to upgrade the old snapshots by itself?

I am not sure what you mean by “upgrade all snapshots”

@anon50380917

I just see that an additional subvolume @ was created here by itself. Is that correct?

That is your root subvolume. Btrfs Assistant didn’t create that, the EOS installer did.

[anon50380917]

@dalto

am not sure what you mean by “upgrade all snapshots”

sorry, is a translation error of deepL, I mean that according to the settings

it removes the old snapshots itself, clean up.

There is also Snapper cleanaup enabled, but why do you need btrfsmaintenance?

[anon50380917]

@dalto

That is your root subvolume. Btrfs Assistant didn’t create that, the EOS installer did.

Because it was created only a few days later …

[dalto]

@anon50380917

There is also Snapper cleanaup enabled, but why do you need btrfsmaintenance?

btrfsmaintenance enables more functionality. You don’t need it to clean-up snapshots. That is handled by Snapper.

It adds things like configurable scheduled scrubs, balance and defrag. It is entirely optional.

When you install it, a new tab is added to Btrfs Assistant with that functionality.

@anon50380917

Because it was created only a few days later …

Probably because you restored a snapshot. I guess, technically, Btrfs Assistant created that from a snapshot. However, the original @ subvolume was created by the installer.

[anon50380917]

OK, thanks @dalto

[BezierCurve]

@Zesko

sudo systemctl edit --full \\x2esnapshots.mount

I have the same problem and i dont know what to do about it

[dalto]

@BezierCurve

I have the same problem and i dont know what to do about it

Modify the path unit is my recommendation.

Use this instead:

[Unit]
Description=Monitors for new snapshots

[Path]
PathModified=/.snapshots

[Install]
WantedBy=multi-user.target

[anon50380917]

Is it somehow possible to reset the numbering of the already existing snapshots, or to start with 1? I have the feeling that soon the width of my screen may no longer be sufficient to display the length of the numbering, if that continues to count as before.

[dalto]

That is snapper itself numbering the snapshots.

I am not sure if there is a way to reset it or not without deleting the config or hacking at the xml.

[Zesko]

@dalto

Enable the grub-btrfs.path systemd unit

I noticed there is the new version of grub-btrfs for GRUB.

It does not use the grub-btrfs.path anymore and calls the grub-btrfs.service obsolete,
but it created the new grub-btrfsd.service.

How to convert them to the grub-btrfsd.service.

1. disable grub-btrfs.path and grub-btrfs.service

$ sudo systemctl disable --now grub-btrfs.path grub-btrfs.service

2. Enable grub-btrfsd.service

$ sudo systemctl enable --now grub-btrfsd.service

If you use Timeshift 22.6+ instead of snapper.

1. Edit grub-btrfsd.service to change the line ExecStart=...

$ sudo systemctl edit --full grub-btrfsd.service

Change

ExecStart=/usr/bin/grub-btrfsd --syslog /.snapshots

to

ExecStart=/usr/bin/grub-btrfsd --syslog --timeshift-auto

2. Restart grub-btrfsd.service

$ sudo systemctl restart grub-btrfsd.service

[limotux]

@dalto

That may be a bug. I will need to look at that on my side and see if I am seeing the same issue.

Hi @dalto
It has been a long time.
I am glad with the developments that came with Cassini, I just converted to dracut

I remember sytemd-boot was wonderful and I loved it. But there was an issue to restore from a snapshot (quoted post).

Was it a bug in BTRFS-Assistant?
Is it OK now.
If BTRFS Assistant will enable me now to systemd-boot and recover/restore a previous snapshot I would convert again to systemd-boot

I highly appreciate all what you and everybody are doing. Simply amazing.
I will appreciate feed back.

[anon50380917]

Now I remember what I wanted to ask: What are Btrfs Quotas and what is the point of enabling this setting?

[dalto]

The primary purpose is to limit disk usage based on criteria.

However, many people enable them because it makes it much faster to calculate disk space metrics.

That being said, enabling them can cause performance issues in certain use cases so I usually leave them disabled on my own installs.

[anon50380917]

Thanks @dalto , that’s good to know.

[nVIceman]

I’m getting closer to doing a fresh install after testing EndeavourOS for awhile now and I’ve noticed this systemd-boot as the default over grub and I couldn’t think of a great reason to now continue to user grub since it isn’t the default anymore and the advantages and reasoning why is no longer is.

I did notice something about bootable snapshot issues and some things needing to be worked or something. I am referencing this thread.

Systemd-boot, dracut and btrfs?

I’m a bit confused about dealing with systemd-boot and dracut in conjunction with a btrfs system. I’m supposed to install EOS with btrfs on another machine next week, but dalto wrote yesterday “There is no good way to do btrfs snapshot booting with systemd-boot.” So in that case I would have to give up the ability to boot directly from snapshots? Or I do without btrfs on this machine and go back to ext4? Both not so good. But switching to grub on this reinstall sounds a bit regressive to me agai…

My question is comparing it to grub (previous way of all this snapshot stuff), what are the current pros and cons? I’m trying to figure out if I should still be using grub, and if so, there seem to be some differences anyways posted about a few weeks ago in this thread.