On 2020/2/11 下午12:03, ethanwu wrote: > David Sterba 於 2020-02-11 00:29 寫到: >> On Mon, Feb 10, 2020 at 05:12:48PM +0800, ethanwu wrote: >>> Josef Bacik 於 2020-02-08 00:26 寫到: >>> > On 2/7/20 4:38 AM, ethanwu wrote: >>> >> When resolving one backref of type EXTENT_DATA_REF, we collect all >>> >> references that simply references the EXTENT_ITEM even though >>> >> their (file_pos- file_extent_item::offset) are not the same as the >>> >> btrfs_extent_data_ref::offset we are searching. >>> >> >>> >> This patch add additional check so that we only collect references >>> >> whose >>> >> (file_pos- file_extent_item::offset) == >>> btrfs_extent_data_ref::offset. >>> >> >>> >> Signed-off-by: ethanwu <ethanwu@xxxxxxxxxxxx> >>> > >>> > I just want to make sure that btrfs/097 passes still right? That's >>> > what the key_for_search thing was about, so I want to make sure we're >>> > not regressing. I assume you've run xfstests but I just want to make >>> > doubly sure we're good here. If you did then you can add >>> > >>> > Reviewed-by: Josef Bacik <josef@xxxxxxxxxxxxxx> >>> > >>> > Thanks, >>> > >>> > Josef >>> >>> Thanks for reviewing. >>> >>> I've run the btrfs part of xfstests, 097 passed. >>> Failed at following tests: >>> 074 (failed 2 out of 5 runs), >>> 139, 153, 154, >>> 197, 198(Patches related to these 2 tests seem to be not merged yet?) >>> 201, 202 >>> >>> My kernel environment is 5.5-rc5, and this branch doesn't contain >>> fixes for tests 201 and 202. >>> All these failing tests also failed at the same version without my >>> patch. >> >> I tested the patchset in my environment and besides the above known >> and unrelated failures, there's one that seems to be new and possibly >> related to the patches: >> >> btrfs/125 [18:18:14][ 5937.333021] run fstests btrfs/125 >> at 2020-02-07 18:18:14 >> [ 5937.737705] BTRFS info (device vda): disk space caching is enabled >> [ 5937.741359] BTRFS info (device vda): has skinny extents >> [ 5938.318881] BTRFS: device fsid e34ea734-aeef-484b-8a5b-d061e3bad8c5 >> devid 1 transid 5 /dev/vdb scanned by mkfs.btrfs (21913) >> [ 5938.323180] BTRFS: device fsid e34ea734-aeef-484b-8a5b-d061e3bad8c5 >> devid 2 transid 5 /dev/vdc scanned by mkfs.btrfs (21913) >> [ 5938.327229] BTRFS: device fsid e34ea734-aeef-484b-8a5b-d061e3bad8c5 >> devid 3 transid 5 /dev/vdd scanned by mkfs.btrfs (21913) >> [ 5938.344608] BTRFS info (device vdb): disk space caching is enabled >> [ 5938.347892] BTRFS info (device vdb): has skinny extents >> [ 5938.350941] BTRFS info (device vdb): flagging fs with big metadata >> feature >> [ 5938.360083] BTRFS info (device vdb): checking UUID tree >> [ 5938.470343] BTRFS: device fsid e34ea734-aeef-484b-8a5b-d061e3bad8c5 >> devid 2 transid 7 /dev/vdc scanned by mount (21955) >> [ 5938.476444] BTRFS: device fsid e34ea734-aeef-484b-8a5b-d061e3bad8c5 >> devid 1 transid 7 /dev/vdb scanned by mount (21955) >> [ 5938.480289] BTRFS info (device vdb): allowing degraded mounts >> [ 5938.483738] BTRFS info (device vdb): disk space caching is enabled >> [ 5938.487557] BTRFS info (device vdb): has skinny extents >> [ 5938.491416] BTRFS warning (device vdb): devid 3 uuid >> f86704f4-689c-4677-b5f2-5380cf6be2d3 is missing >> [ 5938.493879] BTRFS warning (device vdb): devid 3 uuid >> f86704f4-689c-4677-b5f2-5380cf6be2d3 is missing >> [ 5939.233288] BTRFS: device fsid 265be525-bf76-447b-8db6-d69b0d3885d1 >> devid 1 transid 250 /dev/vda scanned by btrfs (21983) >> [ 5939.250044] BTRFS info (device vdb): disk space caching is enabled >> [ 5939.253525] BTRFS info (device vdb): has skinny extents >> [ 5949.283384] BTRFS info (device vdb): balance: start -d -m -s >> [ 5949.288563] BTRFS info (device vdb): relocating block group >> 217710592 flags data|raid5 >> [ 5949.322231] BTRFS error (device vdb): bad tree block start, want >> 39862272 have 30949376 >> [ 5949.328136] repair_io_failure: 22 callbacks suppressed >> [ 5949.328139] BTRFS info (device vdb): read error corrected: ino 0 >> off 39862272 (dev /dev/vdd sector 19488) >> [ 5949.333447] BTRFS info (device vdb): read error corrected: ino 0 >> off 39866368 (dev /dev/vdd sector 19496) >> [ 5949.336875] BTRFS info (device vdb): read error corrected: ino 0 >> off 39870464 (dev /dev/vdd sector 19504) >> [ 5949.340325] BTRFS info (device vdb): read error corrected: ino 0 >> off 39874560 (dev /dev/vdd sector 19512) >> [ 5949.409934] BTRFS warning (device vdb): csum failed root -9 ino 257 >> off 2228224 csum This looks like an existing bug, IIRC Zygo reported it before. Btrfs balance just randomly failed at data reloc tree. Thus I don't believe it's related to Ethan's patches. Thanks, Qu > > Hi, > I've rebased my kernel environment to the latest for-next branch, > xfstests is updated to latest as well. > Test 125 still passes many times without even one failure. > > here's my local.config > > export TEST_DEV=/dev/sdc > export TEST_DIR=/mnt/test > export SCRATCH_MNT=/mnt/scratch > export FSTYP=btrfs > export SCRATCH_DEV_POOL="/dev/sdd /dev/sde /dev/sdf /dev/sdg /dev/sdh" > > each device has 80GB capacity. > > Besides, LOGWRITES_DEV is not set and CONFIG_FAULT_INJECTION_DEBUG_FS > is turned off, but both seems to be unrelated to 125. > > thanks, > ethanwu > > > >
Attachment:
signature.asc
Description: OpenPGP digital signature
