• fixup: add mtree entry

LGTM now

tap is highly discouraged for new code. Can you use ATF instead?

Will do, I have been building it as part of the kernel so that's probably why it didn't need a definition in sys/modules. I have been running this manually.

I've been thinking on how to get this code to be more reviewable. Should I maybe try to get it published as a port instead of submitting it as a patch to src/? Most of this code is self-contained, and its size means it will be next to impossible to review in its current state. If we go down the port route, only changes we would be applying to src/ would be non-functional - most would be about turning some static functions global.

Alternatively, I can break this diff apart, get the virtio-dbg transport reviewed since it is more reasonably sized, and either spin off the userspace device emulation component as a port or introduce it later. Which do you think is more reasonable?

• Respond to pauamma's comments

I think you need to add a definition for the virtio_dbg module in sys/modules. Oh, and how do you use it? Eventually we want ATF tests, of course. But I assume for now you've been manually using it somehow?

FYI, at $WORK the only packages we include in the DVD image are:

• ports-mgmt/pkg
• sysutils/py-salt , because Salt can install everything else
• net-mgmt/lldpd, which helps us debug network problems that would prevent Salt from working.

Wow. I'm surprised this bug went unnoticed for so long. Can you get the fix into 14.1 ?

In D44961#1025278, @mav wrote:

I wonder what is your queue depth, so that one message per request per 90 seconds would cause a noticeable storm. Also per-system limiting makes output not very useful, since it does not say much useful about LUNs, ports, commands, etc due to selecting first message out of many, only that something is wrong. Thinking even wider, I find those messages printed on actual completion not very useful, since if there are not a delays, but something is really wrong, the commands many never complete and so the messages may never get printed. I wonder if instead removing all this and once per second checking OOA queues for stuck requests and printing some digests would be more useful.

• bsdinstall: all ESPs created by zfsboot should have a bootloader

• Respond to markj's feedback.

In D44904#1023723, @markj wrote:

In D44904#1023722, @asomers wrote:

In D44904#1023720, @markj wrote:

Would it be worthwhile to document some of your performance findings in geli.8 or so? So that the next user to hit this problem doesn't have to redo your analysis and discover the relationship with vfs.zfs.vdev.aggregation_limit.

I was planning to follow up with a new tip in fortune(6) and at https://wiki.freebsd.org/ZFSTuningGuide . Do you think that would be sufficient or would you like geli(8) too?

I'm skeptical that fortune(6) is good place to document anything performance-related. ZFSTuningGuide seems like a good place, but I think geli.8 is the right document for this kind of knowledge. There are other performance considerations relating to GELI that have nothing to do with ZFS (GELI's thread-per-CPU-per-volume behaviour for instance) that would also belong in a "PERFORMANCE CONSIDERATIONS" section in geli.8.

In D44904#1023720, @markj wrote:

Would it be worthwhile to document some of your performance findings in geli.8 or so? So that the next user to hit this problem doesn't have to redo your analysis and discover the relationship with vfs.zfs.vdev.aggregation_limit.

• Skip the fuse_vnop_do_lseek and fuse_filehandle_close if
• Two more fixes:

Actually, another problem is that EACCES, EINTEGRITY, and EIO errors won't be correctly reported. That problem predates this review, but I'll fix it now.

Looks ok to me, but it's been a long time since I've been active in this code. And it's nice that the patch is so much simpler now!

In D44320#1014666, @imp wrote:

So digging into this a bit more... I bumped the POSIX_VERSION in FreeBSD. This code seemed to compile great when I did that after I moved the BSDs to the #if I highlighted.

However, OpenSSL needs a small tweak. POSIX_VERSION 200809L dropped makecontext, et al, from the standard in Issue 7 (2008 version), and OpenSSL has no fallback for that situation, except to make an exception for GLIBC... So I added an exception for FreeBSD as well, and submitted that pull request. Now I have to fix at least two ports (openssl3 and openssl111), and fight that battle.... At least I have someone lined up to help me there.

So there's a complication to my suggestion, I'll let you know when vvd@ and I have looked at the fallout. I hate kludging things like this pull request, though, I'm spending way more time on this than I thought I'd need to.