From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: cannot mount btrfs volume read/write (+task blocked backtrace)
Date: Sun, 8 Nov 2015 21:34:06 +0000 (UTC) [thread overview]
Message-ID: <pan$3ffdf$6a78c0ef$7e29cbf3$bd815572@cox.net> (raw)
In-Reply-To: 1330727605.2639.1446965139494.JavaMail.zimbra@grelot.net
Frédéric Grelot posted on Sun, 08 Nov 2015 07:45:39 +0100 as excerpted:
> After 8 hours, "btrfs check --readonly" is still "checking quota
> groups". It does not have any IO activity, but uses 100% CPU.
> #top
> 1143 root 20 0 2266596 2.148g 1124 R 100.0 56.0 183:37.14
> btrfs check --readonly /dev/sda1
>
> I am not sure what to do : if you have no idea, since I have less than
> 3Tb of data I will just manually degrade the volume by removing one of
> the disk, build a new btrfs on it, copy the data since I can still open
> the old one RO, then manually take devices from the old volume to new
> new one (converting to raid1 first, then raid6).
Ahh... quotas. Devs are working very hard on them, but to this point
quotas have never really worked /correctly/, and the estimate as to when
they might... seems to always remain a couple kernel cycles out.
So my recommendation continues to be, either you really need quotas and
thus should use a filesystem where they are known to be mature and
stable, or you don't, and btrfs is an option, but don't enable quotas and
avoid the problems they cause. Unless of course you're specifically
working with the devs to debug and fix current functionality and don't
mind loosing a filesystem or two in the process as a result, in which
case, THANK YOU for helping to stabilize the feature for everyone,
however long it might take.
As for when it might be safe to enable them, at this point, with the
quota history we have, I'd suggest waiting at least two kernel cycles
after all known quota issues have been fixed. But whether that's 4.6 or
5.6 (with roughly 5 releases per year and a assuming another major
version bump at what would be .20, in keeping with the precedent set with
the 3.x series, it's roughly two years per major version kernel cycle, so
5.6 would be around 1Q2018) or 6.6... who can tell, until it happens?
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
prev parent reply other threads:[~2015-11-08 21:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-07 22:20 cannot mount btrfs volume read/write (+task blocked backtrace) Frédéric
2015-11-08 6:45 ` Frédéric Grelot
2015-11-08 21:34 ` Duncan [this message]
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='pan$3ffdf$6a78c0ef$7e29cbf3$bd815572@cox.net' \
--to=1i5t5.duncan@cox.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.