From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: David Sterba <dsterba@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: start deprecation of mount option inode_cache
Date: Wed, 24 Jun 2020 07:27:46 +0800 [thread overview]
Message-ID: <b8fe50cc-02ed-4170-c84c-d994fd489a98@gmx.com> (raw)
In-Reply-To: <20200623185032.14983-1-dsterba@suse.com>
[-- Attachment #1.1: Type: text/plain, Size: 2142 bytes --]
On 2020/6/24 上午2:50, David Sterba wrote:
> Estimated time of removal of the functionality is 5.11, the option will
> be still parsed but not doing anything.
Great that we don't need to test for a mount option that no one really uses.
>
> Reasons for deprecation and removal:
>
> - very poor naming choice of the mount option, it's supposed to cache
> and reuse the inode _numbers_, but it sounds a some generic cache for
> inodes
>
> - the only known usecase where this option would make sense is on a
> 32bit architecture where inode numbers in one subvolume would be
> exhausted due to 32bit inode::i_ino
>
> - the cache is stored on disk, consumes space, needs to be loaded and
> written back
>
> - new inode number allocation is slower due to lookups into the cache
> (compared to a simple increment which is the default)
>
> - uses the free-space-cache code that is going to be deprecated as well
> in the future
>
> Known problems:
>
> - since 2011, returning EEXIST when there's not enough space in a page
> to store all checksums, see commit 4b9465cb9e38 ("Btrfs: add mount -o
> inode_cache")
>
> Remaining issues:
>
> - if the option was enabled, new inodes created, the option disabled
> again, the cache is still stored on the devices and there's currently
> no way to remove it
What about "btrfs rescue remove-deprecated-feature inode_cache"?
I really don't want kernel to do the hassle.
Thanks,
Qu
>
> Signed-off-by: David Sterba <dsterba@suse.com>
> ---
> fs/btrfs/super.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> index 98fe2a634c70..3f1abbeef66c 100644
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -827,6 +827,8 @@ int btrfs_parse_options(struct btrfs_fs_info *info, char *options,
> }
> break;
> case Opt_inode_cache:
> + btrfs_warn(info,
> + "the 'inode_cache' option is deprecated and will be stop working in 5.11");
> btrfs_set_pending_and_info(info, INODE_MAP_CACHE,
> "enabling inode map caching");
> break;
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-06-23 23:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-23 18:50 [PATCH] btrfs: start deprecation of mount option inode_cache David Sterba
2020-06-23 23:27 ` Qu Wenruo [this message]
2020-06-24 11:00 ` David Sterba
2020-06-24 11:06 ` Qu Wenruo
2020-06-24 7:37 ` Steven Davies
2020-06-24 9:55 ` David Sterba
2020-07-07 17:14 ` David Sterba
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=b8fe50cc-02ed-4170-c84c-d994fd489a98@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=dsterba@suse.com \
--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