On Mon, Jul 21, 2025 at 08:14:11AM +0200, Christoph Hellwig wrote: > On Fri, Jul 18, 2025 at 09:04:14AM -0700, Eric Biggers wrote: > > If done properly, fixing this would be great. I've tried to minimize > > the overhead of CONFIG_FS_ENCRYPTION and CONFIG_FS_VERITY when those > > features are not actually being used at runtime. The struct inode > > fields are the main case where we still don't do a good job at that. > > Can you take a look if my idea of not allocating the verity data for > all inodes but just those where verity is enabled and then looking that > up using a rhashtable makes any sense? > I wrote a prototype that puts the fsverity_info structs in an rhashtable, keyed by the ownening 'struct inode *'. It passes the 'verity' group of xfstests on ext4. However, I'm working on checking how bad the performance and code size overhead is, and whether my implementation is actually correct in all cases. Unfortunately, the rhashtable API and implementation is kind of a mess, and it seems it's often not as efficient as it should be. I suppose an XArray would be the main alternative. But XArray needs 'unsigned long' indices, and it doesn't work efficiently when they are pointers. (And i_ino won't do, since i_ino isn't unique.) - Eric
