Re: [PATCH] xfs: speed up parent pointer operations

[Christoph Hellwig <hch@infradead.org>]

On Tue, Jan 06, 2026 at 04:09:07PM -0800, Darrick J. Wong wrote:
> In principle, yes.  For a generic xattr version you'd probably want to
> check for a large valuelen on the set side so that we don't waste time
> scanning the sf structure when we're just going to end up in remote
> value territory anyway.

Yeah.

> 
> >         It might be nice to just do this for set and remove in
> > xfs_attr_defer_add and have it handle all attr operations.
> 
> Yeah.  I think it's more logical to put these new shortcut calls in
> xfs_attr_set because we're be deciding /not/ to invoke the deferred
> xattr mechanism.

Or that, yes.

> > And for replace we should be able to optimize this even further
> > by adding a new xfs_attr_sf_replacename that just checks if the new
> > version would fit, and then memmove everything behind the changed
> > attr and update it in place.  This should improve the operation a lot
> > more.
> 
> That would depends on the frequency of non-parent pointer xattr
> operations where the value doesn't change size modulo the rounding
> factor.

Well, the same applies to value changes - in the shortform format name
and value are basically one blob, split by namelen.  So anything
replacing an existing attr with a new one, either due to a name change
for parent pointers, or due to a value change otherwise can just move
things beyond the attribute and update in place trivially.  For
replacing values with values of the same size things are even simpler.

> I also wonder how much benefit anyone really gets from doing this to
> regular xattrs, but once I'm more convinced that it's solid w.r.t.
> parent pointers it's trivial to move it to xattrs too.

Not sure what counts as regular, but I'm pretty sure it would help
quite a bit for inheriting xattrs or other security attributes.