On Mon 21-07-25 16:55:52, Eric Biggers wrote: > 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.) As Christoph wrote I don't think XArray is a good alternative. The memory overhead is big for sparsely populated key space and that also increases the lookup overhead which is O(log N) to start with. Rhashtable should have O(1) lookup which is what we are most interested in. So if xarray is faster than rhashtable, rhashtable is doing something seriously wrong. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
