Re: [PATCH 2/2] fsx: add support for RWF_DONTCACHE

["Darrick J. Wong" <djwong@kernel.org>]

On Tue, Jan 07, 2025 at 11:24:13AM -0700, Jens Axboe wrote:
> On 1/7/25 11:19 AM, Darrick J. Wong wrote:
> > On Tue, Jan 07, 2025 at 09:05:15AM -0700, Jens Axboe wrote:
> >> Using RWF_DONTCACHE tells the kernel that any page cache instantiated
> >> by this operation should get pruned once the operation completes. If
> >> data is in cache prior to the operation it will remain there.
> >>
> >> Add ops for testing both the read and write side of this. At startup,
> >> kernel support for this feature is probed. If support isn't available,
> >> uncached/dontcache IO is performed as regular buffered IO. If -Z is
> >> used to turn on O_DIRECT, then uncached/dontcache IO isn't performed.
> > 
> > Huh.  Does the kernel reject RWF_DONTCACHE for directio?  And, if a
> 
> It doesn't, it simply ignores it. Not sure why you ask? It's buffered IO
> after all, falling back to just clearing the flag seems like the most
> sensible solution here.

I was curious, because your code does has_dontcache=0 when -Z is used to
select directio mode.  So I wondered if it that was because the kernel
would return EOPNOTSUPP for directio + RWF_DONTCACHE? :)

Then I wondered if there was actually a good usecase either for letting
userspace specify it, or for filesystems to add it for buffered write
fallback.  At this point I would wager there's a stronger case for
adding drop-behind automatically because userspace shouldn't have to
communicate "write this without accessing the page cache, and don't
leave file contents in the page cache that I already told you not to
do."

Anyway the fstests change satisfies me now so
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>

--D

> > directio implementation falls back to the pagecache (e.g. xfs when doing
> > a sub-fsblock cow write), do we:
> > 
> > (a) want RWF_DONTCACHE to propagate through to the buffered io
> > implementation (which I think xfs does) and
> 
> Maybe? The current implementation keeps things simple and doesn't touch
> any of that stuff, but conceptually it'd make sense to mark those
> buffered ranges as uncached, if instantiated as buffered IO on behalf of
> direct IO.
> 
> > (b) should filesystems *turn it on* any time they fall back, even if the
> > original IO request didn't set DONTCACHE?
> 
> Same answer :-)
> 
> -- 
> Jens Axboe
>