On Thu, Jul 17, 2025 at 12:54:48PM +0200, Jan Kara wrote:
> On Thu 17-07-25 10:32:07, Christian Brauner wrote:
> > On Wed, Jul 16, 2025 at 04:10:30PM +0200, Christoph Hellwig wrote:
> > > On Wed, Jul 16, 2025 at 03:08:53PM +0100, Matthew Wilcox wrote:
> > > > struct filemap_inode {
> > > > struct inode inode;
> > > > struct address_space i_mapping;
> > > > struct fscrypt_struct i_fscrypt;
> > > > struct fsverity_struct i_fsverity;
> > > > struct quota_struct i_quota;
> > > > };
> > > >
> > > > struct ext4_inode {
> > > > struct filemap_inode inode;
> > > > ...
> > > > };
> > > >
> > > > saves any messing with i_ops and offsets.
> > >
> > > I still wastest a lot of space for XFS which only needs inode
> > > and i_mapping of those. As would most ext4 file systems..
> >
> > We can do a hybrid approach:
> >
> > diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> > index 2bc6a3ac2b8e..dda45b3f2122 100644
> > --- a/fs/ext4/ext4.h
> > +++ b/fs/ext4/ext4.h
> > @@ -1198,9 +1198,7 @@ struct ext4_inode_info {
> >
> > kprojid_t i_projid;
> >
> > -#ifdef CONFIG_FS_ENCRYPTION
> > - struct fscrypt_inode_info *i_fscrypt_info;
> > -#endif
> > + struct vfs_inode_adjunct i_adjunct; /* Adjunct data for inode */
> > };
>
> Well, but if we moved also fsverity & quota & what not into
> vfs_inode_adjunct the benefit of such structure would be diminishing? Or
> am I misunderstanding the proposal? I think that the new method should
> strive for each filesystem inode to store only the info it needs and not
> waste space for things it isn't interested in.
The benefit will still be there for any filesystem that doesn't care
about any of it which is most of them. One could also just split this up
into topics: fsverity & fscrypt, quota likely separately, and then other
stuff. But we can also just do that later and start with splitting it
individually.
