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: Replace missing disc => strange result!?
Date: Fri, 11 Aug 2017 00:39:04 +0000 (UTC)	[thread overview]
Message-ID: <pan$efeee$bd714cab$37822ac5$dd8b65e2@cox.net> (raw)
In-Reply-To: 1502395208.3361.1.camel@cloud.haefemeier.eu

Cloud Admin posted on Thu, 10 Aug 2017 22:00:08 +0200 as excerpted:

> Hi,
> I had a disc failure and must replace it. I followed the description on
>  https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devi
> ces and started the replacement.
> Setup is a two disc RAID1!
> After it was done, I called 'btrfs fi us /mn/btrfsroot' and I got the
> output below. What is wrong?
> Is it a rebalancing issue? I thought the replace command started it
> automatically...

...
 
> Data,single: Size:1.00GiB, Used:0.00B
>    /dev/mapper/luks-3ff6c412-4d3a-4d33-85a3-cc70e95c26f8	   1.00
> GiB

...

It's not entirely clear what you're referring to with the "what's wrong" 
question, but I'll assume it's all those single and dup chunks that 
aren't raid1.

Unlike device delete, which does an implicit rebalance, replace simply 
replaces one device with another in terms of content, and doesn't 
rebalance anything on remaining devices.  This tends to make it much 
faster, with less danger of something else bad (like another device going 
bad) happening in the process, but it pretty much copies verbatim as much 
as possible so unlike device delete with its implicit balance or an 
explicit balance, existing chunks remain as they were.

Which means any existing single and dup chunks didn't get removed, as I'm 
guessing you expected.

But most or all of them are 0 used, so an explicit rebalance to eliminate 
them should be quite short as it'll just delete the references to them.  
Try this (path from your post above):

btrfs balance start -dusage=0 -musage=0 /mn/btrfsroot

That should eliminate the 0-usage chunks, making the usage output easier 
to follow even if you do need to post updates because my guess as to what 
you were referring to with the "what's wrong" was incorrect.  And as I 
said it should be much faster (almost instantaneous on ssd, probably not 
/quite/ that on spinning rust) than rebalancing chunks that weren't 
empty, too.  =:^)

-- 
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:[~2017-08-11  0:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-10 20:00 Replace missing disc => strange result!? Cloud Admin
2017-08-11  0:39 ` 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$efeee$bd714cab$37822ac5$dd8b65e2@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).