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

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

[Christoph Hellwig]

On Fri, Jul 18, 2025 at 10:24:47AM +0200, Christian Brauner wrote:
> We can't just keep accumulating more and more stuff in our core
> structures. The bpf people are breathing down our neck to put more
> things in struct inode and I'm sure the next thingamabob is already in
> the works and we need a way to push such stuff out of core struct inode.

Agreed.  And as mentioned I'like to think even further and avoid
having these optional bits in the fs inode unconditionally if there
isn't a good reason for that.  I mentioned quotas before, but an even
more extreme case is fsverity.  If I understand the fsverity use case
correctly it is usually used for a very small number of files in the
system only, and you'd usually do bulk reads from them.  So instead of
bloating the inode, be that the generic one or that of the file systems
that use it, why not have a global rhastable index by the inode address
to look it up?  Compared to the actual hash generation and verification
a lockless hashlookup is complete noise, but we'll save a lot of
memory.

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

[Christian Brauner]

On Fri, Jul 18, 2025 at 10:32:06AM +0200, Christoph Hellwig wrote:
> On Fri, Jul 18, 2025 at 10:24:47AM +0200, Christian Brauner wrote:
> > We can't just keep accumulating more and more stuff in our core
> > structures. The bpf people are breathing down our neck to put more
> > things in struct inode and I'm sure the next thingamabob is already in
> > the works and we need a way to push such stuff out of core struct inode.
> 
> Agreed.  And as mentioned I'like to think even further and avoid
> having these optional bits in the fs inode unconditionally if there
> isn't a good reason for that.  I mentioned quotas before, but an even
> more extreme case is fsverity.  If I understand the fsverity use case
> correctly it is usually used for a very small number of files in the
> system only, and you'd usually do bulk reads from them.  So instead of
> bloating the inode, be that the generic one or that of the file systems
> that use it, why not have a global rhastable index by the inode address
> to look it up?  Compared to the actual hash generation and verification
> a lockless hashlookup is complete noise, but we'll save a lot of
> memory.

My plan is to just push fsverity and fscrypt out via offsets. If someone
wants to wade through the pain of then adding an rhashtable and getting
rid of the offset, then fine by me. But I don't want the removal of
verity and crypt to be gated on that. And I didn't understand you as
wanting that either, I hope?

For anything new pushing for alternative lookup structures is fine.