linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH] fstests: btrfs/15[78]: Detect non-raid6 data chunks before doing the test
Date: Thu, 10 Oct 2019 14:13:56 +0800	[thread overview]
Message-ID: <20191010061356.28237-1-wqu@suse.com> (raw)

[BUG]
When certain older mkfs.btrfs is used, btrfs/157 and btrfs/158 fails like
below:

  btrfs/157 2s ... - output mismatch (see xfstests-dev/results//btrfs/157.out.bad)
      --- tests/btrfs/157.out     2019-07-22 14:13:44.653333326 +0800
      +++ results//btrfs/157.out.bad      2019-10-10 13:58:58.625454478 +0800
      @@ -1,8 +1,9 @@
       QA output created by 157
       wrote 131072/131072 bytes at offset 0
       XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
      -wrote 65536/65536 bytes at offset 9437184
      -XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
      +non-numeric offset argument -- 13631488
      +1048576
      ...

[CAUSE]
Btrfs/157 assumes there is only one RADI6 data chunk, and uses the
following grep to find the only RAID6 data chunk:

  $BTRFS_UTIL_PROG ins dump-tree -t 3 $SCRATCH_DEV |
  grep " DATA\|RAID6"

However that grep line can also matches SINGLE data profile. For older
mkfs which doesn't cleanup the SINGLE temporary chunks, it will cause
several lines of output, and screw up the output of
get_physical_stripe0()

[FIX]
Add an extra filter, check_data_chunk_profile() to make sure there is
only 1 data chunk and only 1 raid6 data chunk.

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
Currently it will skip the test if the assumption is not met, but in fact
the original failure detects a bug in my modification of mkfs.btrfs.

so I'm not completely sure if I should _fail or _notrun.
---
 tests/btrfs/157 | 14 ++++++++++++++
 tests/btrfs/158 | 14 ++++++++++++++
 2 files changed, 28 insertions(+)

diff --git a/tests/btrfs/157 b/tests/btrfs/157
index 7f75c407..78dcea21 100755
--- a/tests/btrfs/157
+++ b/tests/btrfs/157
@@ -51,6 +51,19 @@ _require_scratch_dev_pool 4
 _require_btrfs_command inspect-internal dump-tree
 _require_btrfs_fs_feature raid56
 
+# Older mkfs.btrfs or regression could create SINGLE temporary chunks
+# Detect those before they screw up get_physical_stripe*() functions
+check_data_chunk_profile()
+{
+	nr_data_chunks=$($BTRFS_UTIL_PROG inspect-internal dump-tree -t 3 \
+		$SCRATCH_DEV | grep "type DATA" | wc -l)
+	nr_raid6_data_chunks=$($BTRFS_UTIL_PROG inspect-internal dump-tree -t 3 \
+		$SCRATCH_DEV | grep "type DATA.RAID6" | wc -l)
+	if [ $nr_data_chunks -ne $nr_raid6_data_chunks -o $nr_data_chunks -ne 1 ]; then
+		_notrun "non-raid6 data chunk detected"
+	fi
+}
+
 get_physical_stripe0()
 {
 	$BTRFS_UTIL_PROG inspect-internal dump-tree -t 3 $SCRATCH_DEV | \
@@ -82,6 +95,7 @@ $XFS_IO_PROG -f -d -c "pwrite -S 0xaa 0 128K" -c "fsync" \
 
 _scratch_unmount
 
+check_data_chunk_profile
 stripe_0=`get_physical_stripe0`
 stripe_1=`get_physical_stripe1`
 dev4=`echo $SCRATCH_DEV_POOL | awk '{print $4}'`
diff --git a/tests/btrfs/158 b/tests/btrfs/158
index 603e8bea..441a33e8 100755
--- a/tests/btrfs/158
+++ b/tests/btrfs/158
@@ -43,6 +43,19 @@ _require_scratch_dev_pool 4
 _require_btrfs_command inspect-internal dump-tree
 _require_btrfs_fs_feature raid56
 
+# Older mkfs.btrfs or regression could create SINGLE temporary chunks
+# Detect those before they screw up get_physical_stripe*() functions
+check_data_chunk_profile()
+{
+	nr_data_chunks=$($BTRFS_UTIL_PROG inspect-internal dump-tree -t 3 \
+		$SCRATCH_DEV | grep "type DATA" | wc -l)
+	nr_raid6_data_chunks=$($BTRFS_UTIL_PROG inspect-internal dump-tree -t 3 \
+		$SCRATCH_DEV | grep "type DATA.RAID6" | wc -l)
+	if [ $nr_data_chunks -ne $nr_raid6_data_chunks -o $nr_data_chunks -ne 1 ]; then
+		_notrun "non-raid6 data chunk detected"
+	fi
+}
+
 get_physical_stripe0()
 {
 	$BTRFS_UTIL_PROG inspect-internal dump-tree -t 3 $SCRATCH_DEV | \
@@ -74,6 +87,7 @@ $XFS_IO_PROG -f -d -c "pwrite -S 0xaa 0 128K" -c "fsync" \
 
 _scratch_unmount
 
+check_data_chunk_profile
 stripe_0=`get_physical_stripe0`
 stripe_1=`get_physical_stripe1`
 dev4=`echo $SCRATCH_DEV_POOL | awk '{print $4}'`
-- 
2.22.0


                 reply	other threads:[~2019-10-10  6:14 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20191010061356.28237-1-wqu@suse.com \
    --to=wqu@suse.com \
    --cc=linux-btrfs@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).