Re: [PATCH v3 0/4] allow partial folio write with iomap_folio_state

[Jinliang Zheng <alexjlzheng@gmail.com>]

On Tue, 12 Aug 2025 17:15:34 +0800, Jinliang Zheng wrote:
> From: Jinliang Zheng <alexjlzheng@tencent.com>
> 
> With iomap_folio_state, we can identify uptodate states at the block
> level, and a read_folio reading can correctly handle partially
> uptodate folios.
> 
> Therefore, when a partial write occurs, accept the block-aligned
> partial write instead of rejecting the entire write.
> 
> For example, suppose a folio is 2MB, blocksize is 4kB, and the copied
> bytes are 2MB-3kB.
> 
> Without this patchset, we'd need to recopy from the beginning of the
> folio in the next iteration, which means 2MB-3kB of bytes is copy
> duplicately.
> 
>  |<-------------------- 2MB -------------------->|
>  +-------+-------+-------+-------+-------+-------+
>  | block |  ...  | block | block |  ...  | block | folio
>  +-------+-------+-------+-------+-------+-------+
>  |<-4kB->|
> 
>  |<--------------- copied 2MB-3kB --------->|       first time copied
>  |<-------- 1MB -------->|                          next time we need copy (chunk /= 2)
>                          |<-------- 1MB -------->|  next next time we need copy.
> 
>  |<------ 2MB-3kB bytes duplicate copy ---->|
> 
> With this patchset, we can accept 2MB-4kB of bytes, which is block-aligned.
> This means we only need to process the remaining 4kB in the next iteration,
> which means there's only 1kB we need to copy duplicately.
> 
>  |<-------------------- 2MB -------------------->|
>  +-------+-------+-------+-------+-------+-------+
>  | block |  ...  | block | block |  ...  | block | folio
>  +-------+-------+-------+-------+-------+-------+
>  |<-4kB->|
> 
>  |<--------------- copied 2MB-3kB --------->|       first time copied
>                                          |<-4kB->|  next time we need copy
> 
>                                          |<>|
>                               only 1kB bytes duplicate copy
> 
> Although partial writes are inherently a relatively unusual situation and do
> not account for a large proportion of performance testing, the optimization
> here still makes sense in large-scale data centers.
> 
> This patchset has been tested by xfstests' generic and xfs group, and
> there's no new failed cases compared to the lastest upstream version kernel.

Sorry forgot to cc Christoph Hellwig :)

thanks,
Jinliang Zheng

> 
> Changelog:
> 
> V3: patch[1]: use WARN_ON() instead of BUG_ON()
>     patch[2]: make commit message clear
>     patch[3]: -
>     patch[4]: make commit message clear
> 
> V2: https://lore.kernel.org/linux-fsdevel/20250810101554.257060-1-alexjlzheng@tencent.com/ 
>     use & instead of % for 64 bit variable on m68k/xtensa, try to make them happy:
>        m68k-linux-ld: fs/iomap/buffered-io.o: in function `iomap_adjust_read_range':
>     >> buffered-io.c:(.text+0xa8a): undefined reference to `__moddi3'
>     >> m68k-linux-ld: buffered-io.c:(.text+0xaa8): undefined reference to `__moddi3'
> 
> V1: https://lore.kernel.org/linux-fsdevel/20250810044806.3433783-1-alexjlzheng@tencent.com/
> 
> Jinliang Zheng (4):
>   iomap: make sure iomap_adjust_read_range() are aligned with block_size
>   iomap: move iter revert case out of the unwritten branch
>   iomap: make iomap_write_end() return the number of written length
>     again
>   iomap: don't abandon the whole copy when we have iomap_folio_state
> 
>  fs/iomap/buffered-io.c | 68 +++++++++++++++++++++++++++++-------------
>  1 file changed, 47 insertions(+), 21 deletions(-)
> 
> -- 
> 2.49.0