From: Jens Axboe <axboe@kernel.dk>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: zlang@kernel.org, fstests@vger.kernel.org
Subject: Re: [PATCH 2/2] fsx: add support for RWF_DONTCACHE
Date: Tue, 7 Jan 2025 11:24:13 -0700 [thread overview]
Message-ID: <98b65811-dec5-44e7-8b8e-c6f65ab1ee0c@kernel.dk> (raw)
In-Reply-To: <20250107181920.GS6160@frogsfrogsfrogs>
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.
> 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
next prev parent reply other threads:[~2025-01-07 18:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-07 16:05 [PATCHSET v2 0/2] Add RWF_DONTCACHE support Jens Axboe
2025-01-07 16:05 ` [PATCH 1/2] fsstress: add support for RWF_DONTCACHE Jens Axboe
2025-01-07 17:31 ` Darrick J. Wong
2025-01-07 16:05 ` [PATCH 2/2] fsx: " Jens Axboe
2025-01-07 18:19 ` Darrick J. Wong
2025-01-07 18:24 ` Jens Axboe [this message]
2025-01-07 23:22 ` Darrick J. Wong
2025-01-08 0:00 ` Jens Axboe
-- strict thread matches above, loose matches on Subject: below --
2025-01-06 17:48 [PATCHSET 0/2] Add RWF_DONTCACHE support Jens Axboe
2025-01-06 17:48 ` [PATCH 2/2] fsx: add support for RWF_DONTCACHE Jens Axboe
2025-01-07 2:09 ` Darrick J. Wong
2025-01-07 2:12 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=98b65811-dec5-44e7-8b8e-c6f65ab1ee0c@kernel.dk \
--to=axboe@kernel.dk \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=zlang@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox