On 2021/4/15 下午10:52, riteshh wrote:
On 21/04/15 09:14AM, riteshh wrote:
On 21/04/12 07:33PM, Qu Wenruo wrote:
Good news, you can fetch the subpage branch for better test results.
Now the branch should pass all generic tests, except defrag and known
failures.
And no more random crash during the tests.
Thanks, let me test it on PPC64 box.
I do see some failures remaining with the patch series.
However the one which is blocking my testing is the tests/generic/095
I see kernel BUG hitting with below signature.
That's pretty different from my tests.
As I haven't seen such BUG_ON() for a while.
Please let me know if this a known failure?
<xfstests config>
#:~/work-tools/xfstests$ sudo ./check -g auto
SECTION -- btrfs_4k
FSTYP -- btrfs
PLATFORM -- Linux/ppc64le qemu 5.12.0-rc7-02316-g3490dae50c0 #73 SMP Thu
Apr 15 07:29:23 CDT 2021
MKFS_OPTIONS -- -f -s 4096 -n 4096 /dev/loop3
I see you're using -n 4096, not the default -n 16K, let me see if I can
reproduce that.
But from the backtrace, it doesn't look like the case,
as it happens for data path, which means it's only related to sectorsize.
MOUNT_OPTIONS -- /dev/loop3 /mnt1/scratch
<kernel logs>
[ 6057.560580] BTRFS warning (device loop3): read-write for sector size 4096
with page size 65536 is experimental
[ 6057.861383] run fstests generic/095 at 2021-04-15 14:12:10
[ 6058.345127] BTRFS info (device loop2): disk space caching is enabled
[ 6058.348910] BTRFS info (device loop2): has skinny extents
[ 6058.351930] BTRFS warning (device loop2): read-write for sector size 4096
with page size 65536 is experimental
[ 6059.896382] BTRFS: device fsid 43ec9cdf-c124-4460-ad93-933bfd5ddbbd devid 1
transid 5 /dev/loop3 scanned by mkfs.btrfs (739641)
[ 6060.225107] BTRFS info (device loop3): disk space caching is enabled
[ 6060.226213] BTRFS info (device loop3): has skinny extents
[ 6060.227084] BTRFS warning (device loop3): read-write for sector size 4096
with page size 65536 is experimental
[ 6060.234537] BTRFS info (device loop3): checking UUID tree
[ 6061.375902] assertion failed: PagePrivate(page) && page->private, in
fs/btrfs/subpage.c:171
[ 6061.378296] ------------[ cut here ]------------
[ 6061.379422] kernel BUG at fs/btrfs/ctree.h:3403!
cpu 0x5: Vector: 700 (Program Check) at [c0000000260d7490]
pc: c000000000a9370c: assertfail.constprop.11+0x34/0x48
lr: c000000000a93708: assertfail.constprop.11+0x30/0x48
sp: c0000000260d7730
msr: 800000000282b033
current = 0xc0000000260c0080
paca = 0xc00000003fff8a00 irqmask: 0x03 irq_happened: 0x01
pid = 739712, comm = fio
kernel BUG at fs/btrfs/ctree.h:3403!
Linux version 5.12.0-rc7-02316-g3490dae50c0 (riteshh@xxxx) (gcc (Ubuntu
8.4.0-1ubuntu1~18.04) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.30) #73 SMP Thu
Apr 15 07:29:23 CDT 2021
enter ? for help
[c0000000260d7790] c000000000a90280 btrfs_subpage_assert.isra.9+0x70/0x110
[c0000000260d77b0] c000000000a91064 btrfs_subpage_set_uptodate+0x54/0x110
[c0000000260d7800] c0000000009c6d0c btrfs_dirty_pages+0x1bc/0x2c0
This is very strange.
As in btrfs_dirty_pages(), the pages passed in are already prepared by
prepare_pages(), which means all of them should have Private set.
Can you reproduce the bug reliable?
BTW, are using running the latest branch, with this commit at top?
commit 3490dae50c01cec04364e5288f43ae9ac9eca2c9
Author: Qu Wenruo <w...@suse.com>
Date: Mon Feb 22 14:19:38 2021 +0800
btrfs: allow read-write for 4K sectorsize on 64K page size systems
As I was updating the patchset until the last minute.
Thanks,
Qu
[c0000000260d7880] c0000000009c7298 btrfs_buffered_write+0x488/0x7f0
[c0000000260d79d0] c0000000009cbeb4 btrfs_file_write_iter+0x314/0x520
[c0000000260d7a50] c00000000055fd84 do_iter_readv_writev+0x1b4/0x260
[c0000000260d7ac0] c00000000056114c do_iter_write+0xdc/0x2c0
[c0000000260d7b10] c0000000005c2d2c iter_file_splice_write+0x2ec/0x510
[c0000000260d7c30] c0000000005c1ba0 do_splice_from+0x50/0x70
[c0000000260d7c50] c0000000005c37e8 do_splice+0x5a8/0x910
[c0000000260d7cd0] c0000000005c3ce0 sys_splice+0x190/0x300
[c0000000260d7d60] c000000000039ba4 system_call_exception+0x384/0x3d0
[c0000000260d7e10] c00000000000d45c system_call_common+0xec/0x278
--- Exception: c00 (System Call) at 00007ffff72ef170
-ritesh
