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