Re: SEEK_DATA/SEEK_HOLE with vnode locked

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Sun, 21 Aug 2022 16:05:15 UTC
On Sun, Aug 21, 2022 at 12:02:48AM +0000, Rick Macklem wrote:
> Just to summarize this...
> I was able to do a VOP_SEEK() which would be called with a
> LK_SHARED locked vnode and it seemed to work fine.
> 
> However, ReadPlus (which is like Read, but allows for
> holes to be represented as <offset, length> in the reply
> instead of a stream of 0 bytes) seems to be a performance
> dud.
> 
> I was surprised how poorly it performed compares to ordinary
> Read. Typically it would take 60% longer to read a file. I tried
> sparse and non-sparse files of various sizes and they always
> took longer. (If I disabled SEEK_DATA/SEEK_HOLE in the server
> code, so it never actually did holes, it worked comparably to
> regular Read, so somehow the overhead of doing SEEK_DATA/SEEK_HOLE
> was a big performance hit. It was using LK_SHARED locks, so
> it wasn't serializing the reads, but I don't really know why it
> performed so poorly?)
What filesystem did you used on server?

> 
> Anyhow, unless the performance issue gets resolved, there is
> no reason to commit the code to FreeBSD's main.
> (NFSv4.2 operations, like ReadPlus, are all optional and are not
>  required for an RFC conformant implementation.)

Why not commit?  It might make sense to add it, but guard under some
knob.