Date: Sun, 21 Aug 2022 19:05:15 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org> Subject: Re: SEEK_DATA/SEEK_HOLE with vnode locked Message-ID: <YwJXuz5DsuOmyA6t@kib.kiev.ua> In-Reply-To: <YT4PR01MB9736B24FDE64C945C2C9EC8EDD6F9@YT4PR01MB9736.CANPRD01.PROD.OUTLOOK.COM> References: <YQBPR0101MB97420AD41791E544519A0A2DDD659@YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM> <YvQ7MYXPl0AugojS@kib.kiev.ua> <YT4PR01MB9736B24FDE64C945C2C9EC8EDD6F9@YT4PR01MB9736.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YwJXuz5DsuOmyA6t>