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

[Christoph Hellwig <hch@lst.de>]

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.