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.
