All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: djwong@kernel.org, zlang@redhat.com
Cc: Dave Chinner <dchinner@redhat.com>,
	linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me,
	david@fromorbit.com
Subject: [PATCH 1/4] populate: ensure btree directories are created reliably
Date: Tue, 17 Jan 2023 16:43:47 -0800	[thread overview]
Message-ID: <167400103057.1915094.778206076529720127.stgit@magnolia> (raw)
In-Reply-To: <167400103044.1915094.5935980986164675922.stgit@magnolia>

From: Dave Chinner <dchinner@redhat.com>

The population function creates an XFS btree format directory by
polling the extent count of the inode and creating new dirents until
the extent count goes over the limit that pushes it into btree
format.

It then removes every second dirent to create empty space in the
directory data to ensure that operations like metadump with
obfuscation can check that they don't leak stale data from deleted
dirents.

Whilst this does not result in directory data blocks being freed, it
does not take into account the fact that the dabtree index has half
the entries removed from it and that can result in btree nodes
merging and extents being freed. This causes the extent count to go
down, and the inode is converted back into extent form. The
population checks then fail because it should be in btree form.

Fix this by counting the number of directory data extents rather than
the total number of extents in the data fork. We can do this simply
by using xfs_bmap and counting the number of extents returned as it
does not report extents beyond EOF (which is where the dabtree is
located). As the number of data blocks does not change with the
dirent removal algorithm used, this will ensure that the inode data
fork remains in btree format.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
[djwong: make this patch first in line]
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
 common/populate |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)


diff --git a/common/populate b/common/populate
index 44b4af1667..84f4b8e374 100644
--- a/common/populate
+++ b/common/populate
@@ -89,9 +89,12 @@ __populate_xfs_create_btree_dir() {
 		local creat=mkdir
 		test "$((nr % 20))" -eq 0 && creat=touch
 		$creat "${name}/$(printf "%.08d" "$nr")"
+		# Extent count checks use data blocks only to avoid the removal
+		# step from removing dabtree index blocks and reducing the
+		# number of extents below the required threshold.
 		if [ "$((nr % 40))" -eq 0 ]; then
-			local nextents="$(_xfs_get_fsxattr nextents $name)"
-			[ $nextents -gt $max_nextents ] && break
+			local nextents="$(xfs_bmap ${name} | grep -v hole | wc -l)"
+			[ "$((nextents - 1))" -gt $max_nextents ] && break
 		fi
 		nr=$((nr+1))
 	done


  reply	other threads:[~2023-01-18  0:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-18  0:42 [PATCHSET v2 0/4] fstests: filesystem population fixes Darrick J. Wong
2023-01-18  0:43 ` Darrick J. Wong [this message]
2023-01-18  0:44 ` [PATCH 2/4] populate: remove file creation loops that take forever Darrick J. Wong
2023-01-18 15:09   ` Zorro Lang
2023-01-18  0:44 ` [PATCH 3/4] populate: improve attr creation runtime Darrick J. Wong
2023-01-18 15:15   ` Zorro Lang
2023-01-18  0:44 ` [PATCH 4/4] populate: improve runtime of __populate_fill_fs Darrick J. Wong
2023-01-18 15:54   ` Zorro Lang
2023-01-18 19:22     ` Darrick J. Wong
2023-01-19  5:04       ` Zorro Lang
2023-01-19 16:19         ` Darrick J. Wong
2023-01-18 14:24 ` [PATCHSET v2 0/4] fstests: filesystem population fixes Andrey Albershteyn

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=167400103057.1915094.778206076529720127.stgit@magnolia \
    --to=djwong@kernel.org \
    --cc=david@fromorbit.com \
    --cc=dchinner@redhat.com \
    --cc=fstests@vger.kernel.org \
    --cc=guan@eryu.me \
    --cc=linux-xfs@vger.kernel.org \
    --cc=zlang@redhat.com \
    /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.