Re: SEEK_DATA/SEEK_HOLE with vnode locked

Konstantin Belousov <kostikbel@gmail.com> wrote:
[stuff snipped]
>Could you arrange some local test, without NFS, please?
>I might try to take a look at UFS then.
Well, the two attached trivial programs seem to demonstrate
the problem. crsparse.c just creates a sparse file, then readsparse.c
reads the file, either with just read(2) or using SEEK_HOLE/SEEK_DATA
if "-s" is specified on the command line.
$ crsparse xxx
$ time readsparse xxx
$ time readsparse xxx
$ time readsparse -s xxx
$ time readsparse -s xxx

However, when you look at readsparse.c, you will note that it
does the reading in 1Mbyte chunks, which is what the NFS server
will see for ReadPlus.
If you modify it to do the reading in large chunks, there is no
longer a performance problem.

In summary, I think the performance problem is pretty
specific to how ReadPlus would use SEEK_DATA/SEEK_HOLE,
so I doubt it is worth exploring?

Btw, Linux has now decided to implement ReadPlus just like
Read and not look for/process holes.  They are convinced
that ReadPlus can only efficiently find holes if there is a file
system specific method (ie. a VOP call for FreeBSD) that returns
both data and holes. Until then, ReadPlus won't be any different
than Read for them.
--> I could do this, but I don't see any point, at this time.
      It also appears to violate the intent of ReadPlus in the RFC,
      if not actually a strict violation of the RFC.

rick
ps: readsparse.c works well either way for ZFS, so it was some
     other mysterious weirdness that caused ZFS to be really
     slow for ReadPlus?