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
