All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>,
	"Darrick J. Wong" <djwong@kernel.org>,
	Matthew Wilcox <willy@infradead.org>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	Darrick Wong <darrick.wong@oracle.com>, Jan Kara <jack@suse.cz>
Subject: Re: VFS caching of file extents
Date: Fri, 30 Aug 2024 08:36:34 +1000	[thread overview]
Message-ID: <ZtD38pOop33OFGUw@dread.disaster.area> (raw)
In-Reply-To: <63DF6C8E-FB1A-4F32-BF4A-7D91A2BBA545@oracle.com>

On Thu, Aug 29, 2024 at 01:52:40PM +0000, Chuck Lever III wrote:
> 
> 
> > On Aug 29, 2024, at 12:00 AM, Christoph Hellwig <hch@lst.de> wrote:
> > 
> >> Wouldn't readplus (and maybe a sparse copy program) rather have
> >> something that is "SEEK_DATA, fill the buffer with data from that file
> >> position, and tell me what pos the data came from"?
> > 
> > Or rather a read operation that returns a length but no data if there
> > is a hole.

Right, it needs to be an iomap level operation - if the map returned
is a hole it records a hole, otherwise it reads the through the page
cache.

But to do this, we need the buffered reads to hit the filesystem
first and get the mapping to determine how to process the incoming
read operation, not go through the page cache first and bypass the
fs entirely because there are cached pages full of zeroes in the
page cache over the hole...

> That is essentially what READ_PLUS does. The "HOLE" array
> members are a length. The receiving client is then free
> to represent that hole in whatever way is most convenient.
> 
> NFSD can certainly implement READ_PLUS so that it returns
> only a single array element -- and that element would be
> either CONTENT or HOLE -- in a possibly short read result.
> (That might be what it is doing already, come to think of
> it).
> 
> The problem with SEEK_DATA AIUI is that READ_PLUS wants
> a snapshot of the file's state. SEEK_DATA is a separate
> operation, so some kind of serialization would be
> necessary to prevent file changes between reads and seeks.

Note that SEEK_DATA also handles unwritten extents correct. It will
report them as a hole if there is no cached data over the range,
otherwise it will be considered data. The only downside of this is
that if the unwritten extent has been read and the page cache
contains clean zeroed folios, SEEK_DATA will always return that
unwritten range as data.

IOWs, unwritten extent mappings for READPLUS would need special
handling to only return data if the page cache folios over the
unwritten range are dirty...

-Dave.
-- 
Dave Chinner
david@fromorbit.com

      reply	other threads:[~2024-08-29 22:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-28 19:34 VFS caching of file extents Matthew Wilcox
2024-08-28 19:46 ` Chuck Lever
2024-08-28 19:50   ` Matthew Wilcox
2024-08-29  6:05     ` Dave Chinner
2024-08-28 20:30 ` Josef Bacik
2024-08-28 23:46 ` Dave Chinner
2024-08-29  1:57 ` Darrick J. Wong
2024-08-29  4:00   ` Christoph Hellwig
2024-08-29 13:52     ` Chuck Lever III
2024-08-29 22:36       ` Dave Chinner [this message]

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=ZtD38pOop33OFGUw@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=chuck.lever@oracle.com \
    --cc=darrick.wong@oracle.com \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=willy@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.