From: Qu Wenruo <wqu@suse.com>
To: Theodore Ts'o <tytso@mit.edu>, Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: linux-ext4 <linux-ext4@vger.kernel.org>,
linux-btrfs <linux-btrfs@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: Ext4 iomap warning during btrfs/136 (yes, it's from btrfs test cases)
Date: Sat, 9 Aug 2025 07:41:43 +0930 [thread overview]
Message-ID: <035ad34e-fb1e-414f-8d3c-839188cfa387@suse.com> (raw)
In-Reply-To: <20250808121659.GC778805@mit.edu>
在 2025/8/8 21:46, Theodore Ts'o 写道:
> On Fri, Aug 08, 2025 at 06:20:56PM +0930, Qu Wenruo wrote:
>>
>> 在 2025/8/8 17:22, Qu Wenruo 写道:
>>> Hi,
>>>
>>> [BACKGROUND]
>>> Recently I'm testing btrfs with 16KiB block size.
>>>
>>> Currently btrfs is artificially limiting subpage block size to 4K.
>>> But there is a simple patch to change it to support all block sizes <=
>>> page size in my branch:
>>>
>>> https://github.com/adam900710/linux/tree/larger_bs_support
>>>
>>> [IOMAP WARNING]
>>> And I'm running into a very weird kernel warning at btrfs/136, with 16K
>>> block size and 64K page size.
>>>
>>> The problem is, the problem happens with ext3 (using ext4 modeule) with
>>> 16K block size, and no btrfs is involved yet.
>
>
> Thanks for the bug report! This looks like it's an issue with using
> indirect block-mapped file with a 16k block size. I tried your
> reproducer using a 1k block size on an x86_64 system, which is how I
> test problem caused by the block size < page size. It didn't
> reproduce there, so it looks like it really needs a 16k block size.
>
> Can you say something about what system were you running your testing
> on --- was it an arm64 system, or a powerpc 64 system (the two most
> common systems with page size > 4k)? (I assume you're not trying to
> do this on an Itanic. :-) And was the page size 16k or 64k?
The architecture is aarch64, the host board is Rock5B (cheap and fast
enough), the test machine is a VM on that board, with ovmf as the UEFI
firmware.
The kernel is configured to use 64K page size, the *ext3* system is
using 16K block size.
Currently I tried the following combination with 64K page size and ext3,
the result looks like the following
- 2K block size
- 4K block size
All fine
- 8K block size
- 16K block size
All the same kernel warning and never ending fsstress
- 32K block size
- 64K block size
All fine
I am surprised as you that, not all subpage block size are having
problems, just 2 of the less common combinations failed.
And the most common ones (4K, page size) are all fine.
Finally, if using ext4 not ext3, all combinations above are fine again.
So I ran out of ideas why only 2 block sizes fail here...
Thanks,
Qu
>
> Thanks,
>
> - Ted
>
next prev parent reply other threads:[~2025-08-08 22:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-08 7:52 Ext4 iomap warning during btrfs/136 (yes, it's from btrfs test cases) Qu Wenruo
2025-08-08 8:50 ` Qu Wenruo
2025-08-08 12:16 ` Theodore Ts'o
2025-08-08 22:11 ` Qu Wenruo [this message]
2025-08-09 9:09 ` Zhang Yi
2025-08-09 22:06 ` Qu Wenruo
2025-08-11 15:49 ` Darrick J. Wong
2025-08-11 22:14 ` Qu Wenruo
2025-08-12 16:48 ` Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=035ad34e-fb1e-414f-8d3c-839188cfa387@suse.com \
--to=wqu@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox