All of lore.kernel.org
 help / color / mirror / Atom feed
From: Filipe Manana <fdmanana@gmail.com>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 1/2] btrfs: volumes: Return the mapped length for discard
Date: Wed, 23 Oct 2019 10:47:25 +0100	[thread overview]
Message-ID: <CAL3q7H5V0fapMLnznQhHuG8f1myhAdiy42WsUFr-6ryjV7orEQ@mail.gmail.com> (raw)
In-Reply-To: <20191023085037.14838-2-wqu@suse.com>

On Wed, Oct 23, 2019 at 9:53 AM Qu Wenruo <wqu@suse.com> wrote:
>

Hi Qu,

> For btrfs_map_block(), if we pass @op == BTRFS_MAP_DISCARD, the @length
> parameter will not be updated to reflect the real mapped length.
>
> This means for discard operation, we won't know how many bytes are
> really mapped.

Ok, and what's the consequence? The changelog should really say what
is the problem, what the bug is.
The cover letter and the second patch explain what problems are being
solved, but not this change.

>
> Fix this by changing assigning the mapped range length to @length
> pointer, so btrfs_map_block() for BTRFS_MAP_DISCARD also return mapped
> length.
>
> During the change, also do a minor modification to make the length
> calculation a little more straightforward.
> Instead of previously calculated @offset, use "em->end - bytenr" to
> calculate the actually mapped length.

I really don't like much mixing a cleanup with a fix. I would prefer
two separate patches, no matter how small or trivial it is.
>
> Signed-off-by: Qu Wenruo <wqu@suse.com>

Other than that, it looks good to me.
Thanks.

> ---
>  fs/btrfs/volumes.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index cdd7af424033..f66bd0d03f44 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -5578,12 +5578,13 @@ void btrfs_put_bbio(struct btrfs_bio *bbio)
>   * replace.
>   */
>  static int __btrfs_map_block_for_discard(struct btrfs_fs_info *fs_info,
> -                                        u64 logical, u64 length,
> +                                        u64 logical, u64 *length_ret,
>                                          struct btrfs_bio **bbio_ret)
>  {
>         struct extent_map *em;
>         struct map_lookup *map;
>         struct btrfs_bio *bbio;
> +       u64 length = *length_ret;
>         u64 offset;
>         u64 stripe_nr;
>         u64 stripe_nr_end;
> @@ -5616,7 +5617,8 @@ static int __btrfs_map_block_for_discard(struct btrfs_fs_info *fs_info,
>         }
>
>         offset = logical - em->start;
> -       length = min_t(u64, em->len - offset, length);
> +       length = min_t(u64, em->start + em->len - logical, length);
> +       *length_ret = length;
>
>         stripe_len = map->stripe_len;
>         /*
> @@ -6031,7 +6033,7 @@ static int __btrfs_map_block(struct btrfs_fs_info *fs_info,
>
>         if (op == BTRFS_MAP_DISCARD)
>                 return __btrfs_map_block_for_discard(fs_info, logical,
> -                                                    *length, bbio_ret);
> +                                                    length, bbio_ret);
>
>         ret = btrfs_get_io_geometry(fs_info, op, logical, *length, &geom);
>         if (ret < 0)
> --
> 2.23.0
>


-- 
Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”

  reply	other threads:[~2019-10-23  9:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-23  8:50 [PATCH 0/2] btrfs: trim: Fix a bug certain range may not be trimmed properly Qu Wenruo
2019-10-23  8:50 ` [PATCH 1/2] btrfs: volumes: Return the mapped length for discard Qu Wenruo
2019-10-23  9:47   ` Filipe Manana [this message]
2019-10-23  9:51     ` Qu Wenruo
2019-10-23  9:56       ` Filipe Manana
2019-10-23  8:50 ` [PATCH 2/2] btrfs: extent-tree: Ensure we trim ranges across block group boundary Qu Wenruo
2019-10-23  9:51   ` Filipe Manana

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=CAL3q7H5V0fapMLnznQhHuG8f1myhAdiy42WsUFr-6ryjV7orEQ@mail.gmail.com \
    --to=fdmanana@gmail.com \
    --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.