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.
