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
