Date:   Fri, 1 Mar 2019 12:03:41 -0500
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
Message-ID: <20190301170341.GC17671@fieldses.org>
References: <20190222215850.20508-1-Anna.Schumaker@Netapp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190222215850.20508-1-Anna.Schumaker@Netapp.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

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.