Hmm, not sure how you concluded that this isn't a FreeNAS problem (or at least a ZFS problem)
I never concluded anything. All I was saying is that generally we don't really care about the stuff going on inside the jail. If you look at some of our bug tickets many of them are closed to 3rd party to resolve. FreeNAS provides the jail framework, and that's about it. Many programs don't work right with ZFS. Read up on df and du on ZFS. They aren't quite 100% because of how ZFS works. And anyone who uses FreeBSD or even Linux knows about those 2 commands.
Generally, if you can prove it the framework that FreeNAS provides, the ticket will be handled accordingly. But... many tickets put in either are proven to not be the jail framework or are at least not proven to be a problem for us.
Ex1: One user puts in a ticket because he gets weird errors from one application when he writes very large files. Turns out of he does a dd write inside his jail it stops writing at 4GB. Not our problem.. ticket closed to 3rd party to resolve. What was weird about this was that I created the same jail with the same version and I created a 10GB file with zero problems. We don't even know why he couldn't write 4GB but I could!
Ex2: User puts in a ticket because some program he tries to compile inside his jail is using some wacky calculation to determine freespace and his getting a total free space of something like 120KB. The compiler crashes with an insufficient disk space message. It's clear the program doesn't run with the way ZFS handles free space, but again, that's not *our* problem to solve. The problem was that his program wasn't using the proper method for determining free space and as a result the program wouldn't compile. Ticket was closed to 3rd part to resolve. It's our fault because we use ZFS. But it wasn't our problem to fix either. ;) (This was similar in why df/du don't quite work with ZFS).
I haven't seen anything like this on any of the different platforms I use zsh+oh-my-zsh on, and I also didn't find any similar reports on the Internet. And it's not due to lack of usage of this software. zsh is downloaded about 6,000 times per month and the oh-my-zsh project has +14,000 stars on GitHub (somewhere around the top 20 most popular project on github), so it's not like these are some obscure pieces of software (even if "you haven't heard of them" ;) ).
Eh, those numbers aren't "blow my hair back". I've seen small obscure programs have numbers higher than that. 6000 downloads a month is just 50000 a year. That's not very much in a world with more than 3 billion computers. But it really doesn't matter how obscure it is or isn't. That doesn't determine how well a program works or doesn't work.
Edit: One thing to think about is this.. if there's only 50000 downloads a year, what's the chances that one of those 50000 in a year are likely to install it in a FreeNAS jail. You're looking for a very specific situation, and so anything that isn't a very very large project likely has a very small subset of users meeting these conditions. It's the sad truth. So I'm not really surprised you aren't finding much information on your specific issue.
Having said all that, I haven't found the specific use case that triggers this error, so unless someone has seen the same problem I realize it's going to be hard to debug with the information I've given. I'll try to narrow down exactly what is causing the hang and will report back.
A case that triggers the error would be useful as it might point a finger at what is going wrong.
