public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
From: David Disseldorp <ddiss@suse.de>
To: fstests@vger.kernel.org
Cc: Qu Wenruo <wqu@suse.com>, David Disseldorp <ddiss@suse.de>
Subject: [PATCH 4/5] btrfs/282: reduce scrub dataset size
Date: Thu,  7 Dec 2023 18:20:55 +1100	[thread overview]
Message-ID: <20231207072056.14588-5-ddiss@suse.de> (raw)
In-Reply-To: <20231207072056.14588-1-ddiss@suse.de>

The use of dmdelay means that we can use a smaller dataset while still
achieving a reasonable scrub duration. This also drops the xfs_io pwrite
/dev/urandom input file, instead relying on xfs_io's built-in
pseudorandom pattern generation.

Signed-off-by: David Disseldorp <ddiss@suse.de>
---
 tests/btrfs/282     | 8 +++-----
 tests/btrfs/282.out | 2 +-
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/tests/btrfs/282 b/tests/btrfs/282
index f9e22e12..42d992a6 100755
--- a/tests/btrfs/282
+++ b/tests/btrfs/282
@@ -25,8 +25,7 @@ _supported_fs btrfs
 _wants_kernel_commit eb3b50536642 \
 	"btrfs: scrub: per-device bandwidth control"
 
-# We want at least 5G for the scratch device.
-_require_scratch_size $(( 5 * 1024 * 1024))
+_require_scratch
 _require_dm_target delay
 
 # Make sure we can create scrub progress data file
@@ -49,9 +48,8 @@ if [ ! -f "${devinfo_dir}/scrub_speed_max" ]; then
 	_notrun "No sysfs interface for scrub speed throttle"
 fi
 
-# Create a 2G file for later scrub workload.
-# The 2G size is chosen to fit even DUP on a 5G disk.
-$XFS_IO_PROG -f -c "pwrite -i /dev/urandom 0 2G" $SCRATCH_MNT/file | _filter_xfs_io
+# Create a 100M file for later scrub workload.
+$XFS_IO_PROG -f -c "pwrite 0 100M" $SCRATCH_MNT/file | _filter_xfs_io
 
 # Writeback above data, as scrub only verify the committed data.
 sync
diff --git a/tests/btrfs/282.out b/tests/btrfs/282.out
index 8d53e7eb..840e3826 100644
--- a/tests/btrfs/282.out
+++ b/tests/btrfs/282.out
@@ -1,3 +1,3 @@
 QA output created by 282
-wrote 2147483648/2147483648 bytes at offset 0
+wrote 104857600/104857600 bytes at offset 0
 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-- 
2.35.3


  parent reply	other threads:[~2023-12-07  7:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-07  7:20 [PATCH 0/5] btrfs/282: resolve intermittent failures David Disseldorp
2023-12-07  7:20 ` [PATCH 1/5] common/dmdelay: remove DELAY_X enums David Disseldorp
2023-12-07  7:20 ` [PATCH 2/5] btrfs/282: append scrub status output to 282.full David Disseldorp
2023-12-07  9:46   ` Qu Wenruo
2023-12-07  7:20 ` [PATCH 3/5] btrfs/282: dmdelay scrub I/O to fix intermittent failures David Disseldorp
2023-12-07  7:20 ` David Disseldorp [this message]
2023-12-07  7:20 ` [PATCH 5/5] btrfs/282: increase throttled scrub rate tolerance David Disseldorp
2023-12-07  9:49 ` [PATCH 0/5] btrfs/282: resolve intermittent failures Qu Wenruo
2023-12-07 13:49   ` David Disseldorp
2023-12-07 20:02     ` Qu Wenruo

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=20231207072056.14588-5-ddiss@suse.de \
    --to=ddiss@suse.de \
    --cc=fstests@vger.kernel.org \
    --cc=wqu@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox