linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: linux-fsdevel@vger.kernel.org, Dave Chinner <david@fromorbit.com>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	Christoph Hellwig <hch@lst.de>, Jan Kara <jack@suse.cz>
Subject: Re: VFS caching of file extents
Date: Wed, 28 Aug 2024 20:50:47 +0100	[thread overview]
Message-ID: <Zs9_l1w0SuJO4ZbO@casper.infradead.org> (raw)
In-Reply-To: <Zs9+mm8bElKJmz65@tissot.1015granger.net>

On Wed, Aug 28, 2024 at 03:46:34PM -0400, Chuck Lever wrote:
> On Wed, Aug 28, 2024 at 08:34:00PM +0100, Matthew Wilcox wrote:
> > There are a few problems I think this can solve.  One is efficient
> > implementation of NFS READPLUS.
> 
> To expand on this, we're talking about the Linux NFS server's
> implementation of the NFSv4.2 READ_PLUS operation, which is
> specified here:
> 
>   https://www.rfc-editor.org/rfc/rfc7862.html#section-15.10
> 
> The READ_PLUS operation can return an array of content segments that
> include regular data, holes in the file, or data patterns. Knowing
> how the filesystem stores a file would help NFSD identify where it
> can return a representation of a hole rather than a string of actual
> zeroes, for instance.

Thanks for the reference; I went looking for it and found only the
draft.

Another thing this could help with is reducing page cache usage for
very sparse files.  Today if we attempt to read() or page fault on a
file hole, we allocate a fresh page of memory and ask the filesystem to
fill it.  The filesystem notices that it's a hole and calls memset().
If the VFS knew that the extent was a hole, it could use the shared zero
page instead.  Don't know how much of a performance win this would be,
but it might be useful.

  reply	other threads:[~2024-08-28 19:50 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 [this message]
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

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=Zs9_l1w0SuJO4ZbO@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=chuck.lever@oracle.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.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;
as well as URLs for NNTP newsgroup(s).