All of lore.kernel.org
 help / color / mirror / Atom feed
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


      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.