Feature/restore qgroups size

[tpraxl]

Refs: #47

This PR mostly restores old behavior:

• feat: Enable display of shared and exclusive sizes
• fix: Destroy qgroups upon snapshot removal (on a system with qgroups enabled, I encountered a lot of 0.00B qgroups (btrfs qgroup show .), supposedly caused by timeshift)

Opposing to the former behavior, timeshift does not enable qgroups by itself anymore.

It simply executes btrfs qgroup show … and evaluates the exit code.

On success, btrfs qgroups are considered enabled (App.btrfs_qgroups_enabled = true), on failure, btrfs qgroups are considered disabled. In the latter case, timeshift neither shows the size columns, nor does it destroy qgroups.

This restores a very important feature for users that do use qgroups.
Other users are practically unaffected (btrfs with disabled qgroups and rsync users).

Screenshot:

This PR is a first proposal. If the maintainers generally agree with the attempt, I plan to cleanup the affected code a bit.

[mtwebster]

Hi, this mostly works fine.

• Disabling qgroups makes Timeshift misbehave (snapshots not deleted on first try) teejee2008/timeshift#865 seems to be fixed - enabling/disabling and deleting snapshots created with quotas and without can be deleted whether enabled or not.
• I still see Timeshift shows Size and Unshared '0 B' when first start after boot. teejee2008/timeshift#839 if I enable quotas then immediately start timeshift. I don't really see this as that big a deal, however. It doesn't happen after running again, and upon reboot the columns are populated correctly.

The only thing that somewhat bothers me is the log spam for users running btrfs without qgroups enabled. You could make btrfs_qgroups_enabled have three states (-1, 0, 1) instead of a boolean - an 'uninitialized' (-1) value to check before calling query_subvolume_quotas(), and if that returns 0 we never call it again.

Are you ready for this to be merged? You mentioned wanting to clean up the code a bit more.

Thanks

[tpraxl]

Thanks for looking into the PR. I very much appreciate your feedback.

The only thing that somewhat bothers me is the log spam for users running btrfs without qgroups enabled. You could make btrfs_qgroups_enabled have three states (-1, 0, 1) instead of a boolean - an 'uninitialized' (-1) value to check before calling query_subvolume_quotas(), and if that returns 0 we never call it again.

Can you be more specific about the log spam? I would be glad to look into it. Maybe we can mute the logging in that case.

I would like to find an alternative to the suggested solution (disable checks), because I anticipate the following use case:

1. btrfs user with disabled qgroups starts timeshift
2. timeshift persists disabled qgroups
3. btrfs user enables qgroups
4. timeshift will never check again, hence timeshift will not display the columns although qgroups are enabled

Are you ready for this to be merged? You mentioned wanting to clean up the code a bit more.

I would offer the following "roadmap":

1. I would like to implement the solution to the log spam issue, once we clarified the direction to take
2. Afterwards, I would like to clean up the code a bit more

These steps can be taken as part of this PR.
However, if you prefer, you may very well merge this PR now. I would love to see the columns back into the distributed version :)
I would then offer to take the steps above after the merge.

[mtwebster]

3. btrfs user enables qgroups
4. timeshift will never check again, hence timeshift will not display the columns although qgroups are enabled

From my testing, qgroups are picked up and columns displayed if they're enabled, but for whatever reason it doesn't happen the first time timeshift is relaunched, but does on subsequent times - unless I'm misunderstanding what you're saying here.

This is printed any time query_subvolume_quotas() is called:

E: ERROR: can't list qgroups: quotas not enabled

E: btrfs returned an error: 256
Failed to query subvolume quota.

Most people wouldn't see it ordinarily but it can be a distraction when troubleshooting.

However, if you prefer, you may very well merge this PR now. I would love to see the columns back into the distributed version :)
I would then offer to take the steps above after the merge.

We definitely want to tag a new release as soon as possible so I'll merge it and we can improve things later. I've got a fix for the log spam (at least a temporary one - I wanted to see how rusty my vala was).

Thanks

[mtwebster]

Can you squash this? Or I can do it when I merge.

[tpraxl]

Can you squash this? Or I can do it when I merge.

I squashed it, adapted the commit message, and force pushed.

We definitely want to tag a new release as soon as possible so I'll merge it and we can improve things later. I've got a fix for the log spam (at least a temporary one - I wanted to see how rusty my vala was).

Looking forward to view your solution.

Thanks for releasing it so soon.