move handling of zvol devices out of txg sync thread

[avg]

Summary

That caused a deadlock because the manipulations of zvol devices
is done under spa_namespace_lock, but there are cases where the
lock is held while waiting for the sync thread.

This is imperfect, because zvol updates are done with an arbitrary
delay after the corresponding dataset changes. So, potentially
zvol devices can get out of sync if multiple changes are performed
concurrently.
A better solution would be to queue all changes and apply them to zvol
devices in the same order as they are originally done.

PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203864
See: http://thread.gmane.org/gmane.comp.file-systems.openzfs.devel/2924

[smh]

This looks reasonable however as you say its potentially racey with multiple renames happening.

Would a simple global / pool or pool specific lock taken by zfs_ioc_promote and zfs_ioc_rename help protect against that?

[avg]

In D7179#149342, @smh wrote:

This looks reasonable however as you say its potentially racey with multiple renames happening.

Would a simple global / pool or pool specific lock taken by zfs_ioc_promote and zfs_ioc_rename help protect against that?

It would, but it would also mean having a Giant-like pool-wide serialization for all DSL modifications. And that would be on top of the existing serialization via the sync thread meaning that at most one DSL operation would be performed per txg sync. I am hesitant to introduce that performance impact.

I think that the mentioned above serialization via the sync thread ("sync task") greatly reduces the number of mutations that can happen to a dataset "almost" concurrently, so in practice the changes should be spaced out in time by the sync thread runs.

[avg]

Abandoned in favor of D23478.