You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
When using normal qgroups, the full filesystem freezes from time to time, resulting in a complete halt of any input. Nothing works for a couple of seconds (up to a minute). On an NVMe this imho is unacceptable. For this reason simple qgroups (sqgroups) exists now. btrfs quota enable -s $Path
Describe the solution you'd like
When deleting subvolumes the qgroups will be cleaned up asynchronously and take a couple of seconds to become stale.
In that time frame it is impossible to delete that qgroup. Unfortuately timeshift will try to do just that and delete it while it's still under deletion and thus fail. When you wait a bit and make sure the entry is stale, the deletion will work fine.
Describe alternatives you've considered
Disabling qgroups would be an alternative, but since I use my machine with subvolumes that need to have quotas enabled to constraint it's maximum size, it is not a real alternative.
Additional context
I have no idea about vala, but before executing the qgroup destroy here
a check should be done to ensure the qgroup is stale.
This can be done with the json output of the btrfs cli. Before deletion the referenced and exclusive count is high and the path populated. It becomes stale when they are either 0 or empty.
Is your feature request related to a problem? Please describe.
When using normal qgroups, the full filesystem freezes from time to time, resulting in a complete halt of any input. Nothing works for a couple of seconds (up to a minute). On an NVMe this imho is unacceptable. For this reason simple qgroups (sqgroups) exists now.
btrfs quota enable -s $Path
Describe the solution you'd like
When deleting subvolumes the qgroups will be cleaned up asynchronously and take a couple of seconds to become
stale
.In that time frame it is impossible to delete that qgroup. Unfortuately timeshift will try to do just that and delete it while it's still under deletion and thus fail. When you wait a bit and make sure the entry is stale, the deletion will work fine.
Describe alternatives you've considered
Disabling qgroups would be an alternative, but since I use my machine with subvolumes that need to have quotas enabled to constraint it's maximum size, it is not a real alternative.
Additional context
I have no idea about vala, but before executing the qgroup destroy here
timeshift/src/Core/Subvolume.vala
Line 173 in ffb6047
This can be done with the json output of the btrfs cli. Before deletion the
referenced
andexclusive
count is high and thepath
populated. It becomes stale when they are either 0 or empty.The text was updated successfully, but these errors were encountered: