linux-btrfs.vger.kernel.org archive mirror
 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>, dsterba@suse.cz
Subject: Re: [PATCH 2/5] btrfs: Always limit inline extent size by uncompressed size
Date: Fri, 2 Mar 2018 10:46:46 +0000	[thread overview]
Message-ID: <CAL3q7H68aJYeTtU=-sSeMvfxSiQ_Fda4N2o-On2x9tWexRG9bg@mail.gmail.com> (raw)
In-Reply-To: <20180302052254.7059-3-wqu@suse.com>

On Fri, Mar 2, 2018 at 5:22 AM, Qu Wenruo <wqu@suse.com> wrote:
> Normally when specifying max_inline, we should normally limit it by
> uncompressed extent size, as it's the only thing user can control.

Why does it matter that users can control it? Will they write less (or
more) data to files because stuff won't get inlined?
Why do they care about stuff getting inlined or not? That's an
implementation detail of btrfs to speed up access to file data and
save some space.

> (Control the algorithm and compressed data is almost impossible)
>
> Since btrfs is providing *TRANSPARENT* compression, max_inline should
> behave the same for both plain and compress data.

Taking away the benefits of compression for. So now some cases that
ended up getting the benefits of inlining won't get them anymore.

I don't agree with this change.

>
> So this patch will use @inline_len instead of @data_len in
> cow_file_range_inline() so user will know their max_inline mount option
> works exactly the same for both plain and compressed data extent.
>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
>  fs/btrfs/inode.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> index e1a7f3cb5be9..48472509239b 100644
> --- a/fs/btrfs/inode.c
> +++ b/fs/btrfs/inode.c
> @@ -303,7 +303,7 @@ static noinline int cow_file_range_inline(struct btrfs_root *root,
>             (!compressed_size &&
>             (actual_end & (fs_info->sectorsize - 1)) == 0) ||
>             end + 1 < isize ||
> -           data_len > fs_info->max_inline) {
> +           inline_len > fs_info->max_inline) {
>                 return 1;
>         }
>
> --
> 2.16.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Filipe David Manana,

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

  reply	other threads:[~2018-03-02 10:46 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-02  5:22 [PATCH 0/5] max_inline related enhancement Qu Wenruo
2018-03-02  5:22 ` [PATCH 1/5] btrfs: Parse options after node/sector size initialized Qu Wenruo
2018-03-07 15:20   ` David Sterba
2018-03-02  5:22 ` [PATCH 2/5] btrfs: Always limit inline extent size by uncompressed size Qu Wenruo
2018-03-02 10:46   ` Filipe Manana [this message]
2018-03-02 10:54     ` Qu Wenruo
2018-03-02 11:00       ` Filipe Manana
2018-03-02 11:40         ` Qu Wenruo
2018-03-06 11:58           ` David Sterba
2018-03-06 12:08             ` Qu Wenruo
2018-03-02  5:22 ` [PATCH 3/5] btrfs: Embed sector size check into BTRFS_MAX_INLINE_DATA_SIZE() Qu Wenruo
2018-03-06 12:34   ` David Sterba
2018-03-02  5:22 ` [PATCH 4/5] btrfs: Unify inline extent creation condition for plain and compressed data Qu Wenruo
2018-03-02  5:22 ` [PATCH 5/5] btrfs: Show more accurate max_inline Qu Wenruo
2018-03-02  8:21   ` Misono, Tomohiro
2018-03-02  8:33     ` Nikolay Borisov
2018-03-02  8:34     ` Qu Wenruo
2018-03-02  8:37       ` Nikolay Borisov
2018-03-02 10:57         ` Qu Wenruo
2018-03-02  8:13 ` [PATCH 0/5] max_inline related enhancement Nikolay Borisov

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='CAL3q7H68aJYeTtU=-sSeMvfxSiQ_Fda4N2o-On2x9tWexRG9bg@mail.gmail.com' \
    --to=fdmanana@gmail.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).