linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).