Bug 91751
| Summary: | qgroup not destroyed when subvolume snapshot deleted | ||
|---|---|---|---|
| Product: | File System | Reporter: | nfnty (arch) |
| Component: | btrfs | Assignee: | Josef Bacik (josef) |
| Status: | NEW --- | ||
| Severity: | normal | CC: | devurandom, dusty, MurzNN, szg00000 |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.18.2-2-ARCH | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
qgroup show
qgroup.c btrfs_delayed_qgroup_accounting error |
||
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 I also that qgroups don't get cleaned up. I'm on Fedora 22 4.1.5-200.fc22.x86_64. |
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.