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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux