From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: device balance times
Date: Fri, 24 Oct 2014 01:05:39 +0000 (UTC) [thread overview]
Message-ID: <pan$d3176$38668d14$9f498698$7cd4113f@cox.net> (raw)
In-Reply-To: 5448E8F0.7070004@gmail.com
Austin S Hemmelgarn posted on Thu, 23 Oct 2014 07:39:28 -0400 as
excerpted:
> On 2014-10-23 05:19, Miao Xie wrote:
>>
>> Now my colleague and I is implementing the scrub/replace for RAID5/6
>> and I have a plan to reimplement the balance and split it off from the
>> metadata/file data process. the main idea is
>> - allocate a new chunk which has the same size as the relocated one,
>> but don't insert it into the block group list, so we don't allocate
>> the free space from it.
>> - set the source chunk to be Read-only
>> - copy the data from the source chunk to the new chunk
>> - replace the extent map of the source chunk with the one of the new
>> chunk(The new chunk has the same logical address and the length as
>> the old one)
>> - release the source chunk
>>
>> By this way, we needn't deal the data one extent by one extent, and
>> needn't do any space reservation, so the speed will be very fast even
>> [if] we have lots of snapshots.
>>
> Even if balance gets re-implemented this way, we should still provide
> some way to consolidate the data from multiple partially full chunks.
> Maybe keep the old balance path and have some option (maybe call it
> aggressive?) that turns it on instead of the new code.
IMO:
* Keep normal default balance behavior as-is.
* Add two new options, --fast, and --aggressive.
* --aggressive behaves as today and is the normal default.
* --fast is the new chunk-by-chunk behavior. This becomes the default if
the convert filter is used, or if balance detects that it /is/ changing
the mode, thus converting or filling in missing chunk copies, even when
the convert filter was not specifically set. Thus, if there's only one
chunk copy (single or raid0 mode, or raid1/10 or dup with a missing/
invalid copy) and the balance would result in two copies, default to
--fast. Similarly, if it's raid1/10 and switching to single/raid0,
default to --fast. If no conversion is being done, keep the normal
--aggressive default.
* Users could always specify the behavior they want, overriding the
default, using the appropriate option.
* Of course defaults may result in some chunks being rebalanced in fast
mode, while others are rebalanced in aggressive mode, if for instance
it's 3+ device raid1 mode filesystem with one device missing, since in
that case there'd be the usual two copies of some chunks and those would
default to aggressive, while there'd be one copy of chunks where the
other one was on the missing device. However, users could always specify
the desired behavior using the last point above, thus getting the same
behavior for the entire balance.
--
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-10-24 1:05 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-21 18:59 device balance times Tomasz Chmielewski
2014-10-21 20:14 ` Piotr Pawłow
2014-10-21 20:44 ` Arnaud Kapp
2014-10-22 1:10 ` 5 _thousand_ snapshots? even 160? (was: device balance times) Robert White
2014-10-22 4:02 ` Zygo Blaxell
2014-10-22 4:05 ` Duncan
2014-10-23 20:38 ` 5 _thousand_ snapshots? even 160? Arnaud Kapp
2014-10-22 11:30 ` Austin S Hemmelgarn
2014-10-22 17:32 ` Goffredo Baroncelli
2014-10-22 11:22 ` device balance times Austin S Hemmelgarn
2014-10-22 1:43 ` Chris Murphy
2014-10-22 12:40 ` Piotr Pawłow
2014-10-22 16:59 ` Bob Marley
2014-10-23 7:39 ` Russell Coker
2014-10-23 8:49 ` Duncan
2014-10-23 9:19 ` Miao Xie
2014-10-23 11:39 ` Austin S Hemmelgarn
2014-10-24 1:05 ` Duncan [this message]
2014-10-24 2:35 ` Zygo Blaxell
2014-10-24 5:13 ` Duncan
2014-10-24 15:18 ` Zygo Blaxell
2014-10-24 10:58 ` Rich Freeman
2014-10-24 16:07 ` Zygo Blaxell
2014-10-24 19:58 ` Rich Freeman
2014-10-22 16:15 ` Chris Murphy
2014-10-23 2:44 ` 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$d3176$38668d14$9f498698$7cd4113f@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).