Re: RAID10 Balancing Request for Comments and Advices

Vincent Olivier
2015-06-17T13:29:22Z

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

> On Jun 17, 2015, at 9:27 AM, Hugo Mills <hugo@carfax.org.uk> wrote:
>
> On Wed, Jun 17, 2015 at 09:13:08AM -0400, Vincent Olivier wrote:
>>
>>> On Jun 16, 2015, at 8:14 PM, Chris Murphy <lists@colorremedies.com> wrote:
>>>
>>> On Tue, Jun 16, 2015 at 5:58 PM, Duncan <1i5t5.duncan@cox.net> wrote:
>>>
>>>> On a current kernel unlike older ones, btrfs actually automates entirely
>>>> empty chunk reclaim, so this problem doesn't occur anything close to near
>>>> as often as it used to. However, it's still possible to have mostly but
>>>> not entirely empty chunks that btrfs won't automatically reclaim. A
>>>> balance can be used to rewrite and combine these mostly empty chunks,
>>>> reclaiming the space saved. This is what Hugo was recommending.
>>>
>>> Yes, as little as a -dusage=5 (data chunks that are 5% or less full)
>>> can clear the problem and is very fast, seconds. Possibly a bit
>>> longer, many seconds o single digit minutes is -dusage=15. I haven't
>>> done a full balance in forever.
>>
>>
>> Yes, on this 80% full 6x4TB RAID10 -dusage=15 took 2 seconds and relocated "0 out of 3026 chunks”.
>>
>> Out of curiosity, I had to use -dusage=90 to have it relocate only 1 chunk and it took les than 30 seconds.
>>
>> So I put a -dusage=25 in the weekly cron just before the scrub.
>
> In most cases, all you need to do is clean up one data chunk to
> give the metadata enough space to work in. Instead of manually
> iterating through several values of usage= until you get a useful
> response, you can use limit=<n> to stop after <n> successful block
> group relocations.

Nice! Will do that instead! Thanks.

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]