Re: [PATCH v2 13/16] iomap: move read/readahead logic out of CONFIG_BLOCK guard

[Gao Xiang <hsiangkao@linux.alibaba.com>]

On 2025/9/13 04:09, Joanne Koong wrote:
> On Fri, Sep 12, 2025 at 3:56 PM Joanne Koong <joannelkoong@gmail.com> wrote:
>>

...

>>>>> but I don't see it will happen.
>>>>>
>>>>> [1] https://lore.kernel.org/linux-fsdevel/YfivxC9S52FlyKoL@B-P7TQMD6M-0146/
> 
> (sorry, just saw this part of the email otherwise I would have
> included this in the previous message)
> 
> Thanks for the link to the thread. My understanding is that the large
> folio optimizations stuff was added to iomap in July 2023 (afaict from
> the git history) and iomap is entangled with the block layer but it's
> becoming more of a generic interface now. Maybe now it makes sense to
> go through iomap's interface than it did in 2022, but of course David
> has the most context on this.

Again, I really think iomap callback model is not good stuff especially
as it becomes a more generic thing, and it seems inflexible compared
with other interfaces like the page cache (it also has callbacks
but many of them are just a few entrances of IO flows) or bio kAPIs.

As in the previous example, network filesystems generally don't need
any L2P logic (in principle, FUSE is more like a network filesystem),
but they still have to implement those iomap dummy callbacks and
ignore `iomap->addr`.


As for per-block dirty/uptodate tracking, that is just an atomic
feature to manage sub-folio metadata, but iomap is initially a part
which is out of XFS, and basically standard flows for disk/pmem fses.
I really think better generic interfaces are like lego bricks instead,
therefore filesystems can optionally use any of those atomic features
instead of just calling in iomap {read,write,writeback} maze-like
helpers and do different work in the callback hooks (even not all
filesystems need this).

I've mentioned too in
https://lore.kernel.org/r/d631c71f-9d0d-405f-862d-b881767b1945@linux.alibaba.com
https://lore.kernel.org/r/20250905152118.GE1587915@frogsfrogsfrogs

Thanks,
Gao Xiang



> 
> 
> Thanks,
> Joanne
> 
>>>>>
>>>>> Thanks,
>>>>> Gao Xiang
>>>>
>>>