From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: safe/necessary to balance system chunks?
Date: Sat, 26 Apr 2014 04:23:13 +0000 (UTC) [thread overview]
Message-ID: <pan$3ed2f$4edb7153$eb405bea$cf2b6b8@cox.net> (raw)
In-Reply-To: 765C03C7-08EB-4927-8934-5D6F926D6008@colorremedies.com
Chris Murphy posted on Fri, 25 Apr 2014 19:41:43 -0600 as excerpted:
> OK so somehow in Steve's conversion, metadata was converted from DUP to
> RAID1 completely, but some portion of system was left as DUP,
> incompletely converted to RAID1. It doesn't seem obvious that -mconvert
> is what he'd use now, but maybe newer btrfs-progs it will also convert
> any unconverted system chunk.
>
> If not, then -sconvert=raid1 -f and optionally -v.
>
> This isn't exactly risk free, given that it requires -f; and I'm not
> sure we can risk assess conversion failure vs the specific drive
> containing system DUP chunks dying. But for me a forced susage balance
> was fast:
>
> [root@rawhide ~]# time btrfs balance start -susage=100 -f -v /
> Dumping filters: flags 0xa, state 0x0, force is on
> SYSTEM (flags 0x2): balancing, usage=100
> Done, had to relocate 1 out of 8 chunks
>
> real 0m0.095s user 0m0.001s sys 0m0.017s
Yes. The one thing that can be said about system chunks is that they're
small enough that processing just them should be quite fast, even on
spinning rust.
So regardless of whether there's a safety issue justifying the required
-f/force for -s/system-only, or not, unlike the possibly many hours a
full balance or some minutes to an hour or so a full balance on a large
spinning rust based btrfs may take, at least if there is some possible
danger in the -s system alone rebalance, the risk-window should be quite
small, time-wise. =:^)
And correspondingly, safety issue or not, I've never seen a report here
of bugs or filesystem loss due to use of -s -f. That doesn't mean it
can't happen, that's under debate and I can't safely say; it does mean
you're pretty unlucky if you're the first to have a need to report such a
thing, here. =:^\
But we all know that btrfs is still under heavy development, and thus
have those tested backups ready just in case, right? In which case, I
think whatever risk there might be relative to that of simply using btrfs
at all at this point in time, must be pretty negligible. =:^) Tho a few
people each year still do get struck by lightening... or win the lottery.
Just living is a risk. <shrug>
--
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:[~2014-04-26 4:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-25 14:57 safe/necessary to balance system chunks? Steve Leung
2014-04-25 17:24 ` Chris Murphy
2014-04-25 18:12 ` Austin S Hemmelgarn
2014-04-25 18:43 ` Steve Leung
2014-04-25 19:07 ` Austin S Hemmelgarn
2014-04-26 4:01 ` Duncan
2014-04-26 1:11 ` Duncan
2014-04-26 1:24 ` Chris Murphy
2014-04-26 2:56 ` Steve Leung
2014-04-26 4:05 ` Chris Murphy
2014-04-26 4:55 ` Duncan
2014-04-25 19:14 ` Hugo Mills
2014-06-19 11:32 ` Alex Lyakas
2014-04-25 23:03 ` Duncan
2014-04-26 1:41 ` Chris Murphy
2014-04-26 4:23 ` Duncan [this message]
2014-04-25 18:36 ` Steve Leung
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$3ed2f$4edb7153$eb405bea$cf2b6b8@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).