Re: SEEK_DATA/SEEK_HOLE with vnode locked
- Reply: Rick Macklem : "Re: SEEK_DATA/SEEK_HOLE with vnode locked"
- In reply to: Rick Macklem : "Re: SEEK_DATA/SEEK_HOLE with vnode locked"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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.