Make txg_quiesce visible so it will work for Dtrace

Submitted by: Davide Italiano
Prefer deriving ashift from stripesize when it's available, add
a sysctl to disable this behavior.
In case ZFS doesn't use UMA for buffers there's no need to waste memory
creating zones that will remain empty.

Reviewed by:	pjd

(cherry picked from commit 9d4f84d04805fb7c725f1d1e4cd10f8c9ac41860)
Make it possible to import pool if ashift increased.

(cherry-picked from TrueNAS 3b8a0f9f7963caee66433c5ac4eb435e9e8ae6f6)
Fix typo; while I'm there, also correct the description for the sysctl variable.
Increase default ashift to 4K.
Allow three IOCTLs to be used on suspended pool, restoring state that
existed before IOCTL code refactoring merged change 4445fffb from illumos
at r248571.

This change allows `zpool clear` to be used again to recover suspended pool.
It seems the only was supposed by the code to restore pool operation after
reconnecting lost disks that were required for data completeness.  There
are still cases where `zpool clear` command can just safely stuck due to
deadlocks inside ZFS kernel part, but probably that is better then having
no chances to recover at all.

(cherry picked from commit c034c95e67abdb7eef95a34c9dc188f227a085cf)
Make ZFS to use separate thread to handle SPA_ASYNC_REMOVE async events.
Existing async thread is running only on successfull spa_sync() completion,
that is impossible in case of pool loosing required (last) disk(s).  That
indefinite delay of SPA_ASYNC_REMOVE processing made ZFS to not close the
lost disks, preventing GEOM/CAM from destroying devices and reusing names
on later disk reattach.

In earlier version of the patch I've tried to just run existing thread
immediately, unrelated to spa_sync() completion, but that exposed number
of situations where it could stuck due to locks held by stuck spa_sync(),
that are required for other kinds of async events.

Experiments with OpenIndiana snapshot confirmed that they also have this
issue with lost disks reattach.

(cherry picked from commit 070e8f39ecaa8deb6d80ad9f485ffb7d62225c9a)
Make `zpool clear` to reopen also reconnected cache and spare devices.
Since `zpool status` reports about such kinds of errors, it is strange
that they are not cleared by `zpool clear`.

(cherry picked from commit 3cc4899abadb075e1a1c87b9fe540fec982c89e5)
Block reporting of ZFS features for suspended pools.

Before executing any subcommand, zpool tool fetches pools configuration from
the kernel.  Before features support was added, kernel was regenerating that
configuration based on data always present in memory.  Unfortunately, pool
features list and activity counters are not such. They are stored in ZAP,
that normally resides in ARC, but under heavy memory pressure may be swapped
out.  If pool is suspended at this point, there is no way to recover it back
since any zpool command will stuck.

This change has one predictable flaw: `zpool upgrade` always wish to upgrade
suspended pools, but fortunately it can't do it due to the suspension.

(cherry picked from commit 2a26325c0f59f3a7e507ea2b1c10158ffe46590b)
Change vfs.zfs.write_to_degraded from CTLFLAG_RW to CTLFLAG_RWTUN

Suggested by:	pjd
(cherry picked from commit a590bde3e505abcbe90cb98f2252363e18baac3b)

(cherry picked from commit 993f38fff7985c3dc2a37128c14b4d975ada1871)
Fix typo in sysctl description

Reported by:	Jeremy Chadwick
MFC after:	3 days
(cherry picked from commit b36b09239d80ebc5806b3520c7528e155edee7d1)

(cherry picked from commit 3ce5129c20db35e0183218935a410669a56bd324)
ZFS: Fix a panic while unmounting a busy filesystem.

This particular scenario was easily reproduced using a NFS export.  When the
first 'zfs unmount' occurred, it returned EBUSY via this path, while
vflush() had flushed references on the filesystem's root vnode, which in
turn caused its v_interlock to be destroyed.  The next time 'zfs unmount'
was called, vflush() tried to obtain this lock, which caused this panic.

Since vflush() on FreeBSD is a definitive call, there is no need to check
vfsp->vfs_count after it completes.  Simply #ifdef sun this check.

Submitted by:	avg
Reviewed by:	avg
Approved by:	ken (mentor)
MFC after:	1 month
(cherry picked from commit 74c2859109b2ecb7da28ff31df37a7933d1da6cc)

(cherry picked from commit c6c454b741663b65a0b00d4475dd36d3c27989ee)
Remove UMA zones for ZIO larger than PAGE_SIZE (4KB on amd64),
which are not multiple of page size. At a lower level UMA will
still allocate multiples of page size, so we would end up with
two zones with the same number of pages but different size.
Collapse them in a single zone to avoid this.

(cherry picked from commit 7d9e775affd57d730a380d8b4ca655766c937d8f)
Enable kernel-specific code for FreeBSD also on other systems that use
the kernel of FreeBSD.

Reviewed by:	pjd

(cherry picked from commit 81396ac4d6991043acbdb2f768306335d3db31f2)
(cherry picked from commit a1e8db4102097816399608faef4fdb412dea6d24)
Fix compile with C++.
MFV r251619:

ZFS needs better comments.

Illumos ZFS issues:
  3741 zfs needs better comments

MFC after:      2 weeks

(cherry picked from commit 9d0815fcd162db9197ce3750a1e17c721ecbd315)
(cherry picked from commit 78704c8ecfa55fb84b597af85fe80f11a1b595d3)
Don't proceed with vdev_label_init() when pool is imported read-only.

(cherry picked from commit a8a904a286a330477260eebe146df06146fcf595)
zfs: try to properly handle i/o errors in mappedread_sf

Unconditionally freeing a page is not good, especially if it is the page
that was wired by the caller.  The checks are picked up from
kern_sendfile.

MFC after:	3 weeks

(cherry picked from commit aa9dd56782a20f5d5a87859acf27f149c9f6ba56)
(cherry picked from commit 333f7f23f81ce9e88ae409a23b95ad787760d0e8)
MFV r252839:

Quoting illumos issue #3836:
  Currently zio_free() always puts the zio on a list for subsequent
  processing by zio_free_sync().  This is only necessary for frees that
  might need to issue reads (gang and dedup blocks).

  By processing the majority of the frees as we encounter them, we reduce
  the amount of time that the spa_sync() thread spends burning CPU and
  not doing any i/o, thus increasing the overall write throughput of the
  system.

Illumos ZFS issues:
  3836 zio_free() can be processed immediately in the common case

MFC after:	1 week

(cherry picked from commit be7444451060bb6bbf361f251d66c2a5c689d37f)
(cherry picked from commit 4fae45050c826b2aa36fc066b0fc3edbc9256dbc)