Re: [PATCH RFC DRAFT DOESNOTBUILD] inode: free up more space

Christian Brauner
2025-07-16T09:50:55Z

On Wed, Jul 16, 2025 at 11:15:48AM +0200, Jan Kara wrote:
> On Tue 15-07-25 16:35:24, Christian Brauner wrote:
> > struct inode is bloated as everyone is aware and we should try and
> > shrink it as that's potentially a lot of memory savings. I've already
> > freed up around 8 bytes but we can probably do better.
> >
> > There's a bunch of stuff that got shoved into struct inode that I don't
> > think deserves a spot in there. There are two members I'm currently
> > particularly interested in:
> >
> > (1) #ifdef CONFIG_FS_ENCRYPTION
> > struct fscrypt_inode_info *i_crypt_info;
> > #endif
> >
> > ceph, ext4, f2fs, ubifs
> >
> > (2) #ifdef CONFIG_FS_VERITY
> > struct fsverity_info *i_verity_info;
> > #endif
> >
> > btrfs, ext4, f2fs
> >
> > So we have 4 users for fscrypt and 3 users for fsverity with both
> > features having been around for a decent amount of time.
> >
> > For all other filesystems the 16 bytes are just wasted bloating inodes
> > for every pseudo filesystem and most other regular filesystems.
> >
> > We should be able to move both of these out of struct inode by adding
> > inode operations and making it the filesystem's responsibility to
> > accommodate the information in their respective inodes.
> >
> > Unless there are severe performance penalties for the extra pointer
> > dereferences getting our hands on 16 bytes is a good reason to at least
> > consider doing this.
> >
> > I've drafted one way of doing this using ext4 as my victim^wexample. I'd
> > like to hear some early feedback whether this is something we would want
> > to pursue.
> >
> > Build failures very much expected!
> >
> > Not-Signed-off-by: Christian Brauner <brauner@kernel.org>
>
> I like the concept. I went that way with quota info attached to the inode
> as well. Just for quota info I've put the .get_dquots hook into
> super_operations because in practice all inodes in a superblock have to
> have a common memory layout anyway. OTOH inode_operations are one deference
> closer so maybe they are a better fit? Anyway, all I wanted to say is that

Imho, move it to inode operations. I think that's the better fit for
quotas. It's easier to see what types of actual meaningful filesystem
operations inodes actually support. I'm not to worried about having a
lot of methods on i_op (yet). Thoughts?