From: Nikolay Borisov <nborisov@suse.com>
To: linux-btrfs@vger.kernel.org, fstests@vger.kernel.org
Cc: Nikolay Borisov <nborisov@suse.com>
Subject: [PATCH v2] btrfs: Update btrfs/215
Date: Mon, 7 Dec 2020 11:23:18 +0200 [thread overview]
Message-ID: <20201207092318.950548-1-nborisov@suse.com> (raw)
This patch updates btrfs/215 to work with latest upstream kernel. That's
required since commit 324bcf54c449 ("mm: use limited read-ahead to satisfy read")
changed readahead logic to always issue a read even if the RA pages are
set to 0. This results in 1 extra io being issued so the counts in the
test should be incremented by 1. Also use the opportunity to update the
commit reference since it's been merged in the upstream kernel.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
---
V2:
* Updated comment above buffered read issue command to better describe why 2
failures are expected.
tests/btrfs/215 | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/tests/btrfs/215 b/tests/btrfs/215
index 4acc288a9f60..748287e74cdf 100755
--- a/tests/btrfs/215
+++ b/tests/btrfs/215
@@ -6,7 +6,7 @@
#
# Test that reading corrupted files would correctly increment device status
# counters. This is fixed by the following linux kernel commit:
-# btrfs: Increment device corruption error in case of checksum error
+# 814723e0a55a ("btrfs: increment device corruption error in case of checksum error")
#
seq=`basename $0`
seqres=$RESULT_DIR/$seq
@@ -70,19 +70,19 @@ _scratch_mount
# disable readahead to avoid skewing the counter
echo 0 > /sys/fs/btrfs/$uuid/bdi/read_ahead_kb
-# buffered reads whould result in a single error since the read is done
-# page by page
+# buffered reads whould result in 2 errors since readahead code always submits
+# at least 1 page worth of IO and it will be counted as an error as well
$XFS_IO_PROG -c "pread -b $filesize 0 $filesize" "$SCRATCH_MNT/foobar" > /dev/null 2>&1
errs=$($BTRFS_UTIL_PROG device stats $SCRATCH_DEV | awk '/corruption_errs/ { print $2 }')
-if [ $errs -ne 1 ]; then
- _fail "Errors: $errs expected: 1"
+if [ $errs -ne 2 ]; then
+ _fail "Errors: $errs expected: 2"
fi
# DIO does check every sector
$XFS_IO_PROG -d -c "pread -b $filesize 0 $filesize" "$SCRATCH_MNT/foobar" > /dev/null 2>&1
errs=$($BTRFS_UTIL_PROG device stats $SCRATCH_DEV | awk '/corruption_errs/ { print $2 }')
-if [ $errs -ne 5 ]; then
- _fail "Errors: $errs expected: 1"
+if [ $errs -ne 6 ]; then
+ _fail "Errors: $errs expected: 6"
fi
# success, all done
--
2.17.1
next reply other threads:[~2020-12-07 9:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-07 9:23 Nikolay Borisov [this message]
2020-12-07 16:36 ` [PATCH v2] btrfs: Update btrfs/215 Josef Bacik
2020-12-08 8:15 ` Nikolay Borisov
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=20201207092318.950548-1-nborisov@suse.com \
--to=nborisov@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