Hi,

quoted

quoted

xfstest/btrfs/220 tigger check-integrity warning.

btrfs source:  5.15.0-0.rc5 with btrfs pull for rc6

btrfs kernel config:
CONFIG_BTRFS_FS=m
CONFIG_BTRFS_FS_POSIX_ACL=y
CONFIG_BTRFS_FS_CHECK_INTEGRITY=y
# CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set
# CONFIG_BTRFS_DEBUG is not set
CONFIG_BTRFS_ASSERT=y
CONFIG_BTRFS_FS_REF_VERIFY=y

reproduce frequency: 100%

[ 1917.552758] btrfs: attempt to write superblock which
references block M
@5242880 (sdb2/5242880/0) which is not flushed out of disk's
write cache (block
flush_gen=1, dev->flush_gen=0)!

Anything special about /dev/sdb? I can reproduce if test device is zram
since zram seems to handle FUA in its way.
For normal device backing by file/disk, the test always passed on my side.

Thanks for this info.  

I checked it on some disks.
passed:
	SSD/SAS	PX05SMQ040
failed:
	SSD/SAS		HUSMH842
	SSD/NVMe	SM963/SM1715
I noticed that PX05SMQ040 is 'WCE:1/write back', but HUSMH842 is'WCE:0/write
through', both SM963 and SM1715 are 
' [0:0] : 0     Volatile Write Cache Not Present/write through'

When I changed the SSD/SAS from write through to write back,
The result of fstest/btrfs/220 on HUSMH842 is changed from failed to
passed.
# sdparm --set=WCE --save /dev/sda

so there is some process in btrfs wrongly depends on block disk write
back?

Best Regards
Wang Yugui (wangyugui@e16-tech.com)
2021/10/22