Re: [PATCHv8 0/5] iomap: Add support for per-block dirty state to improve write performance

[Matthew Wilcox <willy@infradead.org>]

On Tue, Jun 06, 2023 at 05:13:47PM +0530, Ritesh Harjani (IBM) wrote:
> Hello All,
> 
> Please find PATCHv8 which adds per-block dirty tracking to iomap.
> As discussed earlier this is required to improve write performance and reduce
> write amplification for cases where either blocksize is less than pagesize (such
> as Power platform with 64k pagesize) or when we have a large folio (such as xfs
> which currently supports large folio).

You're moving too fast.  Please, allow at least a few hours between
getting review comments and sending a new version.

> v7 -> v8
> ==========
> 1. Renamed iomap_page -> iomap_folio & iop -> iof in Patch-1 itself.

I don't think iomap_folio is the right name.  Indeed, I did not believe
that iomap_page was the right name.  As I said on #xfs recently ...

<willy> i'm still not crazy about iomap_page as the name of that
   data structure.  and calling the variable 'iop' just seems doomed
   to be trouble.  how do people feel about either iomap_block_state or
   folio_block_state ... or even just calling it block_state since it's
   local to iomap/buffered-io.c
<willy> we'd then call the variable either ibs or fbs, both of which
   have some collisions in the kernel, but none in filesystems
<dchinner> willy - sounds reasonable