Bug 91751 - qgroup not destroyed when subvolume snapshot deleted
Summary: qgroup not destroyed when subvolume snapshot deleted
Status: NEW
Alias: None
Product: File System
Classification: Unclassified
Component: btrfs (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Josef Bacik
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-22 03:51 UTC by nfnty
Modified: 2019-05-11 00:27 UTC (History)
4 users (show)

See Also:
Kernel Version: 3.18.2-2-ARCH
Tree: Mainline
Regression: No


Attachments
qgroup show (127.49 KB, application/octet-stream)
2015-01-22 03:51 UTC, nfnty
Details
qgroup.c btrfs_delayed_qgroup_accounting error (3.08 KB, text/plain)
2015-01-22 03:58 UTC, nfnty
Details

Description nfnty 2015-01-22 03:51:24 UTC
Created attachment 164271 [details]
qgroup show

qgroups are not being destroyed when the snapshots are. This makes btrfs-cleaner extremely slow when snapper-cleanup is run on a setup with 15 daily and 10 hourly snapshots. Every day when snapper-cleanup is run btrfs-cleaner consumes about 20 minutes of processor time and locks IO every 5-10 seconds for 5 second bursts. Disabling quotas seems to have solved this problem.

I had 2965 qgroups spread across three subvolumes according to `btrfs qgroup show /`. Attached output. cgroupid of the subvolumes are 257 (/, 30G), 258 (/home, 30G) and 259 (/data, 400G).

Running on laptop Sandy Bridge i3 @ 2.3GHz and 512GB Crucial M4 SSD.
Comment 1 nfnty 2015-01-22 03:58:57 UTC
Created attachment 164281 [details]
qgroup.c btrfs_delayed_qgroup_accounting error

Every time snapper-cleanup is run the kernel outputs an error trace regarding qgroup.c btrfs_delayed_qgroup_accounting. Attached kernel log snippet.

May be related to https://bugzilla.kernel.org/show_bug.cgi?id=81221
Comment 2 Dusty Mabe 2015-09-01 20:15:05 UTC
I also that qgroups don't get cleaned up. I'm on Fedora 22 4.1.5-200.fc22.x86_64.

Note You need to log in before you can comment on or make changes to this bug.