Re: Rebalancing raid1 after adding a device

["Stéphane Lesimple" <stephane_btrfs@lesimple.fr>]

June 18, 2019 9:06 PM, "Austin S. Hemmelgarn" <ahferroin7@gmail.com> wrote:

> On 2019-06-18 14:26, Stéphane Lesimple wrote:
>
> [...] 
>
>> I don't need to have a perfectly balanced FS, I just want all the space > to be allocatable.
>> I tried using the -ddevid option but it only instructs btrfs to work on > the block groups
>> allocated on said device, as it happens, it tends to > move data between the 4 preexisting devices
>> and doesn't fix my problem. > A full balance with -dlimit=100 did no better.
>> Is there a way to ask the block group allocator to prefer writing to a > specific device during a
>> balance? Something like -ddestdevid=N? This > would just be a hint to the allocator and the usual
>> constraints would > always apply (and prevail over the hint when needed).
>> Or is there any obvious solution I'm completely missing?
> 
> Based on what you've said, you may actually not have enough free space that can be allocated to
> balance things properly.
> 
> When a chunk gets balanced, you need to have enough space to create a new instance of that type of
> chunk before the old one is removed. As such, if you can't allocate new chunks at all, you can't
> balance those chunks either.
> 
> So, that brings up the question of how to deal with your situation.
> 
> The first thing I would do is multiple compaction passes using the `usage` filter. Start with:
> 
> btrfs balance -dusage=0 -musage=0 /wherever
> 
> That will clear out any empty chunks which haven't been removed (there shouldn't be any if you're
> on a recent kernel, but it's good practice anyway). After that, repeat the same command, but with a
> value of 10 instead of 0, and then keep repeating in increments of 10 up until 50. Doing this will
> clean up chunks that are more than half empty (making multiple passes like this is a bit more
> reliable, and in some cases also more efficient), which should free up enough space for balance to
> work with (as well as probably moving most of the block groups it touches to use the new disk).

Fair point, I do run some balances with -dusage=20 from time to time, the current state of the FS
is actually as follows:

btrfs d u /tank | grep Unallocated:
   Unallocated:            57.45GiB
   Unallocated:             4.58TiB <= new 10T
   Unallocated:            16.03GiB
   Unallocated:            63.49GiB
   Unallocated:            69.52GiB

As you can see I was able to move some data to the new 10T drive in the last few days, mainly by
trial/error with several -ddevid and -dlimit parameters. As of now I still have 4.38T that are
unallocatable, out of the 4.58T that are unallocated on the new drive. I was looking for a better
solution that just running a full balance (with or without -devid=old10T) by asking btrfs to
balance data to the new drive, but it seems there's no way to instruct btrfs to do that.

I think I'll still run a -dusage pass before doing the full balance indeed, can't hurt.

-- 
Stéphane.