Re: fstest/btrfs/220 tigger a check-integrity warning

[Wang Yugui <wangyugui@e16-tech.com>]

Hi,

> > > 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