All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Carlos Maiolino <cem@kernel.org>, xfs <linux-xfs@vger.kernel.org>,
	Andrey Albershteyn <aalbersh@redhat.com>
Subject: Re: [PATCH] xfs: speed up parent pointer operations
Date: Thu, 8 Jan 2026 09:03:07 -0800	[thread overview]
Message-ID: <20260108170307.GK15551@frogsfrogsfrogs> (raw)
In-Reply-To: <aV95NpD3Jow6UgOj@infradead.org>

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

      reply	other threads:[~2026-01-08 17:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-19 15:41 [PATCH] xfs: speed up parent pointer operations Darrick J. Wong
2026-01-06  8:16 ` Christoph Hellwig
2026-01-07  0:09   ` Darrick J. Wong
2026-01-07  6:04     ` Christoph Hellwig
2026-01-07 18:22       ` Darrick J. Wong
2026-01-08  9:30         ` Christoph Hellwig
2026-01-08 17:03           ` Darrick J. Wong [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260108170307.GK15551@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=aalbersh@redhat.com \
    --cc=cem@kernel.org \
    --cc=hch@infradead.org \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.