Re: [PATCH 0/4] btrfs: Make balance cancelling response faster

Qu Wenruo
2020-02-11T05:24:24Z

[-- Attachment #1.1: Type: text/plain, Size: 1835 bytes --]

On 2019/12/5 上午12:39, David Sterba wrote:
> On Tue, Dec 03, 2019 at 02:42:50PM +0800, Qu Wenruo wrote:
>> [PROBLEM]
>> There are quite some users reporting that 'btrfs balance cancel' slow to
>> cancel current running balance, or even doesn't work for certain dead
>> balance loop.
>>
>> With the following script showing how long it takes to fully stop a
>> balance:
>> #!/bin/bash
>> dev=/dev/test/test
>> mnt=/mnt/btrfs
>>
>> umount $mnt &> /dev/null
>> umount $dev &> /dev/null
>>
>> mkfs.btrfs -f $dev
>> mount $dev -o nospace_cache $mnt
>>
>> dd if=/dev/zero bs=1M of=$mnt/large &
>> dd_pid=$!
>>
>> sleep 3
>> kill -KILL $dd_pid
>> sync
>>
>> btrfs balance start --bg --full $mnt &
>> sleep 1
>>
>> echo "cancel request" >> /dev/kmsg
>> time btrfs balance cancel $mnt
>> umount $mnt
>>
>> It takes around 7~10s to cancel the running balance in my test
>> environment.
>>
>> [CAUSE]
>> Btrfs uses btrfs_fs_info::balance_cancel_req to record how many cancel
>> request are queued.
>> However that cancelling request is only checked after relocating a block
>> group.
>
> Yes that's the reason why it takes so long to cancel. Adding more
> cancellation points is fine, but I don't know what exactly happens when
> the block group relocation is not finished. There's code to merge the
> reloc inode and commit that, but that's only a high-level view of the
> thing.

When cancelled, we still merge the reloc roots with its source (if
possible, as we still do the check for last_snapshot generation).

That means, if balance is canceled halfway, we still merge what is
relocated. Then do the regular cleanup (cleanup the reloc tree).

I see no problem doing faster canceling here.

Or do you have any extra concern?

Thanks,
Qu

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]