On 2021/5/25 下午6:20, Ritesh Harjani wrote:
[...]

quoted

quoted

- 9d57e61bf723 ("of/pci: Add IORESOURCE_MEM_64 to resource flags for 64-
    bit memory addresses")
    Will screw up at least my ARM board, which is using device tree for
    its PCIE node.
    Have to revert it.

- 764c7c9a464b ("btrfs: zoned: fix parallel compressed writes")
    Will screw up compressed write with striped RAID profile.
    Fix sent to the mail list:

https://patchwork.kernel.org/project/linux-btrfs/patch/20210525055243.85166-1-wqu@suse.com/


- Known btrfs mkfs bug
    Fix sent to the mail list:

https://patchwork.kernel.org/project/linux-btrfs/patch/20210517095516.129287-1-wqu@suse.com/


- btrfs/215 false alert
    Fix sent to the mail list:

https://patchwork.kernel.org/project/linux-btrfs/patch/20210517092922.119788-1-wqu@suse.com/

Please wait for while.

I just checked my latest result, the branch doesn't pass my local test
for subpage case.

I'll fix it first, sorry for the problem.

Ok, yes (it's failing for me in some test case).
Sure, will until your confirmation.

Got the reason. The patch "btrfs: allow submit_extent_page() to do bio
split for subpage" got a conflict when got rebased, due to zone code change.

The conflict wasn't big, but to be extra safe, I manually re-craft the
patch from the scratch, to find out what's wrong.

During that re-crafting, I forgot to delete two lines, prevent
btrfs_add_bio_page() from splitting bio properly, and submit empty bio,
thus causing an ASSERT() in submit_extent_page().

The bug can be reliably reproduced by btrfs/060, thus that one can be a
quick test to make sure the problem is gone.

BTW, for older subpage branch, the latest one without problem is at HEAD
2af4eb21b234c6ddbc37568529219d33038f7f7c, which I also tested on a
Power8 VM, it passes "-g auto" with only 18 known failures.

I believe it's now safe to re-test.

Really sorry for the inconvenience.

Thanks,
Qu

-ritesh

quoted

Thanks,
Qu

quoted

Thanks,
Qu

quoted

Thanks
-ritesh

quoted

Thanks,
Qu

quoted

Thanks again for the awesome report!
Qu

quoted

-ritesh

quoted

quoted

2. btrfs/124 failure.

I guess below could be due to small size of the device?

xfstests.global-btrfs/4k.btrfs/124
Error Details
- output mismatch (see /results/btrfs/results-4k/btrfs/124.out.bad)

Again passes locally.

But accroding to your fs, I notice several unbalanced disk usage:

# /usr/local/bin/btrfs filesystem show
Label: none  uuid: fbb48eb6-25c7-4800-8656-503c1e502d85
      Total devices 2 FS bytes used 32.00KiB
      devid    1 size 5.00GiB used 622.38MiB path /dev/vdc
      devid    2 size 2.00GiB used 622.38MiB path /dev/vdi

Label: none  uuid: d3c4fb09-eea2-4dea-8187-b13e97f4ad5c
      Total devices 4 FS bytes used 379.12MiB
      devid    1 size 5.00GiB used 8.00MiB path /dev/vdb
      devid    3 size 20.00GiB used 264.00MiB path /dev/vde
      devid    4 size 20.00GiB used 1.26GiB path /dev/vdf

We had reports about btrfs doing poor work when handling
unbalanced disk
sizes.
I had a purpose to fix it, with a little better calcuation, but still
not
yet perfect.

Thus would you mind to check if the test pass when all the disks in
SCRATCH_DEV_POOL are in the same size?

Of course we need to fix the problem of ENOSPC for unbalanced
disks, but
that's a common problem and not exacly related to subpage.
I should take some time to refresh the unbalanced disk usage patches
soon.

Thanksm
Qu

[...]

quoted

-ritesh