Re: Any way to ensure minimal folio size and alignment for iomap based direct IO?

[Matthew Wilcox <willy@infradead.org>]

On Mon, Sep 15, 2025 at 07:32:53PM +0930, Qu Wenruo wrote:
> - No fs block is allowed to cross (large) folio boundaries
>   This ensure that the btrfs checksum routine needs no multi-shot calls
>   for a single data block, and ensures we can use a lot of
>   bio_advance_iter_single() calls to move to the next block.

That's true for pagecache I/O, yes.

> But things are going crazy for iomap based direct IOs.
> 
> I'm getting the following bio during my local tests, which is using 8K fs
> block size with 4K page size:
> 
> [  130.957366] root=5 inode=2464 logical=15974400 length=8192 index=0
> bv_offset=0 bv_len=4096 is not aligned to 8192
> [  130.957376] i=0 page=0xffff8cc616e96000 offset=0 size=4096
> [  130.961977] i=1 page=0xffff8cc61730e000 offset=0 size=4096
> 
> The bio initially looks fine, the length is 8K, properly aligned.
> 
> But the dump of the bio shows it's not the case, instead of a large folio,
> it's two page sized folios.
> 
> This will not pass the btrfs requirement, but weirdly the alignment check
> for the iov_iter at check_direct_IO() shows no problem.
> 
> But unfortunately I can not find any folio allocation for the direct IO
> routine except the zero_page...
> 
> Any clue on the iomap part, or is the btrfs requirement incompatible with
> iomap in the first place?

It's nothing to do with iomap.  We can't make the assumption that
userspace is using large folios for, eg, anonymous memory.  Or if
the memory is backed by page cache, we can't assume that the file
that's mmaped is on a similarly-aligned block device.