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

[Christoph Hellwig <hch@infradead.org>]

On Wed, Jan 07, 2026 at 10:22:42AM -0800, Darrick J. Wong wrote:
> > > xattr mechanism.
> > 
> > Or that, yes.
> 
> It turns out that for replace, it's more convenient to do it separately
> in the xattr and parent pointer code because parent pointer replacements
> require switching new_name -> name and new_value -> value after the
> remove step; and the rename optimization is different for parent
> pointers vs. every other xattr.

I don't really follow, but I trust you on the parent pointers.

> > 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.
> 
> Yes it is pretty simple:

This is the same sized value and name, and it indeed is trivial.

But even a change in size of the value (or name for that matter, except
that outside of parent pointers that operation doesn't exist) is trivial
in an sf attr fork with enough space, you just need to either move out
anything beyond the attr first (larger name + value size) or down after
(smaller large and value size).

> IIRC there's no rounding applied to shortform attr entries, so we have
> to have an exact match on the value length.

Exactly.

> > > 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.
> 
> Here, by "regular" I meant "not parent pointers" but yeah.  It'll
> probably help everyone to implement the shortcuts.

For user attributes it really depends on how people use it.  But for
applications that update fixed sized attributes, which doesn't sound too
unusual, it would be a nice improvement as well.