Re: [PATCH 2/2] iomap: make zero range flush conditional on unwritten mappings

[Brian Foster <bfoster@redhat.com>]

On Tue, Aug 27, 2024 at 09:32:35PM -0700, Christoph Hellwig wrote:
> On Tue, Aug 27, 2024 at 10:23:10AM -0400, Brian Foster wrote:
> > Yeah, I agree with that. That was one of the minor appeals (to me) of the
> > prototype I posted a while back that customizes iomap_truncate_page() to
> > do unconditional zeroing instead of being an almost pointless wrapper
> > for iomap_zero_range().
> 
> I only very vaguely remember that, you don't happen to have a pointer
> to that?
> 
> 

Yeah, it was buried in a separate review around potentially killing off
iomap_truncate_page():

https://lore.kernel.org/linux-fsdevel/ZlxUpYvb9dlOHFR3@bfoster/

The idea is pretty simple.. use the same kind of check this patch does
for doing a flush, but instead open code and isolate it to
iomap_truncate_page() so we can just default to doing the buffered write
instead.

Note that I don't think this replaces the need for patch 1, but it might
arguably make further optimization of the flush kind of pointless
because I'm not sure zero range would ever be called from somewhere that
doesn't flush already.

The tradeoffs I can think of are this might introduce some false
positives where an EOF folio might be dirty but a sub-folio size block
backing EOF might be clean, and again that callers like truncate and
write extension would need to both truncate the eof page and zero the
broader post-eof range. Neither of those seem all that significant to
me, but just my .02.

Brian