Re: [PATCH] fstests: btrfs: add a test case to verify fsverity on compressed files

[Qu Wenruo <wqu@suse.com>]

在 2026/10/10 18:32, Eric Biggers 写道:
> On Sat, Oct 10, 2026 at 01:55:08PM +1030, Qu Wenruo wrote:
>> There is a bug report that with the recently enabled large folios
>> support, compressed files on btrfs can give random but reproducible
>> warnings about file corruption.
>>
>> It turns out to be a bug in the verification range, where blocks not
>> included in the read range are passed to be verified.
>>
>> Add a new regression test case for it, the workload is pretty simple:
>>
>> - Create a 64M file with compressed file extents
>> - Enable fsverity digest on that file
>> - Drop page cache
>> - Read that file
>> - Verify there is no "FILE CORRUPTED!" warning
>>
>> Signed-off-by: Qu Wenruo <wqu@suse.com>
>> ---
>>   tests/btrfs/359     | 45 +++++++++++++++++++++++++++++++++++++++++++++
>>   tests/btrfs/359.out |  6 ++++++
>>   2 files changed, 51 insertions(+)
>>   create mode 100755 tests/btrfs/359
>>   create mode 100644 tests/btrfs/359.out
>>
>> diff --git a/tests/btrfs/359 b/tests/btrfs/359
>> new file mode 100755
>> index 00000000..2047d965
>> --- /dev/null
>> +++ b/tests/btrfs/359
>> @@ -0,0 +1,45 @@
>> +#! /bin/bash
>> +# SPDX-License-Identifier: GPL-2.0
>> +# Copyright (c) 2026 SUSE S.A.  All Rights Reserved.
>> +#
>> +# FS QA Test 359
>> +#
>> +# Test if btrfs handles fsverity read correctly without corruption warning
>> +#
>> +. ./common/preamble
>> +_begin_fstest auto quick verity compress
>> +
>> +_fixed_by_kernel_commit xxxxxxxxxxxx \
>> +	"btrfs: fix the fsverity callback where unexpected range is verified"
>> +
>> +. ./common/filter
>> +. ./common/verity
>> +
>> +_require_scratch_verity
> 
> Missing _require_check_dmesg?

Right, thanks for pointing out this.
> 
> Also, sourcing common/verity adds nodatasum to the mount options.
> Doesn't that disable compression too?

It can still be override by the extra "-o compress" option at later 
_scratch_mount() call.

In fact after the run, the fs still has compressed extents, e.g:

	item 201 key (257 EXTENT_DATA 66977792) itemoff 5577 itemsize 53
		generation 9 type 1 (regular)
		extent data disk byte 15724544 nr 4096
		extent data offset 0 nr 131072 ram 131072
		extent compression 1 (zlib)
		extent encryption 0

On the hand, I believe it's possible to craft a generic test case that 
doesn't require any btrfs specific mount option.

Using holes can still force btrfs to split the reads and trigger the 
warning.

I'll send out a generic test instead.

Thanks,
Qu





> 
> - Eric