All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 0/4] btrfs: Make balance cancelling response faster
Date: Wed, 4 Dec 2019 17:39:54 +0100	[thread overview]
Message-ID: <20191204163954.GG2734@twin.jikos.cz> (raw)
In-Reply-To: <20191203064254.22683-1-wqu@suse.com>

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.

  parent reply	other threads:[~2019-12-04 16:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-03  6:42 [PATCH 0/4] btrfs: Make balance cancelling response faster Qu Wenruo
2019-12-03  6:42 ` [PATCH 1/4] btrfs: relocation: Introduce error injection points for cancelling balance Qu Wenruo
2019-12-03 13:29   ` Johannes Thumshirn
2019-12-03  6:42 ` [PATCH 2/4] btrfs: relocation: Check cancel request after each data page read Qu Wenruo
2019-12-03  6:42 ` [PATCH 3/4] btrfs: relocation: Check cancel request after each extent found Qu Wenruo
2019-12-03  6:42 ` [PATCH 4/4] btrfs: relocation: Work around dead relocation stage loop Qu Wenruo
2019-12-04 16:39 ` David Sterba [this message]
2020-02-11  5:21   ` [PATCH 0/4] btrfs: Make balance cancelling response faster Qu Wenruo
2020-02-11  5:35     ` Qu Wenruo
2019-12-05  2:58 ` Zygo Blaxell
2019-12-05  3:26   ` Qu Wenruo
  -- strict thread matches above, loose matches on Subject: below --
2019-12-03  6:24 Qu Wenruo

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=20191204163954.GG2734@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.com \
    /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.