public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org, fstests@vger.kernel.org
Subject: [PATCH] btrfs: add a test case to verify scrub speed throttle works
Date: Wed,  4 Jan 2023 16:21:23 +0800	[thread overview]
Message-ID: <20230104082123.56800-1-wqu@suse.com> (raw)

We introduced scrub speed throttle in commit eb3b50536642 ("btrfs: scrub:
per-device bandwidth control"),  but it is not that well documented
(e.g. what's the unit of the sysfs interface), nor tested by any test
case.

This patch will add a test case for this functionality.

The test case itself is pretty straightforward:

- Fill the fs with 2G file as scrub workload
- Set scrub speed limit to 50MiB/s
- Scrub and compare the reported rate against above 50MiB/s throttle

However the test case has an assumption that the underlying disk must be
faster than our 50MiB/s, which should be pretty common in
baremetal/exclusive VMs.
But for cloud environment it's not ensured 100%, thus the test case is
not included in auto group to avoid false alerts.

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 tests/btrfs/282     | 83 +++++++++++++++++++++++++++++++++++++++++++++
 tests/btrfs/282.out |  3 ++
 2 files changed, 86 insertions(+)
 create mode 100755 tests/btrfs/282
 create mode 100644 tests/btrfs/282.out

diff --git a/tests/btrfs/282 b/tests/btrfs/282
new file mode 100755
index 00000000..9a6677ec
--- /dev/null
+++ b/tests/btrfs/282
@@ -0,0 +1,83 @@
+#! /bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (C) 2023 SUSE Linux Products GmbH. All Rights Reserved.
+#
+# FS QA Test 282
+#
+# Make sure scrub speed limitation works as expected.
+#
+. ./common/preamble
+_begin_fstest scrub
+
+# Override the default cleanup function.
+# _cleanup()
+# {
+# 	cd /
+# 	rm -r -f $tmp.*
+# }
+
+. ./common/filter
+
+# real QA test starts here
+
+# Modify as appropriate.
+_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))
+
+_scratch_mkfs >> $seqres.full 2>&1
+_scratch_mount
+
+uuid=$(findmnt -n -o UUID $SCRATCH_MNT)
+
+devinfo_dir="/sys/fs/btrfs/${uuid}/devinfo/1"
+
+# Check if we have the sysfs interface first.
+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
+
+# Writeback above data, as scrub only verify the committed data.
+sync
+
+throttle_mb=50
+# Those are floor and ceiling for us to compare the result, give it a
+# generous +- 10% tolerance.
+throttle_mb_ceiling=55
+throttle_mb_floor=45
+
+# Set the speed limit to 50MiB/s, which should be slower than almost all
+# modern HDD.
+# This would take around 40 sec to scrub above data for SINGLE, double for DUP.
+# With extra time spent on writing the data.
+echo $(($throttle_mb * 1024 * 1024)) > "${devinfo_dir}/scrub_speed_max"
+
+$BTRFS_UTIL_PROG scrub start -B $SCRATCH_MNT > $tmp.scrub_result
+cat $tmp.scrub_result >> $seqres.full
+
+# The output looks like this:
+# Scrub done for 42d25bc2-e8b7-432e-9850-f3314aefffc6
+# Scrub started:    Wed Jan  4 13:12:00 2023
+# Status:           finished
+# Duration:         0:00:30
+# Total to scrub:   7.52GiB
+# Rate:             205.22MiB/s
+# Error summary:    no errors found
+#
+# What we care is that Rate line, and only the int part.
+speed=$(grep "Rate:" $tmp.scrub_result | $AWK_PROG '{print $2}' | cut -f1 -d.)
+
+if [ "$speed" -gt "$throttle_mb_ceiling" -o "$speed" -lt "$throttle_mb_floor" ]; then
+	echo "scrub speed $speed is not properly throttled"
+fi
+
+# success, all done
+status=0
+exit
diff --git a/tests/btrfs/282.out b/tests/btrfs/282.out
new file mode 100644
index 00000000..8d53e7eb
--- /dev/null
+++ b/tests/btrfs/282.out
@@ -0,0 +1,3 @@
+QA output created by 282
+wrote 2147483648/2147483648 bytes at offset 0
+XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-- 
2.39.0


             reply	other threads:[~2023-01-04  8:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-04  8:21 Qu Wenruo [this message]
2023-01-04 22:17 ` [PATCH] btrfs: add a test case to verify scrub speed throttle works Anand Jain
2023-01-04 23:17   ` Qu Wenruo
  -- strict thread matches above, loose matches on Subject: below --
2023-01-05  7:18 Qu Wenruo
2023-01-05 11:04 ` Anand Jain

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=20230104082123.56800-1-wqu@suse.com \
    --to=wqu@suse.com \
    --cc=fstests@vger.kernel.org \
    --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