From: Zygo Blaxell <zblaxell@furryterror.org>
To: Duncan <1i5t5.duncan@cox.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: device balance times
Date: Fri, 24 Oct 2014 11:18:07 -0400 [thread overview]
Message-ID: <20141024151807.GF17395@hungrycats.org> (raw)
In-Reply-To: <pan$e118d$d880428d$ebc41b4b$dabf1c21@cox.net>
[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]
On Fri, Oct 24, 2014 at 05:13:27AM +0000, Duncan wrote:
> Zygo Blaxell posted on Thu, 23 Oct 2014 22:35:29 -0400 as excerpted:
>
> > My pet peeve: if balance is converting profiles from RAID1 to single,
> > the conversion should be *instantaneous* (or at least small_constant *
> > number_of_block_groups). Pick one mirror, keep all the chunks on that
> > mirror, delete all the corresponding chunks on the other mirror.
>
> That would argue for either a third balance mode, --convert-only, or a
> different tool, avoiding a rewrite of existing chunks entirely, simply
> replicating them if adding redundancy or deleting a copy if reducing it,
> as necessary.
Isn't that what soft does? [reading noises] OK, maybe not.
'soft' leaves a chunk alone if it already fits all the target profile
requirements; however, in this case the profile (and only the profile,
no data) is changing.
I think just two modes are sufficient: one that does everything the most
thorough way (throw scrub and defrag in there too, so we can do a single
pass over the filesystem that does all the maintenance tasks at once),
and one that takes advantage of every special-case shortcut available
to achieve specific goals in the shortest time.
I also think it's a little odd that conversion and balance are the
same tool. Traditional RAID conversions don't care about filesystem
layout, because they work on a completely separate layer (i.e. at the
block level). It's certainly possible to perform a RAID conversion
by reallocating all the filesystem-level objects, but just because
you can doesn't mean you should. ;)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2014-10-24 15:18 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
2014-10-24 2:35 ` Zygo Blaxell
2014-10-24 5:13 ` Duncan
2014-10-24 15:18 ` Zygo Blaxell [this message]
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=20141024151807.GF17395@hungrycats.org \
--to=zblaxell@furryterror.org \
--cc=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).