From: Marc Joliet <marcec@gmx.de>
To: linux-btrfs@vger.kernel.org
Subject: system hangs due to qgroups
Date: Sat, 03 Dec 2016 19:40:37 +0100 [thread overview]
Message-ID: <1776088.42rHLKPlSp@thetick> (raw)
[-- Attachment #1: Type: text/plain, Size: 3186 bytes --]
Hello all,
I'm having some trouble with btrfs on a laptop, possibly due to qgroups.
Specifically, some file system activities (e.g., snapshot creation,
baloo_file_extractor from KDE Plasma) cause the system to hang for up to about
40 minutes, maybe more. It always causes (most of) my desktop to hang,
(although I can usually navigate between pre-existing Konsole tabs) and
prevents new programs from starting. I've seen the system load go up to >30
before the laptop suddenly resumes normal operation. I've been seeing this
since Linux 4.7, maybe already 4.6.
Now, I thought that maybe this was (indirectly) due to an overly full file
system (~90% full), so I deleted some things I didn't need to get it up to 15%
free. (For the record, I also tried mounting with ssd_spread.) After that, I
ran a balance with -dusage=50, which started out promising, but then went back
to the "bad" behaviour. *But* it seemed better than before overall, so I
started a balance with -musage=10, then -musage=50. That turned out to be a
mistake. Since I had to transport the laptop, and couldn't wait for "balance
cancel" to return (IIUC it only returns after the next block (group?) is
freed), I forced the laptop off.
After I next turned on the laptop, the balance resumed, causing bootup to
fail, after which I remembered about the skip_balance mount option, which I
tried in a rescue shell from an initramfs. But wait, that failed, too!
Specifically, the stack trace I get whenever I try it includes as one of the
last lines:
"RIP [<ffffffff8131226f>] qgroup_fix_relocated_data_extents+0x1f/0x2a8"
(I can take photos of the full stack trace if requested.)
So then I ran "btrfs qgroup show /sysroot/", which showed many quota groups,
much to my surprise. On the upside, at least now I discovered the likely
reason for the performance problems.
(I actually think I know why I'm seeing qgroups: at one point I was trying out
various snapshot/backup tools for btrfs, and one (I forgot which)
unconditionally activated quota support, which infuriated me, but I promptly
deactivated it, or so I thought. Is quota support automatically enabled when
qgroups are discovered, or did I perhaps not disable quota support properly?)
Since I couldn't use skip_balance, and logically can't destroy qgroups on a
read-only file system, I decided to wait for a regular mount to finish. That
has been running since Tuesday, and I am slowly growing impatient.
Thus I arrive at my question(s): is there anything else I can try, short of
reformatting and restoring from backup? Can I use btrfs-check here, or any
other tool? Or...?
Also, should I be able to avoid reformatting: how do I properly disable quota
support?
(BTW, searching for qgroup_fix_relocated_data_extents turned up the ML thread
"[PATCH] Btrfs: fix endless loop in balancing block groups", could that be
related?)
The laptop is currently running Gentoo with Linux 4.8.10 and btrfs-progs
4.8.4.
Greetings
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next reply other threads:[~2016-12-03 18:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-03 18:40 Marc Joliet [this message]
2016-12-03 20:42 ` system hangs due to qgroups Chris Murphy
2016-12-03 21:46 ` Marc Joliet
2016-12-03 22:56 ` Chris Murphy
2016-12-04 16:02 ` Marc Joliet
2016-12-04 18:24 ` Duncan
2016-12-04 19:20 ` Marc Joliet
2016-12-05 2:32 ` Duncan
2016-12-04 18:52 ` Chris Murphy
2016-12-05 9:00 ` Marc Joliet
2016-12-05 10:16 ` Marc Joliet
2016-12-05 23:22 ` Marc Joliet
2016-12-19 11:17 ` Marc Joliet
2016-12-04 2:10 ` Adam Borowski
2016-12-04 16:02 ` Marc Joliet
2016-12-05 0:39 ` Qu Wenruo
2016-12-05 11:01 ` Marc Joliet
2016-12-05 12:10 ` Marc Joliet
2016-12-05 14:43 ` [SOLVED] " Marc Joliet
2016-12-06 0:29 ` Qu Wenruo
2016-12-06 10:12 ` Marc Joliet
2016-12-06 14:55 ` Marc Joliet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1776088.42rHLKPlSp@thetick \
--to=marcec@gmx.de \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox