linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Cc: dsterba@suse.cz
Subject: [PATCH 0/5] max_inline related enhancement
Date: Fri,  2 Mar 2018 13:22:49 +0800	[thread overview]
Message-ID: <20180302052254.7059-1-wqu@suse.com> (raw)

This patchset intends to reduce confusion about "max_inline" mount
option.

The max_inline mount option has the following problems:

1) Different behavior for plain and compressed data extent
   For plain data extent, it's limiting the extent data size, and will
   never reach sector size.
   For compressed data extent, it's limiting the compressed data size,
   and compressed data size can reach sector size.

   The compressed behavior is very confusing for normal user, as it's
   almost impossible for end user to know if their operation will end up
   inlined or no inlined.

2) Inaccurate max inline output
   Passing max_inline=4096 and kernel will prompt max_inline is 4096,
   but we still don't allow inline plain data extent to reach 4096.

3) Symbol link can exceed sector size for its inlined data
   Since btrfs_symlink() is calling BTRFS_MAX_INLINE_DATA_SIZE()
   directly without extra truncation.

This patchset will fixes such problems by:

1) Limit both plain and compressed inline extent size by uncompressed
   data size
   So user know exactly what will end up on-disk, just by checking the data
   size.

2) Output max inline size by limiting it to BTRFS_MAX_INLINE_DATA_SIZE()
   other than sector size.

3) Embed sector size check into BTRFS_MAX_INLINE_DATA_SIZE()
   So now btrfs_symlink() won't create any inline extent larger than
   page size.
   (Only affects later operations, and can still read such existing
    symbol link)

Qu Wenruo (5):
  btrfs: Parse options after node/sector size initialized
  btrfs: Always limit inline extent size by uncompressed size
  btrfs: Embed sector size check into BTRFS_MAX_INLINE_DATA_SIZE()
  btrfs: Unify inline extent creation condition for plain and compressed
    data
  btrfs: Show more accurate max_inline

 fs/btrfs/ctree.h   |  5 +++--
 fs/btrfs/disk-io.c | 13 +++++++------
 fs/btrfs/inode.c   |  5 +----
 fs/btrfs/super.c   |  4 ++--
 4 files changed, 13 insertions(+), 14 deletions(-)

-- 
2.16.2


             reply	other threads:[~2018-03-02  5:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-02  5:22 Qu Wenruo [this message]
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
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=20180302052254.7059-1-wqu@suse.com \
    --to=wqu@suse.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    /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).