mbox series

[0/3] Remove deprecated inode cache feature

Message ID 20201126131039.3441290-1-nborisov@suse.com (mailing list archive)
Headers show
Series Remove deprecated inode cache feature | expand

Message

Nikolay Borisov Nov. 26, 2020, 1:10 p.m. UTC
This patchset removes inode cache feature which has been deprecated since kernel
v5.9 release. First 2 patches move code around and replace calls of functions
which are to be removed. Patch 3 finally removes inode cache for good.

I tested this under xfstest and didn't observe any new regressions.

Nikolay Borisov (3):
  btrfs: Move btrfs_find_highest_objectid/btrfs_find_free_objectid to
    disk-io.c
  btrfs: Replace calls to btrfs_find_free_ino with
    btrfs_find_free_objectid
  btrfs: Remove inode cache feature

 fs/btrfs/Makefile           |   2 +-
 fs/btrfs/ctree.h            |  15 +-
 fs/btrfs/disk-io.c          |  78 +++--
 fs/btrfs/disk-io.h          |   2 +
 fs/btrfs/free-space-cache.c | 177 -----------
 fs/btrfs/free-space-cache.h |   6 -
 fs/btrfs/inode-map.c        | 582 ------------------------------------
 fs/btrfs/inode-map.h        |  16 -
 fs/btrfs/inode.c            |  23 +-
 fs/btrfs/ioctl.c            |   1 -
 fs/btrfs/relocation.c       |   1 -
 fs/btrfs/super.c            |   8 -
 fs/btrfs/transaction.c      |  19 --
 fs/btrfs/tree-log.c         |   1 -
 14 files changed, 66 insertions(+), 865 deletions(-)
 delete mode 100644 fs/btrfs/inode-map.c
 delete mode 100644 fs/btrfs/inode-map.h

--
2.25.1

Comments

David Sterba Nov. 26, 2020, 3:31 p.m. UTC | #1
On Thu, Nov 26, 2020 at 03:10:36PM +0200, Nikolay Borisov wrote:
> This patchset removes inode cache feature which has been deprecated since kernel
> v5.9 release. First 2 patches move code around and replace calls of functions
> which are to be removed. Patch 3 finally removes inode cache for good.

There's still the remaining issue what to do with the space occupied by
the cache inode if the feature was enabled. I haven't researched that,
eg. how big the inode is if it's worth removing it at all or if we
should do some lightweight scan to remove them at some appropriate time.
Nikolay Borisov Nov. 26, 2020, 4 p.m. UTC | #2
On 26.11.20 г. 17:31 ч., David Sterba wrote:
> There's still the remaining issue what to do with the space occupied by
> the cache inode if the feature was enabled. I haven't researched that,
> eg. how big the inode is if it's worth removing it at all or if we
> should do some lightweight scan to remove them at some appropriate time.

I'd rather implement this in btrfs-progs.
David Sterba Nov. 27, 2020, 2:58 p.m. UTC | #3
On Thu, Nov 26, 2020 at 06:00:24PM +0200, Nikolay Borisov wrote:
> 
> 
> On 26.11.20 г. 17:31 ч., David Sterba wrote:
> > There's still the remaining issue what to do with the space occupied by
> > the cache inode if the feature was enabled. I haven't researched that,
> > eg. how big the inode is if it's worth removing it at all or if we
> > should do some lightweight scan to remove them at some appropriate time.
> 
> I'd rather implement this in btrfs-progs.

I did a quick check, 1M empty files created then every 7th deleted (so
there are no large ranges to free), resulting in ~140K files and that
occupied about 680KiB. So for 1M files it's about 5M of space, where
metadata part is small (<1KiB), the bitmaps are stored in hidden data
inodes.  All in all it does not sound like a terrible waste of space.