MFV r350898: 8423 8199 7432 Implement large_dnode pool feature

[avg]

Summary

8423 8199 7432 Implement large_dnode pool feature

8423 Implement large_dnode pool feature
8199 multi-threaded dmu_object_alloc()
7432 Large dnode pool feature

llumos/illumos-gate@54811da5ac6b517992fdc173df5d605e4e61fdc0
https://github.com/illumos/illumos-gate/commit/54811da5ac6b517992fdc173df5d605e4e61fdc0
https://www.illumos.org/issues/8423
https://www.illumos.org/issues/8199
https://www.illumos.org/issues/7432

ZoL issues:
Improved dnode allocation #6564
Clean up large dnode code #6262
Fix dnode_hold() freeing dnode behavior #8172
Fix dnode allocation race #6414, #6439
Partial: Raw sends must be able to decrease nlevels #6821, #6864
Remove unnecessary txg syncs from receive_object() Closes #7197

Author: Toomas Soome <[e-mail]>

---

This updates FreeBSD large_dnode code to a version that was committed to illumos.
It has some cleanups, improvements and fixes comparing to what we have in FreeBSD now.
I think that the most significant update is 8199 multi-threaded dmu_object_alloc().

[avg]

I am not sure what happened. Looks like arc or phabricator went a little bit nuts.

[jhb]

I think you did an svn merge or the like that set a crap ton of properties on lots of subdirectories? The affected files list from the original e-mail seemed to start off by listing every single directory in the source tree.

[avg]

In D21236#461601, @jhb wrote:

I think you did an svn merge or the like that set a crap ton of properties on lots of subdirectories? The affected files list from the original e-mail seemed to start off by listing every single directory in the source tree.

D21237 is what I actually did. The second run of arc diff --create was sane, I am not sure what went wrong on the first run.