From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Qu Wenruo <wqu@suse.com>, linux-btrfs@vger.kernel.org
Cc: dsterba@suse.cz
Subject: Re: [PATCH RESEND 1/2] btrfs: Enhance btrfs_trim_fs function to handle error better
Date: Sun, 1 Apr 2018 18:35:17 +0800 [thread overview]
Message-ID: <4befd8e2-c6e6-a3cb-2d38-9a3c9739a32e@gmx.com> (raw)
In-Reply-To: <20171128070830.12756-1-wqu@suse.com>
[-- Attachment #1.1: Type: text/plain, Size: 5068 bytes --]
Gentle ping?
The patch is small and (with its 2nd patch) should fix trim behavior
inside block groups.
Thanks,
Qu
On 2017年11月28日 15:08, Qu Wenruo wrote:
> Function btrfs_trim_fs() doesn't handle errors in a consistent way, if
> error happens when trimming existing block groups, it will skip the
> remaining blocks and continue to trim unallocated space for each device.
>
> And the return value will only reflect the final error from device
> trimming.
>
> This patch will fix such behavior by:
>
> 1) Recording first error from block group or device trimming
> So return value will also reflect any error found when trimming.
> Make developer more aware of the problem.
>
> 2) Outputting btrfs warning message for each trimming failure
> Any error for block group or device trimming will cause btrfs warning
> kernel message.
>
> 3) Continuing trimming if we can
> If we failed to trim one block group or device, we could still try
> next block group or device.
>
> Such behavior can avoid confusion for case like failure to trim the
> first block group and then only unallocated space is trimmed.
>
> Reported-by: Chris Murphy <lists@colorremedies.com>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
> fs/btrfs/extent-tree.c | 59 ++++++++++++++++++++++++++++++++++++--------------
> 1 file changed, 43 insertions(+), 16 deletions(-)
>
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index 673ac4e01dd0..f830aa91ac3d 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -10948,6 +10948,16 @@ static int btrfs_trim_free_extents(struct btrfs_device *device,
> return ret;
> }
>
> +/*
> + * Trim the whole fs, by:
> + * 1) Trimming free space in each block group
> + * 2) Trimming unallocated space in each device
> + *
> + * Will try to continue trimming even if we failed to trim one block group or
> + * device.
> + * The return value will be the error return value of the first error.
> + * Or 0 if nothing wrong happened.
> + */
> int btrfs_trim_fs(struct btrfs_fs_info *fs_info, struct fstrim_range *range)
> {
> struct btrfs_block_group_cache *cache = NULL;
> @@ -10958,6 +10968,8 @@ int btrfs_trim_fs(struct btrfs_fs_info *fs_info, struct fstrim_range *range)
> u64 end;
> u64 trimmed = 0;
> u64 total_bytes = btrfs_super_total_bytes(fs_info->super_copy);
> + int bg_ret = 0;
> + int dev_ret = 0;
> int ret = 0;
>
> /*
> @@ -10968,7 +10980,7 @@ int btrfs_trim_fs(struct btrfs_fs_info *fs_info, struct fstrim_range *range)
> else
> cache = btrfs_lookup_block_group(fs_info, range->start);
>
> - while (cache) {
> + for (; cache; cache = next_block_group(fs_info, cache)) {
> if (cache->key.objectid >= (range->start + range->len)) {
> btrfs_put_block_group(cache);
> break;
> @@ -10982,29 +10994,36 @@ int btrfs_trim_fs(struct btrfs_fs_info *fs_info, struct fstrim_range *range)
> if (!block_group_cache_done(cache)) {
> ret = cache_block_group(cache, 0);
> if (ret) {
> - btrfs_put_block_group(cache);
> - break;
> + btrfs_warn_rl(fs_info,
> + "failed to cache block group %llu ret %d",
> + cache->key.objectid, ret);
> + if (!bg_ret)
> + bg_ret = ret;
> + continue;
> }
> ret = wait_block_group_cache_done(cache);
> if (ret) {
> - btrfs_put_block_group(cache);
> - break;
> + btrfs_warn_rl(fs_info,
> + "failed to wait cache for block group %llu ret %d",
> + cache->key.objectid, ret);
> + if (!bg_ret)
> + bg_ret = ret;
> + continue;
> }
> }
> - ret = btrfs_trim_block_group(cache,
> - &group_trimmed,
> - start,
> - end,
> - range->minlen);
> + ret = btrfs_trim_block_group(cache, &group_trimmed,
> + start, end, range->minlen);
>
> trimmed += group_trimmed;
> if (ret) {
> - btrfs_put_block_group(cache);
> - break;
> + btrfs_warn_rl(fs_info,
> + "failed to trim block group %llu ret %d",
> + cache->key.objectid, ret);
> + if (!bg_ret)
> + bg_ret = ret;
> + continue;
> }
> }
> -
> - cache = next_block_group(fs_info, cache);
> }
>
> mutex_lock(&fs_info->fs_devices->device_list_mutex);
> @@ -11012,15 +11031,23 @@ int btrfs_trim_fs(struct btrfs_fs_info *fs_info, struct fstrim_range *range)
> list_for_each_entry(device, devices, dev_alloc_list) {
> ret = btrfs_trim_free_extents(device, range->minlen,
> &group_trimmed);
> - if (ret)
> + if (ret) {
> + btrfs_warn_rl(fs_info,
> + "failed to trim unallocated space for devid %llu ret %d",
> + device->devid, ret);
> + if (!dev_ret)
> + dev_ret = ret;
> break;
> + }
>
> trimmed += group_trimmed;
> }
> mutex_unlock(&fs_info->fs_devices->device_list_mutex);
>
> range->len = trimmed;
> - return ret;
> + if (bg_ret)
> + return bg_ret;
> + return dev_ret;
> }
>
> /*
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2018-04-01 10:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-28 7:08 [PATCH RESEND 1/2] btrfs: Enhance btrfs_trim_fs function to handle error better Qu Wenruo
2017-11-28 7:08 ` [PATCH v2 2/2] btrfs: Ensure btrfs_trim_fs can trim the whole fs Qu Wenruo
2017-11-28 7:20 ` [PATCH v2.1 " Qu Wenruo
2017-11-29 20:28 ` Holger Hoffstätte
2017-11-30 0:45 ` [PATCH v2.2 " Qu Wenruo
2018-04-01 10:35 ` Qu Wenruo [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-04-04 6:15 [PATCH RESEND 1/2] btrfs: Enhance btrfs_trim_fs function to handle error better 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=4befd8e2-c6e6-a3cb-2d38-9a3c9739a32e@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).