Re: [PATCH] iomap: don't lose folio dropbehind state for overwrites

[Ritesh Harjani (IBM) <ritesh.list@gmail.com>]

Jens Axboe <axboe@kernel.dk> writes:

> DONTCACHE I/O must have the completion punted to a workqueue, just like
> what is done for unwritten extents, as the completion needs task context
> to perform the invalidation of the folio(s). However, if writeback is
> started off filemap_fdatawrite_range() off generic_sync() and it's an
> overwrite, then the DONTCACHE marking gets lost as iomap_add_to_ioend()
> don't look at the folio being added and no further state is passed down
> to help it know that this is a dropbehind/DONTCACHE write.
>
> Check if the folio being added is marked as dropbehind, and set
> IOMAP_IOEND_DONTCACHE if that is the case. Then XFS can factor this into
> the decision making of completion context in xfs_submit_ioend().
> Additionally include this ioend flag in the NOMERGE flags, to avoid
> mixing it with unrelated IO.
>
> This fixes extra page cache being instantiated when the write performed
> is an overwrite, rather than newly instantiated blocks.
>
> Fixes: b2cd5ae693a3 ("iomap: make buffered writes work with RWF_DONTCACHE")
> Signed-off-by: Jens Axboe <axboe@kernel.dk>
>
> ---
>
> Found this one while testing the unrelated issue of invalidation being a
> bit broken before 6.15 release. We need this to ensure that overwrites
> also prune correctly, just like unwritten extents currently do.

I guess I did report this to you a while ago when I was adding support
for uncahed buffered-io to xfs_io. But I never heard back from you :( 

https://lore.kernel.org/all/87h649trof.fsf@gmail.com/

No worries, good that we finally have this fixed.

-ritesh