FS/XFS testing framework
 help / color / mirror / Atom feed
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

  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