On 2021/7/2 上午3:41, David Sterba wrote:

On Mon, May 17, 2021 at 05:55:16PM +0800, Qu Wenruo wrote:

quoted

[BUG]
When running fstests with 4K sectorsize and 64K page size (aka subpage
support), the following tests failed:

   $ sudo ./check generic/416 generic/619
   FSTYP         -- btrfs
   PLATFORM      -- Linux/aarch64 rockpi4 5.12.0-rc8-custom+ #9 SMP Tue Apr 27 12:49:52 CST 2021
   MKFS_OPTIONS  -- -s 4k /dev/mapper/arm_nvme-scratch1
   MOUNT_OPTIONS -- /dev/mapper/arm_nvme-scratch1 /mnt/scratch

   generic/416     [failed, exit status 1]- output mismatch (see ~/xfstests-dev/results//generic/416.out.bad)
      QA output created by 416
     -wrote 16777216/16777216 bytes at offset 0
     -XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
     +mount: /mnt/scratch: wrong fs type, bad option, bad superblock on /dev/mapper/arm_nvme-scratch1, missing codepage or helper program, or other error.
     +mount failed
     +(see ~/xfstests-dev/results//generic/416.full for details)
     ...
     (Run 'diff -u ~/xfstests-dev/tests/generic/416.out ~/xfstests-dev/results//generic/416.out.bad'  to see the entire diff)
   generic/619     [failed, exit status 1]- output mismatch (see ~/xfstests-dev/results//generic/619.out.bad)
      QA output created by 619
     -Silence is golden
     +mount: /mnt/scratch: wrong fs type, bad option, bad superblock on /dev/mapper/arm_nvme-scratch1, missing codepage or helper program, or other error.
     +mount failed
     +(see ~/xfstests-dev/results//generic/619.full for details)
     ...
     (Run 'diff -u ~/xfstests-dev/tests/generic/619.out ~/xfstests-dev/results//generic/619.out.bad'  to see the entire diff)
   Ran: generic/416 generic/619
   Failures: generic/416 generic/619
   Failed 2 of 2 tests

[CAUSE]
Those two tests call _scratch_mkfs_sized to create a small fs, all of them
are smaller than the 256M.

Since the fs is small, fstests choose to pass -M to make a mixed btrfs.
(Let's just ignore whether we should pass -M here).

I think this is actually the problem, this should be fixed in fstests.

Yeah, but this still expose a problem.

When -s is specified, why nodesize is not chosen automatically when -M 
is also specified.

For current -s 4k specification, nodesize is chosen automatically by the 
16K default value, not the PAGE_SIZE anymore.

But with -s 4K and -M together, we go 64K as default nodesize which is 
totally wrong.

quoted

Then on 64K page size system, "mkfs.btrfs -s 4K -M -b 128M $dev" will fail

When --mixed is used, use both --sectorsize and --nodesize.

Nope, on 4K systems, when -s 4k and -M is specififed, nodesize is 
automatically chosen as 4K.

No need to specify the nodesize.

In fact, when possible the nodesize should be automatically chosen.

Thus this is the problem I am going to solve.
The fstest failure is just an easy way to expose the bug.

Thanks,
Qu

quoted

with the following error message:

   btrfs-progs v5.11
   See http://btrfs.wiki.kernel.org for more information.

   ERROR: illegal nodesize 65536 (not equal to 4096 for mixed block group)

This is caused by the nodesize selection, which always try to choose the
larger value between pagesize and sectorsize.

This hardcoded PAGESIZE usage in mkfs.btrfs makes us to choose 64K
nodesize even we specified to use 4K sectorsize.

[FIX]
Just use sectorsize as nodesize when -M is specified.

With this fix, above two tests now pass for btrfs subpage case.

This is changing the mkfs behaviour for everybody just to fix a fstests
test case. I disagree to do that. Fstests get weekly releases so if the
test is failing now, it won't next week once a patch is applied.