On Tue, Mar 12, 2024 at 09:38:09AM -0700, Darrick J. Wong wrote: > On Tue, Mar 12, 2024 at 01:10:06PM +0100, Andrey Albershteyn wrote: > > On 2024-03-07 14:18:09, Darrick J. Wong wrote: > > > On Mon, Mar 04, 2024 at 08:10:45PM +0100, Andrey Albershteyn wrote: > > > > fs-verity adds new inode flag which causes scrub to fail as it is > > > > not yet known. > > > > > > > > Signed-off-by: Andrey Albershteyn <aalbersh@xxxxxxxxxx> > > > > Reviewed-by: Darrick J. Wong <djwong@xxxxxxxxxx> > > > > --- > > > > fs/xfs/scrub/attr.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/fs/xfs/scrub/attr.c b/fs/xfs/scrub/attr.c > > > > index 9a1f59f7b5a4..ae4227cb55ec 100644 > > > > --- a/fs/xfs/scrub/attr.c > > > > +++ b/fs/xfs/scrub/attr.c > > > > @@ -494,7 +494,7 @@ xchk_xattr_rec( > > > > /* Retrieve the entry and check it. */ > > > > hash = be32_to_cpu(ent->hashval); > > > > badflags = ~(XFS_ATTR_LOCAL | XFS_ATTR_ROOT | XFS_ATTR_SECURE | > > > > - XFS_ATTR_INCOMPLETE | XFS_ATTR_PARENT); > > > > + XFS_ATTR_INCOMPLETE | XFS_ATTR_PARENT | XFS_ATTR_VERITY); > > > > > > Now that online repair can modify/discard/salvage broken xattr trees and > > > is pretty close to merging, how can I make it invalidate all the incore > > > merkle tree data after a repair? > > > > > > --D > > > > > > > I suppose dropping all the xattr XFS_ATTR_VERITY buffers associated > > with an inode should do the job. > > Oh! Yes, xfs_verity_cache_drop would handle that nicely. Here's today's branch, in which I implemented Eric's suggestions for the "support block-based Merkle tree caching" patch, except for the ones that conflict with the different direction I went in for ->read_merkle_tree_block; and implemented Dave's suggestions for shrinker improvements: https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=fsverity-cleanups-6.9_2024-03-12 --D > --D > > > -- > > - Andrey > > > > >