From: David Sterba <dsterba@suse.cz>
To: Luca Stefani <luca.stefani.ge1@gmail.com>
Cc: Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 2/2] btrfs: Don't block system suspend during fstrim
Date: Tue, 17 Sep 2024 18:24:31 +0200 [thread overview]
Message-ID: <20240917162431.GC2920@twin.jikos.cz> (raw)
In-Reply-To: <20240916125707.127118-3-luca.stefani.ge1@gmail.com>
On Mon, Sep 16, 2024 at 02:56:15PM +0200, Luca Stefani wrote:
> Sometimes the system isn't able to suspend because the task
> responsible for trimming the device isn't able to finish in
> time, especially since we have a free extent discarding phase,
> which can trim a lot of unallocated space, and there is no
> limits on the trim size (unlike the block group part).
>
> Since discard isn't a critical call it can be interrupted
> at any time, in such cases we stop the trim, report the amount
> of discarded bytes and return failure.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=219180
> Link: https://bugzilla.suse.com/show_bug.cgi?id=1229737
> Signed-off-by: Luca Stefani <luca.stefani.ge1@gmail.com>
I went through the cancellation points, some of them don't seem to be
necessary, eg. in a big loop when some function is called to do trim
(extents, bitmaps) and then again does the signal and freezing check.
Next, some of the functions are called from async discard and errors are
not checked: btrfs_trim_block_group_bitmaps() called from
btrfs_discard_workfn().
Ther's also check for signals pending in trim_bitmaps() in
free-space-cache.c. Given that the space cache code is on the way out we
don't necesssarily need to fix it but if the patch gets backported to
older kernels it still makes sense.
> ---
> fs/btrfs/extent-tree.c | 23 ++++++++++++++++++++++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index 79b9243c9cd6..cef368a30731 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -16,6 +16,7 @@
> #include <linux/percpu_counter.h>
> #include <linux/lockdep.h>
> #include <linux/crc32c.h>
> +#include <linux/freezer.h>
> #include "ctree.h"
> #include "extent-tree.h"
> #include "transaction.h"
> @@ -1235,6 +1236,11 @@ static int remove_extent_backref(struct btrfs_trans_handle *trans,
> return ret;
> }
>
> +static bool btrfs_trim_interrupted(void)
> +{
> + return fatal_signal_pending(current) || freezing(current);
> +}
> +
> static int btrfs_issue_discard(struct block_device *bdev, u64 start, u64 len,
> u64 *discarded_bytes)
> {
> @@ -1316,6 +1322,11 @@ static int btrfs_issue_discard(struct block_device *bdev, u64 start, u64 len,
> start += bytes_to_discard;
> bytes_left -= bytes_to_discard;
> *discarded_bytes += bytes_to_discard;
> +
> + if (btrfs_trim_interrupted()) {
> + ret = -ERESTARTSYS;
> + break;
> + }
> }
>
> return ret;
> @@ -6470,7 +6481,7 @@ static int btrfs_trim_free_extents(struct btrfs_device *device, u64 *trimmed)
> start += len;
> *trimmed += bytes;
>
> - if (fatal_signal_pending(current)) {
> + if (btrfs_trim_interrupted()) {
> ret = -ERESTARTSYS;
> break;
> }
> @@ -6519,6 +6530,11 @@ int btrfs_trim_fs(struct btrfs_fs_info *fs_info, struct fstrim_range *range)
>
> cache = btrfs_lookup_first_block_group(fs_info, range->start);
> for (; cache; cache = btrfs_next_block_group(cache)) {
> + if (btrfs_trim_interrupted()) {
> + bg_ret = -ERESTARTSYS;
> + break;
> + }
> +
> if (cache->start >= range_end) {
> btrfs_put_block_group(cache);
> break;
> @@ -6558,6 +6574,11 @@ int btrfs_trim_fs(struct btrfs_fs_info *fs_info, struct fstrim_range *range)
>
> mutex_lock(&fs_devices->device_list_mutex);
> list_for_each_entry(device, &fs_devices->devices, dev_list) {
> + if (btrfs_trim_interrupted()) {
> + dev_ret = -ERESTARTSYS;
This one seems redundant.
> + break;
> + }
> +
> if (test_bit(BTRFS_DEV_STATE_MISSING, &device->dev_state))
> continue;
>
> --
> 2.46.0
>
next prev parent reply other threads:[~2024-09-17 16:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-16 12:56 [PATCH v5 0/2] " Luca Stefani
2024-09-16 12:56 ` [PATCH v5 1/2] btrfs: Split remaining space to discard in chunks Luca Stefani
2024-09-17 16:25 ` David Sterba
2024-09-16 12:56 ` [PATCH v5 2/2] btrfs: Don't block system suspend during fstrim Luca Stefani
2024-09-17 16:24 ` David Sterba [this message]
2024-09-17 17:38 ` Luca Stefani
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=20240917162431.GC2920@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.stefani.ge1@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®