[PATCH] xfs: speed up parent pointer operations

[PATCH] xfs: speed up parent pointer operations

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

After a recent fsmark benchmarking run, I observed that the overhead of
parent pointers on file creation and deletion can be a bit high.  On a
machine with 20 CPUs, 128G of memory, and an NVME SSD capable of pushing
750000iops, I see the following results:

 $ mkfs.xfs -f -l logdev=/dev/nvme1n1,size=1g /dev/nvme0n1 -n parent=0
 meta-data=/dev/nvme0n1           isize=512    agcount=40, agsize=9767586 blks
          =                       sectsz=4096  attr=2, projid32bit=1
          =                       crc=1        finobt=1, sparse=1, rmapbt=1
          =                       reflink=1    bigtime=1 inobtcount=1 nrext64=1
          =                       exchange=0   metadir=0
 data     =                       bsize=4096   blocks=390703440, imaxpct=5
          =                       sunit=0      swidth=0 blks
 naming   =version 2              bsize=4096   ascii-ci=0, ftype=1, parent=0
 log      =/dev/nvme1n1           bsize=4096   blocks=262144, version=2
          =                       sectsz=4096  sunit=1 blks, lazy-count=1
 realtime =none                   extsz=4096   blocks=0, rtextents=0
          =                       rgcount=0    rgsize=0 extents
          =                       zoned=0      start=0 reserved=0

So we created 40 AGs, one per CPU.  Now we create 40 directories and run
fsmark:

 $ time fs_mark  -D  10000  -S  0  -n  100000  -s  0  -L  8 -d ...
 # Version 3.3, 40 thread(s) starting at Wed Dec 10 14:22:07 2025
 # Sync method: NO SYNC: Test does not issue sync() or fsync() calls.
 # Directories:  Time based hash between directories across 10000 subdirectories with 180 seconds per subdirectory.
 # File names: 40 bytes long, (16 initial bytes of time stamp with 24 random bytes at end of name)
 # Files info: size 0 bytes, written with an IO size of 16384 bytes per write
 # App overhead is time in microseconds spent in the test not doing file writing related system calls.

 parent=0               parent=1
 ==================     ==================
 real    0m57.573s      real    1m2.934s
 user    3m53.578s      user    3m53.508s
 sys     19m44.440s     sys     25m14.810s

 $ time rm -rf ...

 parent=0               parent=1
 ==================     ==================
 real    0m59.649s      real    1m12.505s
 user    0m41.196s      user    0m47.489s
 sys     13m9.566s      sys     20m33.844s

Parent pointers increase the system time by 28% overhead to create 32
million files that are totally empty.  Removing them incurs a system
time increase of 56%.  Wall time increases by 9% and 22%.

For most filesystems, each file tends to have a single owner and not
that many xattrs.  If the xattr structure is shortform, then all xattr
changes are logged with the inode and do not require the the xattr
intent mechanism to persist the parent pointer.

Therefore, we can speed up parent pointer operations by calling the
shortform xattr functions directly if the child's xattr is in short
format.  Now the overhead looks like:

 $ time fs_mark  -D  10000  -S  0  -n  100000  -s  0  -L  8 -d ...

 parent=0               parent=1
 ==================     ==================
 real    0m58.030s      real    1m0.983s
 user    3m54.141s      user    3m53.758s
 sys     19m57.003s     sys     21m30.605s

 $ time rm -rf ...

 parent=0               parent=1
 ==================     ==================
 real    0m58.911s      real    1m4.420s
 user    0m41.329s      user    0m45.169s
 sys     13m27.857s     sys     15m58.564s

Now parent pointers only increase the system time by 8% for creation and
19% for deletion.  Wall time increases by 5% and 9%.

Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 fs/xfs/libxfs/xfs_attr_leaf.h |    1 +
 fs/xfs/libxfs/xfs_attr.c      |    2 +-
 fs/xfs/libxfs/xfs_parent.c    |   36 ++++++++++++++++++++++++++++++++++++
 3 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/fs/xfs/libxfs/xfs_attr_leaf.h b/fs/xfs/libxfs/xfs_attr_leaf.h
index 589f810eedc0d8..da95de8199dd24 100644
--- a/fs/xfs/libxfs/xfs_attr_leaf.h
+++ b/fs/xfs/libxfs/xfs_attr_leaf.h
@@ -49,6 +49,7 @@ void	xfs_attr_shortform_create(struct xfs_da_args *args);
 void	xfs_attr_shortform_add(struct xfs_da_args *args, int forkoff);
 int	xfs_attr_shortform_getvalue(struct xfs_da_args *args);
 int	xfs_attr_shortform_to_leaf(struct xfs_da_args *args);
+int	xfs_attr_try_sf_addname(struct xfs_da_args *args);
 int	xfs_attr_sf_removename(struct xfs_da_args *args);
 struct xfs_attr_sf_entry *xfs_attr_sf_findname(struct xfs_da_args *args);
 int	xfs_attr_shortform_allfit(struct xfs_buf *bp, struct xfs_inode *dp);
diff --git a/fs/xfs/libxfs/xfs_attr.c b/fs/xfs/libxfs/xfs_attr.c
index 9d1e5ccab106ca..6ca0ee538131a8 100644
--- a/fs/xfs/libxfs/xfs_attr.c
+++ b/fs/xfs/libxfs/xfs_attr.c
@@ -349,7 +349,7 @@ xfs_attr_set_resv(
  * xfs_attr_shortform_addname() will convert to leaf format and return -ENOSPC.
  * to use.
  */
-STATIC int
+int
 xfs_attr_try_sf_addname(
 	struct xfs_da_args	*args)
 {
diff --git a/fs/xfs/libxfs/xfs_parent.c b/fs/xfs/libxfs/xfs_parent.c
index 69366c44a70159..40db7042a30975 100644
--- a/fs/xfs/libxfs/xfs_parent.c
+++ b/fs/xfs/libxfs/xfs_parent.c
@@ -29,6 +29,7 @@
 #include "xfs_trans_space.h"
 #include "xfs_attr_item.h"
 #include "xfs_health.h"
+#include "xfs_attr_leaf.h"
 
 struct kmem_cache		*xfs_parent_args_cache;
 
@@ -202,6 +203,16 @@ xfs_parent_addname(
 	xfs_inode_to_parent_rec(&ppargs->rec, dp);
 	xfs_parent_da_args_init(&ppargs->args, tp, &ppargs->rec, child,
 			child->i_ino, parent_name);
+
+	if (xfs_inode_has_attr_fork(child) &&
+	    xfs_attr_is_shortform(child)) {
+		ppargs->args.op_flags |= XFS_DA_OP_ADDNAME;
+
+		error = xfs_attr_try_sf_addname(&ppargs->args);
+		if (error != -ENOSPC)
+			return error;
+	}
+
 	xfs_attr_defer_add(&ppargs->args, XFS_ATTR_DEFER_SET);
 	return 0;
 }
@@ -224,6 +235,10 @@ xfs_parent_removename(
 	xfs_inode_to_parent_rec(&ppargs->rec, dp);
 	xfs_parent_da_args_init(&ppargs->args, tp, &ppargs->rec, child,
 			child->i_ino, parent_name);
+
+	if (xfs_attr_is_shortform(child))
+		return xfs_attr_sf_removename(&ppargs->args);
+
 	xfs_attr_defer_add(&ppargs->args, XFS_ATTR_DEFER_REMOVE);
 	return 0;
 }
@@ -250,6 +265,27 @@ xfs_parent_replacename(
 			child->i_ino, old_name);
 
 	xfs_inode_to_parent_rec(&ppargs->new_rec, new_dp);
+
+	if (xfs_attr_is_shortform(child)) {
+		ppargs->args.op_flags |= XFS_DA_OP_ADDNAME | XFS_DA_OP_REPLACE;
+
+		error = xfs_attr_sf_removename(&ppargs->args);
+		if (error)
+			return error;
+
+		xfs_parent_da_args_init(&ppargs->args, tp, &ppargs->new_rec,
+				child, child->i_ino, new_name);
+		ppargs->args.op_flags |= XFS_DA_OP_ADDNAME;
+
+		error = xfs_attr_try_sf_addname(&ppargs->args);
+		if (error == -ENOSPC) {
+			xfs_attr_defer_add(&ppargs->args, XFS_ATTR_DEFER_SET);
+			return 0;
+		}
+
+		return error;
+	}
+
 	ppargs->args.new_name = new_name->name;
 	ppargs->args.new_namelen = new_name->len;
 	ppargs->args.new_value = &ppargs->new_rec;

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

[Christoph Hellwig]

On Fri, Dec 19, 2025 at 07:41:54AM -0800, Darrick J. Wong wrote:
> Now parent pointers only increase the system time by 8% for creation and
> 19% for deletion.  Wall time increases by 5% and 9%.

Nice!

> @@ -202,6 +203,16 @@ xfs_parent_addname(
>  	xfs_inode_to_parent_rec(&ppargs->rec, dp);
>  	xfs_parent_da_args_init(&ppargs->args, tp, &ppargs->rec, child,
>  			child->i_ino, parent_name);
> +
> +	if (xfs_inode_has_attr_fork(child) &&
> +	    xfs_attr_is_shortform(child)) {
> +		ppargs->args.op_flags |= XFS_DA_OP_ADDNAME;
> +
> +		error = xfs_attr_try_sf_addname(&ppargs->args);
> +		if (error != -ENOSPC)
> +			return error;
> +	}
> +
>  	xfs_attr_defer_add(&ppargs->args, XFS_ATTR_DEFER_SET);

We should be able to do this for all attrs, not just parent pointers,
right?  It might be nice to just do this for set and remove in
xfs_attr_defer_add and have it handle all attr operations.

> +	if (xfs_attr_is_shortform(child)) {
> +		ppargs->args.op_flags |= XFS_DA_OP_ADDNAME | XFS_DA_OP_REPLACE;
> +
> +		error = xfs_attr_sf_removename(&ppargs->args);
> +		if (error)
> +			return error;
> +
> +		xfs_parent_da_args_init(&ppargs->args, tp, &ppargs->new_rec,
> +				child, child->i_ino, new_name);
> +		ppargs->args.op_flags |= XFS_DA_OP_ADDNAME;
> +
> +		error = xfs_attr_try_sf_addname(&ppargs->args);
> +		if (error == -ENOSPC) {
> +			xfs_attr_defer_add(&ppargs->args, XFS_ATTR_DEFER_SET);
> +			return 0;
> +		}

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.

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

[Darrick J. Wong]

On Tue, Jan 06, 2026 at 12:16:59AM -0800, Christoph Hellwig wrote:
> On Fri, Dec 19, 2025 at 07:41:54AM -0800, Darrick J. Wong wrote:
> > Now parent pointers only increase the system time by 8% for creation and
> > 19% for deletion.  Wall time increases by 5% and 9%.
> 
> Nice!
> 
> > @@ -202,6 +203,16 @@ xfs_parent_addname(
> >  	xfs_inode_to_parent_rec(&ppargs->rec, dp);
> >  	xfs_parent_da_args_init(&ppargs->args, tp, &ppargs->rec, child,
> >  			child->i_ino, parent_name);
> > +
> > +	if (xfs_inode_has_attr_fork(child) &&
> > +	    xfs_attr_is_shortform(child)) {
> > +		ppargs->args.op_flags |= XFS_DA_OP_ADDNAME;
> > +
> > +		error = xfs_attr_try_sf_addname(&ppargs->args);
> > +		if (error != -ENOSPC)
> > +			return error;
> > +	}
> > +
> >  	xfs_attr_defer_add(&ppargs->args, XFS_ATTR_DEFER_SET);
> 
> We should be able to do this for all attrs, not just parent pointers,
> right?

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.

>         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.

> > +	if (xfs_attr_is_shortform(child)) {
> > +		ppargs->args.op_flags |= XFS_DA_OP_ADDNAME | XFS_DA_OP_REPLACE;
> > +
> > +		error = xfs_attr_sf_removename(&ppargs->args);
> > +		if (error)
> > +			return error;
> > +
> > +		xfs_parent_da_args_init(&ppargs->args, tp, &ppargs->new_rec,
> > +				child, child->i_ino, new_name);
> > +		ppargs->args.op_flags |= XFS_DA_OP_ADDNAME;
> > +
> > +		error = xfs_attr_try_sf_addname(&ppargs->args);
> > +		if (error == -ENOSPC) {
> > +			xfs_attr_defer_add(&ppargs->args, XFS_ATTR_DEFER_SET);
> > +			return 0;
> > +		}
> 
> 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.

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.

--D

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

[Christoph Hellwig]

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.

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

[Darrick J. Wong]

On Tue, Jan 06, 2026 at 10:04:46PM -0800, Christoph Hellwig wrote:
> 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.

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.

> > > 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.

Yes it is pretty simple:

int
xfs_attr_shortform_replace(
	struct xfs_da_args		*args)
{
	struct xfs_attr_sf_entry	*sfe;

	ASSERT(args->dp->i_af.if_format == XFS_DINODE_FMT_LOCAL);

	trace_xfs_attr_sf_replace(args);

	sfe = xfs_attr_sf_findname(args);
	if (!sfe)
		return -ENOATTR;

	if (sfe->valuelen != args->valuelen)
		return -ENOSPC;

	memcpy(&sfe->nameval[sfe->namelen], args->value, args->valuelen);
	xfs_trans_log_inode(args->trans, args->dp,
			XFS_ILOG_CORE | XFS_ILOG_ADATA);
	return 0;
}

(parent pointers are a tad more difficult because we have to copy the
new name as well as the new value)

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

> > 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.

--D

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

[Christoph Hellwig]

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.

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

[Darrick J. Wong]

On Thu, Jan 08, 2026 at 01:30:30AM -0800, Christoph Hellwig wrote:
> 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).

<nod> Though if it's not an exact size match, then calling _sf_remove
and _sf_add already does that -- the _sf_remove will compact the entire
sf attr structure before _sf_add puts in the new attr.

The downsides of that sequence is that while we could probably save a
trip through xfs_idata_realloc, then I have to write and QA new code.
So for now I'd rather focus on optimizing xattr replace where the old
and new size are the same.

> > 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.

<nod>

--D