In Btrfs mode the unshared space from the snapshot is not visible, it has been removed from the GUI

[emanuc]

Why was the "unshared" view removed? This is a regression for Btrfs users using Timeshift, I can no longer control how much space the snapshot is taking up.
I have encountered this problem with the latest version of Timeshift on Debian testing
Thanks for the work you do.

[Fantu]

is not a bug but was removed in c0737b1 but seems was not working after 8d77b18 that was done to solves other issues
anyway I also think view of unshared space (to see space effective space of single snapshot can be useful (I don't use btrfs snapshot with timeshift for now but with minimal custom scripts on some servers at work)

[jondo]

I suggest that the new "unshared" column should display how much disk space will be freed if only this snapshot is deleted.

Example (from a similar backintime issue): When file a is contained in snapshots 1 and 2, and file b in 2 and 3, deleting neither of the snapshots would free any disk space, so in the absence of any other files "unshared" should only show zeros.

The former "unshared" column displayed values similar to du -sh * instead, which do not have this property.

[tpraxl]

Are there any plans to restore the columns?

[tpraxl]

I really want this feature restored, and I offer my help in doing so.

However, I do not really understand the reasons for 8d77b18 (@Fantu pointed it out as being the breaking commit that has lead to c0737b1 – the actual removal of the column).

The commit message of 8d77b18 refers to issues in https://github.com/teejee2008/timeshift/issues:

• Removing snapshots fails if BTRFS quota groups (qgroups) is disabled teejee2008/timeshift#680
• Disabling qgroups makes Timeshift misbehave (snapshots not deleted on first try) teejee2008/timeshift#865
• Timeshift shows Size and Unshared '0 B' when first start after boot. teejee2008/timeshift#839

Can someone explain the background of these issues in short and the reasons for why it was fixed in a way that broke the column display, so that I am able to look into possible solutions?

Maybe @teejee2008 or @clefebvre can point that out?

[Fantu]

I use btrfs on some disks personal and some servers at work, in latest years I use simply use it and snapshot and some other thing with custom scripts prepared many years ago.
The big of tests I did for choose if, where and how to use it, see the possible limitations, performance, issues etc... mainly date back to 2014-2016 if I remember correctly.
I don't remember perhaps enough details and over the years they have made improvements.
FWIR quota must be enabled for calculate size of single snapshot (unshared size), I don't remember other way.
In my case where I regularly use snapshots and custom scripts I do not use quotas due to some cons and not enough benefits at the time of tests and for history/cleaning to decide in the script whether to delete other snapshots I instead rely on the current free size and effective.
Considering the way it frees up space, however, over the years, I have seen that this is not very good as on large dimensions (of snapshots) it takes longer to free up the actual space and you risk canceling small extra snapshots unnecessarily or deleting more even with large snapshots because when checking free space it has not finished the actual cleaning yet which may take a long time (more on hdd).
So for when in my case the odds would have been used only to calculate the size of the snapshots and they didn't seem enough to make up for the cons, it was seen that they would be quite useful.
at the moment I only use timeshift on a few systems without btrfs, in the future maybe I will consider using it more, and with btrfs having the quotas active and being able to see the snapshot size would be useful.
Unfortunately I don't have time to redo the btrfs tests because I am involved in many other things but if someone would do them and see that they do not involve significant problems I would recommend to put them back.
Or alternatively if someone has time and wants to do a PR that restores this functionality but optionally and well supporting the different cases so as not to have unexpected events like some of those that had been supported.
Anyway before do the works for don't risk to waste time probably is better ask to @clefebvre if it would be accepted.
Sorry for my bad english.

[tpraxl]

I'll try to summarize my understanding:

• The display of size / unshared columns has never been enabled for rsync, right? It was only ever enabled for btrfs.
• In order to calculate the size / unshared columns, we need to enable quota (btrfs quota enable)
  • This is known to hit performance
    • See https://btrfs.readthedocs.io/en/latest/btrfs-qgroup.html
    • See https://btrfs.readthedocs.io/en/latest/btrfs-quota.html#performance-implications
  • The user might run timeshift with or without btrfs and with or without quotas enabled
  • Users who enabled quotas, experienced performance issues with btrfs quotas
  • Users who disabled quotas, experienced problems with timeshift

Is there a reliable way to detect if the user has turned quotas on?

Then I would suggest to take a first step by restoring the size and unshared columns only for users who are using btrfs with quotas.

[Fantu]

@tpraxl to detect if quota is enabled should be easy as if try qgroup command will show specific error, for example:

btrfs qgroup show /mnt/backup-vm/
ERROR: can't list qgroups: quotas not enabled

[emanuc]

You can also check from the "sys" folder, if quotas are enabled it should give you a "qgroups" folder:

emanu@fedora ~> ls /sys/fs/btrfs/d4e9bcc1-3dca-4027-9150-9ab4262271f1 | grep qgroups
qgroups

emanu@fedora ~> ls /sys/fs/btrfs/95d14f9d-8717-4ea0-8a79-34603a7269fe | grep qgroups
emanu@fedora ~ [0|1]> ls /sys/fs/btrfs/e7c0db81-bb74-4ba0-96d5-e97e9a2ddeb9 | grep qgroups

emanu@fedora ~> ls /sys/fs/btrfs/d4e9bcc1-3dca-4027-9150-9ab4262271f1
allocation/  bdi@  bg_reclaim_threshold  checksum  clone_alignment  commit_stats  devices/  devinfo/  exclusive_operation  features/  generation  label  metadata_uuid  nodesize  qgroups/  quota_override  read_policy  sectorsize

emanu@fedora ~> ls /sys/fs/btrfs/d4e9bcc1-3dca-4027-9150-9ab4262271f1 | grep qgroups
emanu@fedora ~ [0|1]> sudo btrfs quota enable /

emanu@fedora ~> ls /sys/fs/btrfs/d4e9bcc1-3dca-4027-9150-9ab4262271f1 | grep qgroups
qgroups
emanu@fedora ~> sudo btrfs quota disable /
emanu@fedora ~> ls /sys/fs/btrfs/d4e9bcc1-3dca-4027-9150-9ab4262271f1 | grep qgroups
emanu@fedora ~ [0|1]> 

There is also a library for handling Btrfs: https://github.com/kdave/btrfs-progs/blob/master/libbtrfsutil/README.md#libbtrfsutil

For the performance issue with quotas is if you do a lot of snapshot operations, like creating and deleting many snapshots.
This problem should be solved by "Extent tree v2": btrfs/btrfs-todo#25

[tpraxl]

I think I'm gonna provide a method canShowSizes to decide if the columns should be visible. This method would execute btrfs qgroup show ... and use the exit code to determine whether quotas are enabled, hence show or hide the columns.

In the first step, I would simply restore the old calculation that has been disabled and show the results.

@clefebvre / @teejee2008 : would you support this step?

A second step might introduce getCalculationStrategy, if there are reasonable ways to determine the sizes for systems with disabled quotas or even non-btrfs rsync. I consider the second step as an optional feature. Turning off quotas naturally removes the ability to show sizes; IMHO there's no urgent need to perform complicated / time-consuming tasks to work around this natural limit.

[Fantu]

even if "du" command is not useful for simply take the size of snapshot in btrfs, it is it for folders, on other backup solution based on rsync I can use it for see the size of single backup, tried now with one my pc with backintime, about timeshift I don't remember if I ever tried to check single backup size with it and I don't have access on one of the computer using it now for fast check