[PATCH v2] btrfs: Update btrfs/215

[PATCH v2] btrfs: Update btrfs/215

[Nikolay Borisov]

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

Re: [PATCH v2] btrfs: Update btrfs/215

[Josef Bacik]

On 12/7/20 4:23 AM, Nikolay Borisov wrote:
> 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.

Do we want to just test for non-zero, since the original problem was that we 
weren't getting any error stats at all?  Then we don't have to worry about new 
edge cases in the future.  Thanks,

Josef

Re: [PATCH v2] btrfs: Update btrfs/215

[Nikolay Borisov]

On 7.12.20 г. 18:36 ч., Josef Bacik wrote:
> On 12/7/20 4:23 AM, Nikolay Borisov wrote:
>> 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.
> 
> Do we want to just test for non-zero, since the original problem was
> that we weren't getting any error stats at all?  Then we don't have to
> worry about new edge cases in the future.  Thanks,


I'da rather have precise numbers so that when something changes and the
test blips red I can go and do a targeted investigation. Esp. with the
subapge rework pending.

> 
> Josef
>