Re: [PATCH v3 3/3] NFSD: Add support for encoding multiple segments

[Christoph Hellwig <hch@infradead.org>]

On Fri, Mar 20, 2015 at 11:17:18AM -0400, J. Bruce Fields wrote:
> Maybe this is a question for xfs developers.
> 
> So, we have a new READ_PLUS call that's basically just a version of READ
> optimized for sparse files:
> 
> 	http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-33#section-15.10
> 
> It allows an NFS server to return either file data (like a normal READ
> call) or, at the server's discretion, records saying "this range of the
> data is all zeroes".
> 
> Anna tried implementing READ_PLUS for knfsd using
> vfs_llseek(.,.,SEEK_HOLE) followed by an ordinary read if that
> determines we're not at a hole.
> 
> (Very) preliminary results suggest that's slower than a plain READ for
> an xfs file with no holes.  (And *much* slower in the ext4 case for some
> reason.)

It should be a fairly cheap operastion, and does extent tree operations
that are pretty similar to an (uncached) read.  Do you have profiles?

> Is that expected, and should we be doing this some other way instead?

Are the read cached or uncached?  If they are from pagecache just
copying the zeroes is pretty much unbeatable compared to extent
tree lookups, so we'd need a new page flag (difficult..) to see
that a page is a hole (and then it would only work for the whole page),
but for uncached reads an optimization would be to tell a read that it's
an NFS READ_PLUS so that it could just read until it reach a hole,
and then we'd need some way to communicate the hole size (or just fall
back to SEEK_HOLE for that case).

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs