[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cd2201c9-ff7f-4cfd-acfc-2bba265b3a29@huawei.com>
Date: Wed, 12 Nov 2025 10:49:19 +0800
From: Baokun Li <libaokun1@...wei.com>
To: Theodore Ts'o <tytso@....edu>
CC: <linux-ext4@...r.kernel.org>, <adilger.kernel@...ger.ca>, <jack@...e.cz>,
<linux-kernel@...r.kernel.org>, <kernel@...kajraghav.com>,
<mcgrof@...nel.org>, <ebiggers@...nel.org>, <willy@...radead.org>,
<yi.zhang@...wei.com>, <yangerkun@...wei.com>, <chengzhihao1@...wei.com>,
<libaokun@...weicloud.com>, Baokun Li <libaokun1@...wei.com>
Subject: Re: [PATCH v2 00/24] ext4: enable block size larger than page size
On 2025-11-12 07:54, Theodore Ts'o wrote:
> On Fri, Nov 07, 2025 at 10:42:25PM +0800, libaokun@...weicloud.com wrote:
>> `kvm-xfstests -c ext4/all -g auto` has been executed with no new failures.
>> `kvm-xfstests -c ext4/64k -g auto` has been executed and no Oops was
>> observed, but allocation failures for large folios may trigger warn_alloc()
>> warnings.
> I'm seeing some new failures. ext4/4k -g auto is running without any
> failures, but when I tried to run ext4/64, I got:
>
> ext4/64k: 607 tests, 16 failures, 101 skipped, 7277 seconds
> Failures: ext4/033 generic/472 generic/493 generic/494 generic/495
> generic/496 generic/497 generic/554 generic/569 generic/620
> generic/636 generic/641 generic/643 generic/759 generic/760
> Flaky: generic/251: 80% (4/5)
> Totals: 671 tests, 101 skipped, 79 failures, 0 errors, 6782s
>
> Some of the test failures may be because I was only using a 5G test
> and scratch device, and with a 64k block sze, that might be too small.
> But I tried using a 20G test device, and ext3/033 is still failing but
> with a different error signature:
>
> --- tests/ext4/033.out 2025-11-06 22:04:13.000000000 -0500
> +++ /results/ext4/results-64k/ext4/033.out.bad 2025-11-11 17:57:31.149710364 -0500
> @@ -1,6 +1,8 @@
> QA output created by 033
> Figure out block size
> Format huge device
> +mount: /vdf: fsconfig() failed: Structure needs cleaning.
> + dmesg(1) may have more information after failed mount system call.
>
>
> I took a look at the generc/472 and that appears to be a swap on file failure:
>
> root@...-xfstests:~# /vtmp/mke2fs.static -t ext4 -b 65536 -Fq /dev/vdc
> Warning: blocksize 65536 not usable on most systems.
> /dev/vdc contains a ext4 file system
> created on Tue Nov 11 18:02:13 2025
> root@...-xfstests:~# mount /dev/vdc /vdc
> root@...-xfstests:~# fallocate -l 1G /vdc/swap
> root@...-xfstests:~# mkswap /vdc/swap
> mkswap: /vdc/swap: insecure permissions 0644, fix with: chmod 0600 /vdc/swap
> Setting up swapspace version 1, size = 1024 MiB (1073737728 bytes)
> no label, UUID=a6298248-abf1-42a1-b124-2f6b3be7f597
> root@...-xfstests:~# swapon /vdc/swap
> swapon: /vdc/swap: insecure permissions 0644, 0600 suggested.
> swapon: /vdc/swap: swapon failed: Invalid argument
> root@...-xfstests:~#
I checked the code of the swapon syscall in mm/swapfile.c, and currently
the swapfile does not support LBS. Therefore, some failing test cases can
be filtered out based on this.
/*
* The swap subsystem needs a major overhaul to support this.
* It doesn't work yet so just disable it for now.
*/
if (mapping_min_folio_order(mapping) > 0) {
error = -EINVAL;
goto bad_swap_unlock_inode;
}
Regards,
Baokun
> A number of the other tests (generic/493, generic/494, generic/495,
> generic/496, generic/497, generic/554) are all swapfile tests.
>
> I'm not sure why you're not seeing these issues; what version of
> xfstests are you using? I recently uploaded a new test appliance[1]
> can you try rerunning your tests with the latest test appliance for
> kvm-xfstests?
>
> [1] https://www.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests;
>
> - Ted
>
Powered by blists - more mailing lists