From: Christoph Hellwig <hch@lst.de>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>,
Chandan Babu R <chandan.babu@oracle.com>,
linux-xfs@vger.kernel.org
Subject: Re: [PATCH 14/16] xfs: optimize adding the first 8-byte inode to a shortform directory
Date: Thu, 2 May 2024 06:25:09 +0200 [thread overview]
Message-ID: <20240502042509.GD26601@lst.de> (raw)
In-Reply-To: <20240501215056.GD360919@frogsfrogsfrogs>
On Wed, May 01, 2024 at 02:50:56PM -0700, Darrick J. Wong wrote:
> I noticed a few places where we pass offset == 0 here. That's ok as a
> null value because the start of a shortform directory is always the
> header, correct?
The start of the "physical" layout has the header, but offset is the
"logic" d_offset offset. The start of it it reserved for (but not
actually used by) the "." and ".." entries that will occupy the space
when converted out of the short form. Probably also needs a comment.
> Ok, so this isn't needed anymore because the ino8 conversion now adds
> the new dirent?
Yes.
> > - xfs_dir2_sf_toino8(args);
> > + xfs_dir2_sf_toino8(args, 0);
>
> This is a replace, so we pass 0 here effectively as a null value?
Exactly.
> > @@ -1250,6 +1275,17 @@ xfs_dir2_sf_toino8(
> > xfs_dir2_sf_get_ino(mp, oldsfp, oldsfep));
> > xfs_dir2_sf_put_ftype(mp, sfep,
> > xfs_dir2_sf_get_ftype(mp, oldsfep));
> > +
> > + /*
> > + * If there is a new entry to add it once we reach the specified
> > + * offset.
>
> It took me a minute of staring at the if test logic to figure out what
> we're doing here. If, after, reformatting a directory entry, the next
> entry is the offset where _pick wants us to place the new dirent, we
> should jump sfep to the next entry, and then add the new entry.
>
> Is that right? And we can't simplify the logic to:
>
> if (new_offset && new_offset = xfs_dir2_sf_get_offset(sfep))
== ?
> Because _pick might want us to add the entry at the end of the directory
> but we haven't incremented sfp->count yet, so the loop body will not be
> executed in that case.
>
> Is it ever the case that the entry get added in the middle of a
> shortform directory?
Yes, that is the hard case. There is no good reason to add it in
the middle, but we've encoded that the "logical" offset for a
shortform directly needs to fit into the physical size of a single
directory block when converted to block format in asserts and verifiers
and are stuck with it. Otherwise we could have just always added it
at the end..
next prev parent reply other threads:[~2024-05-02 4:25 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-30 12:49 optimize local for and shortform directory handling Christoph Hellwig
2024-04-30 12:49 ` [PATCH 01/16] xfs: allow non-empty forks in xfs_bmap_local_to_extents_empty Christoph Hellwig
2024-04-30 15:51 ` Darrick J. Wong
2024-05-01 4:37 ` Christoph Hellwig
2024-05-01 21:04 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 02/16] xfs: remove an extra buffer allocation in xfs_attr_shortform_to_leaf Christoph Hellwig
2024-05-01 21:11 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 03/16] xfs: rationalize dir2_sf entry condition asserts Christoph Hellwig
2024-05-01 21:13 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 04/16] xfs: remove an extra buffer allocation in xfs_dir2_sf_to_block Christoph Hellwig
2024-05-01 21:15 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 05/16] xfs: move the "does it fit" check into xfs_dir2_block_to_sf Christoph Hellwig
2024-05-01 21:16 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 06/16] xfs: remove the buffer allocation size in xfs_dir2_try_block_to_sf Christoph Hellwig
2024-05-01 21:17 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 07/16] xfs: remove a superfluous memory allocation in xfs_dir2_block_to_sf Christoph Hellwig
2024-05-01 21:18 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 08/16] xfs: remove a superfluous memory allocation in xfs_dir2_sf_toino8 Christoph Hellwig
2024-05-01 21:20 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 09/16] xfs: remove a superfluous memory allocation in xfs_dir2_sf_toino4 Christoph Hellwig
2024-05-01 21:20 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 10/16] xfs: optimize removing the last 8-byte inode from a shortform directory Christoph Hellwig
2024-05-01 21:25 ` Darrick J. Wong
2024-05-02 4:13 ` Christoph Hellwig
2024-04-30 12:49 ` [PATCH 11/16] xfs: add xfs_dir2_block_overhead helper Christoph Hellwig
2024-05-01 21:27 ` Darrick J. Wong
2024-05-02 4:14 ` Christoph Hellwig
2024-04-30 12:49 ` [PATCH 12/16] xfs: factor out a xfs_dir2_sf_addname_common helper Christoph Hellwig
2024-05-01 21:31 ` Darrick J. Wong
2024-05-02 4:15 ` Christoph Hellwig
2024-04-30 12:49 ` [PATCH 13/16] xfs: move common code into xfs_dir2_sf_addname Christoph Hellwig
2024-05-01 21:32 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 14/16] xfs: optimize adding the first 8-byte inode to a shortform directory Christoph Hellwig
2024-05-01 21:50 ` Darrick J. Wong
2024-05-02 4:25 ` Christoph Hellwig [this message]
2024-05-02 14:43 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 15/16] xfs: move the block format conversion out of line in xfs_dir2_sf_addname Christoph Hellwig
2024-05-01 21:33 ` Darrick J. Wong
2024-04-30 12:49 ` [PATCH 16/16] xfs: make the hard case in xfs_dir2_sf_addname less hard Christoph Hellwig
2024-05-01 22:10 ` Darrick J. Wong
2024-05-10 6:29 ` kernel test robot
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=20240502042509.GD26601@lst.de \
--to=hch@lst.de \
--cc=chandan.babu@oracle.com \
--cc=djwong@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).