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@xxxxxxxxxx> > > 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?