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