From: "J. Bruce Fields" <bfields@fieldses.org>
To: Anna Schumaker <schumaker.anna@gmail.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH 0/2] NFSD: Add support for the v4.2 READ_PLUS operation
Date: Fri, 1 Mar 2019 12:03:41 -0500 [thread overview]
Message-ID: <20190301170341.GC17671@fieldses.org> (raw)
In-Reply-To: <20190222215850.20508-1-Anna.Schumaker@Netapp.com>
On Fri, Feb 22, 2019 at 04:58:48PM -0500, Anna Schumaker wrote:
> These patches add server support for the READ_PLUS operation. This
> operation is meant to improve file reading performance when working with
> sparse files, but there are some issues around the use of vfs_llseek() to
> identify hole and data segments when encoding the reply. I've done a
> bunch of testing on virtual machines,
Maybe the VM<->VM case is important too, but it'd be a little easier to
understand a case with real hardware, I think. What kind of disk are
you using, our of curiosity?
Also, what are the file sizes, and the rsize? (Apologies if I
overlooked that.)
> and I found that READ_PLUS performs best if:
It's interesting to think about why these are:
> 1) The file being read is not yet in the server's page cache.
I don't understand this one.
> 2) The read request begins with a hole segment. And
If I understand your current implementation, it's basically:
- seek with SEEK_DATA.
- if that finds a hole, read the rest of the requested range and
return two segments (a hole plus ordinary read results)
- otherwise just return ordinary read data for the whole range.
So, right, in the case the read range starts with data, the seek was
just a waste of time, makes sense.
> 3) The server only performs one llseek() call during encoding
OK, so for that we'd need to compare to a different implementation,
which is what you did elsewhere:
> I also have performance numbers for if we encode every hole and data
> segment but I figured this email was long enough already. I'm happy to
> share it if requested!
Got it. (And, sure, that might be interesting.)
--b.
prev parent reply other threads:[~2019-03-01 17:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-22 21:58 [PATCH 0/2] NFSD: Add support for the v4.2 READ_PLUS operation Anna Schumaker
2019-02-22 21:58 ` [PATCH 1/2] NFSD: nfsd4_encode_read{v}() should encode eof and maxcount Anna Schumaker
2019-02-22 21:58 ` [PATCH 2/2] NFSD: Add basic READ_PLUS support Anna Schumaker
2019-03-01 17:03 ` J. Bruce Fields [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=20190301170341.GC17671@fieldses.org \
--to=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=schumaker.anna@gmail.com \
/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.