All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carlos Maiolino <cmaiolino@redhat.com>
To: linux-xfs@vger.kernel.org
Subject: [PATCH RFC] generic 223: Ensure xfs allocator will honor alignment requirements
Date: Mon, 26 Aug 2019 16:47:12 +0200	[thread overview]
Message-ID: <20190826144712.14614-1-cmaiolino@redhat.com> (raw)

If the files being allocated during the test do not fit into a single
Allocation Group, XFS allocator may disable alignment requirements
causing the test to fail even though XFS was working as expected.

Fix this by fixing a min AG size, so all files created during the test
will fit into a single AG not disabling XFS alignment requirements.

Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
---

Hi,

I am tagging this patch as a RFC mostly to start a discussion here, regarding
this issue found while running generic/223.

The generic/223 fails when running it with finobt disabled. Specifically, the
last file being fallocated are unaligned.

When the finobt is enabled, the allocator does not try to squeeze partial file
data into small available extents in AG 0, while it does when finobt is
disabled.

Here are the bmap of the same file after generic/223 finishes with and without
finobt:

finobt=0

/mnt/scratch/file-1073745920-falloc:
 EXT: FILE-OFFSET         BLOCK-RANGE      AG AG-OFFSET           TOTAL FLAGS
   0: [0..191]:           320..511          0 (320..511)            192 001011
   1: [192..375]:         64..247           0 (64..247)             184 001111
   2: [376..1287791]:     678400..1965815   0 (678400..1965815) 1287416 000111
   3: [1287792..2097159]: 1966080..2775447  1 (256..809623)      809368 000101


finobt=1

/mnt/scratch/file-1073745920-falloc:
 EXT: FILE-OFFSET         BLOCK-RANGE      AG AG-OFFSET           TOTAL FLAGS
   0: [0..1285831]:       678400..1964231   0 (678400..1964231) 1285832 000111
   1: [1285832..2097159]: 1966080..2777407  1 (256..811583)      811328 000101


I still don't know the details about why the allocator takes different decisions
depending on finobt being used or not, although I believe it's because the extra
space being used in each AG, and the default AG size when running the test, but
I'm still reading the code to try to understand this difference.

Even though I think there might be room for improvement in the XFS allocator
code to avoid this bypass of alignment requirements here, I still think the test
should be fixed to avoid forcing the filesystem to drop alignment constraints
during file allocation which basically invalidate the test, and that's why I
decided to start the discussion with a RFC patch for the test, but sending it to
xfs list instead of fstests.

Comments?

Cheers


 tests/generic/223 | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/tests/generic/223 b/tests/generic/223
index dfd8c41b..782651e2 100755
--- a/tests/generic/223
+++ b/tests/generic/223
@@ -34,6 +34,13 @@ _require_xfs_io_command "falloc"
 
 rm -f $seqres.full
 
+# Ensure we won't trick xfs allocator to disable alignment requirements
+if [ "$FSTYP" == "xfs" ]; then
+	mkfs_opts="-d agsize=2g"
+else
+	mkfs_opts=""
+fi
+
 BLOCKSIZE=4096
 
 for SUNIT_K in 8 16 32 64 128; do
@@ -41,7 +48,7 @@ for SUNIT_K in 8 16 32 64 128; do
 	let SUNIT_BLOCKS=$SUNIT_BYTES/$BLOCKSIZE
 
 	echo "=== mkfs with su $SUNIT_BLOCKS blocks x 4 ==="
-	export MKFS_OPTIONS=""
+	export MKFS_OPTIONS=$mkfs_opts
 	_scratch_mkfs_geom $SUNIT_BYTES 4 $BLOCKSIZE >> $seqres.full 2>&1
 	_scratch_mount
 
-- 
2.20.1


             reply	other threads:[~2019-08-26 14:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-26 14:47 Carlos Maiolino [this message]
2019-08-27 13:38 ` [PATCH RFC] generic 223: Ensure xfs allocator will honor alignment requirements Brian Foster
2019-08-27 15:33   ` Carlos Maiolino
2019-08-27 16:08     ` Brian Foster

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=20190826144712.14614-1-cmaiolino@redhat.com \
    --to=cmaiolino@redhat.com \
    --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.