All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: 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: Fri, 8 Aug 2025 08:16:59 -0400	[thread overview]
Message-ID: <20250808121659.GC778805@mit.edu> (raw)
In-Reply-To: <4ef2476f-50c3-424d-927d-100e305e1f8e@gmx.com>

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?

Thanks,

					- Ted

  reply	other threads:[~2025-08-08 12:17 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 [this message]
2025-08-08 22:11     ` Qu Wenruo
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=20250808121659.GC778805@mit.edu \
    --to=tytso@mit.edu \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.