From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Data single *and* raid?
Date: Sun, 2 Aug 2015 00:27:29 +0000 (UTC) [thread overview]
Message-ID: <pan$b8fa$cc3e43af$7e32a698$96ba80bb@cox.net> (raw)
In-Reply-To: 20150801223413.GC14352@carfax.org.uk
Hugo Mills posted on Sat, 01 Aug 2015 22:34:13 +0000 as excerpted:
>> Yes and that also puts it in the realm of kernels that weren't
>> releasing/deallocating empty chunks; although I don't know if that's a
>> factor, if dconvert forcibly deals with this..
>
> It does -- you only have to look at the btrfs fi df output to see
> that there's no empty block groups (to within 0.1% or so)
Exactly. The allocations are all full.
And the fi show says there's little to no room to allocate more, as
well. There's room on one device, but that's not going to help except
with single, which shouldn't be allocated any more.
I'd say...
1) If this fs was created with btrfs-progs v4.1.1, get what you need to
retrieve off of it immediately, then blow it away and start over, as the
thing isn't stable and all data is at risk.
2) If it wasn't created with progs v4.1.1, the next issue is that kernel,
since it's obviously from before raid56 was fully functional (well either
that or there's a more serious bug going on). Existing data should at
least be reasonably stable, but with raid56 mode being so new, the newer
the kernel you're using to work with it, the better. 4.1.x at LEAST, if
not 4.2-rc, as we're nearing the end of the 4.2 development cycle. And
plan on keeping even better than normal backups and on current on kernels
for at least another several kernel cycles, if you're going to use raid56
mode, as while it's complete now, it's going to take a bit to stabilize
to the level of the rest of btrfs itself, which of course is stabilizing
now, but not really fully stable and mature yet, so the sysadmin's rule
that data with any value is backed up, or by definition it's throw-away
data, despite any claims to the contrary, continues to apply double on
btrfs, compared to more mature and stable filesystems.
So definitely upgrade the kernel. Then see where things stand.
3) Meanwhile, based on raid56 mode's newness, I've been recommending that
people stay off it until 4.5-ish or so, basically a year after initial
nominal full support, unless of course their intent is to be a leading/
bleeding edge testing and report deployment. Otherwise, use raid1 or
raid10 mode until then, and evaluate raid56 mode stability around 4.5,
before deploying.
And if you're one of the brave doing current raid56 deployment, testing
and bug reporting in full knowledge of its newness and lack of current
stability and maturity, THANKS, it's your work that's helping to
stabilize it for others, when they do switch to it. =:^)
--
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
next prev parent reply other threads:[~2015-08-02 0:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-01 20:09 Data single *and* raid? Hendrik Friedel
2015-08-01 20:24 ` Chris Murphy
2015-08-01 20:32 ` Hugo Mills
2015-08-01 20:44 ` Chris Murphy
2015-08-01 21:45 ` Duncan
2015-08-01 22:26 ` Chris Murphy
2015-08-01 22:34 ` Hugo Mills
2015-08-02 0:27 ` Duncan [this message]
2015-08-02 1:14 ` Chris Murphy
2015-08-02 3:46 ` Duncan
2015-08-02 18:31 ` Chris Murphy
2015-08-02 19:06 ` Hugo Mills
2015-08-02 12:54 ` Hendrik Friedel
2015-08-06 18:57 ` Hendrik Friedel
2015-08-07 1:26 ` Qu Wenruo
2015-08-07 5:16 ` Hendrik Friedel
2015-08-07 6:25 ` Duncan
2015-08-07 8:11 ` Hugo Mills
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$b8fa$cc3e43af$7e32a698$96ba80bb@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.