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@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
