On Sun, Mar 17, 2024 at 06:43:39PM -0700, Christoph Hellwig wrote: > Just skimming over the series from the little I've followed from the > last rounds (sorry, to busy with various projects): > > > --- a/fs/xfs/xfs_inode.h > > +++ b/fs/xfs/xfs_inode.h > > @@ -92,6 +92,9 @@ typedef struct xfs_inode { > > spinlock_t i_ioend_lock; > > struct work_struct i_ioend_work; > > struct list_head i_ioend_list; > > +#ifdef CONFIG_FS_VERITY > > + struct xarray i_merkle_blocks; > > +#endif > > This looks like very much a blocker to me. Adding a 16 byte field to > struct inode that is used just for a few read-only-ish files on > select few file systems doesn't seem very efficient. Given that we > very rarely update it and thus concurrency on the write side doesn't > matter much, is there any way we could get a away with a fs-wide > lookup data structure and avoid this? Only if you can hand a 128-bit key to an xarray. ;) But in all seriousness, we could have a per-AG xarray that maps xfs_agino_t to this xarray of merkle blocks. That would be nice in that we don't have to touch xfs_icache.c for the shrinker at all. --D