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: 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


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