From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs balance enospc
Date: Wed, 17 Sep 2014 21:11:50 +0000 (UTC) [thread overview]
Message-ID: <pan$305c3$5abb7bbb$f19e8993$266a8cf0@cox.net> (raw)
In-Reply-To: 5419CA37.1070608@intellasoft.net
Mark Murawski posted on Wed, 17 Sep 2014 13:51:51 -0400 as excerpted:
>> Does/should a balance imply removal of missing devices (as long as
>> the minimum number of devices are still available)?
>
> That's a really good question. As a user I would expect it to balance
> over remaining devices assuming you still have a complete picture. Doing
> a device delete missing after a balance should be just some pool
> metadata updates at that point.
A balance does not imply removal of missing devices. And at this point
I'd say it shouldn't, tho perhaps some day after the code is somewhat
more stable it could.
In fact, until recently kernelspace btrfs (which does all the work in a
balance, userspace is simply the way you tell it what to do) didn't even
properly detect dynamically added/removed devices, resulting in
definitely unintuitive behavior where the balance would still queue up
chunks to be rewritten to the missing device, that would obviously never
be written because the device was missing and wasn't coming back! (!!!)
AFAIK (I'm a sysadmin and list regular, not a developer) that arguably
pathological behavior has been fixed now, at least in theory, and the
kernel should properly detect missing devices and should no longer try to
write to them when doing a balance, so now, at least in theory and
assuming good copies of all data and metadata on the remaining device
from the original pair, a balance to it and a just added device in raid1
mode should leave only the device metadata for btrfs device delete
missing to fix up afterward.
However, as of now, there's still at least two bug reports being traced
down in the dynamic device detection code (see the current thread where
btrfs fi show on a two-device filesystem is pointing to the wrong place
for one of the devices, and another where show says a device is missing,
that isn't), and possibly others yet to be found, so it's not yet a good
idea to have btrfs doing automatic device delete missing on balance.
After the bug fixes are in and the code churn in that area calmed down
for a couple kernel cycles, perhaps then we can debate whether a balance
should automatically delete missing devices when appropriate, or not, but
certainly now isn't isn't the time.
--
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-09-17 21:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <54186A4B.60902@intellasoft.net>
2014-09-16 16:51 ` btrfs balance enospc Mark Murawski
2014-09-16 17:26 ` Chris Murphy
2014-09-16 19:54 ` Mark Murawski
2014-09-16 21:22 ` Chris Murphy
2014-09-16 20:10 ` Kyle Gates
2014-09-17 17:51 ` Mark Murawski
2014-09-17 19:10 ` Chris Murphy
2014-09-17 21:11 ` Duncan [this message]
2014-09-15 15:34 Mark Murawski
2014-09-15 17:07 ` Leonidas Spyropoulos
2014-09-15 17:37 ` Mark Murawski
2014-09-15 20:54 ` Chris Murphy
2014-09-15 22:40 ` Mark Murawski
2014-09-16 0:08 ` Duncan
2014-09-16 1:19 ` Chris Murphy
2014-09-16 2:23 ` Mark Murawski
2014-09-16 16:37 ` Duncan
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$305c3$5abb7bbb$f19e8993$266a8cf0@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).