All of lore.kernel.org
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: miaox@cn.fujitsu.com, "Piotr Pawłow" <pp@siedziba.pl>,
	"Chris Murphy" <lists@colorremedies.com>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: device balance times
Date: Thu, 23 Oct 2014 07:39:28 -0400	[thread overview]
Message-ID: <5448E8F0.7070004@gmail.com> (raw)
In-Reply-To: <5448C81E.4060701@cn.fujitsu.com>

[-- Attachment #1: Type: text/plain, Size: 1905 bytes --]

On 2014-10-23 05:19, Miao Xie wrote:
> On Wed, 22 Oct 2014 14:40:47 +0200, Piotr Pawłow wrote:
>> On 22.10.2014 03:43, Chris Murphy wrote:
>>> On Oct 21, 2014, at 4:14 PM, Piotr Pawłow<pp@siedziba.pl>  wrote:
>>>> Looks normal to me. Last time I started a balance after adding 6th device to my FS, it took 4 days to move 25GBs of data.
>>> It's long term untenable. At some point it must be fixed. It's way, way slower than md raid.
>>> At a certain point it needs to fallback to block level copying, with a ~ 32KB block. It can't be treating things as if they're 1K files, doing file level copying that takes forever. It's just too risky that another device fails in the meantime.
>>
>> There's "device replace" for restoring redundancy, which is fast, but not implemented yet for RAID5/6.
>
> 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 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.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

  reply	other threads:[~2014-10-23 11:39 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 [this message]
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
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=5448E8F0.7070004@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --cc=miaox@cn.fujitsu.com \
    --cc=pp@siedziba.pl \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.