zvol rework (#2484)
* Set current->bio_{list,tail} to NULL before submit_bio()
  Linux attempts to avoid recursive processing of bios in
  generic_make_request by storing a list of bios being processed in
  current task_struct. Prior to Linux 2.6.34, this was done with
  current->bio_list and current->bio_tail. When current->bio_tail
  non-NULL, generic_make_request() would add IOs to the existing list and
  return. In Linux 2.6.34, these two were consolidated into
  current->bio_list. The value of that pointer serves the purpose that
  current->bio_tail previously served in generic_make_request().

  This will deadlock when we have a generic_make_request function
  submitting IOs on top of ZFS and we execute a code path that is not
  asynchronous until the operation is handed off to the underlying block
  IO layer via zio_wait(). That causes us to block in zio_wait() block on
  a ZIO that is effectively ignored because it will not be processed until
  we return. Being blocked waiting for something that will not happen
  until we return causes a deadlock.

  An example of this is running mkfs.ext4 on a zvol with the zvol
  refactoring code in place. In that case, zil_flush_vdevs() will hand off
  the flush IOs to the block layer through zio_wait() in a synchronous
  path, which deadlocks. We correct this by saving current->bio_tail or
  current->bio_list depending on the kernel, changing the value is to NULL
  for the duration of submit_bio() and changing it back afterward.

  Signed-off-by: Richard Yao <ryao@gentoo.org>

* zvol processing should use struct bio
  The main impetus for this patch is the Illumos taskq import. The ZoL
  zvol code operated in an interrupt context to take advantage of the IO
  elevator and the SPL taskq code was (ab)used to form the bottom half.
  The SPL taskq code was designed to be callable in an interrupt context
  while the Illumos taskq code was designed to expect the assistance of
  the thread thread scheduler. Since Linux's thread scheduler does not
  provide that assistance, we must trampoline through the system workqueue
  to continue providing the bottom half when using the Illumos taskq code.
  This seems unnecessarily complex when we consider that Illumos itself
  does not perform this emulation and the recent multiqueue work in Linux
  has identified interrupt processing as a major bottleneck on Linux:

  http://kernel.dk/systor13-final18.pdf

  The entry point for zvol operations is zfs_request(). That is called in
  an interrupt context by blk_queue_bio(), which is the kernel's generic
  ->make_request() handler. Registering our own handler allows us to avoid
  this. Comments in the code suggest that this was not done to gain the
  benefit of having Linux's IO elevator do merging. However, the DMU
  already does write merging while arc_read() should implicitly merge read
  IOs because only 1 thread is permitted to fetch the buffer. In addition,
  the main consumers of zvols are VMs and iSCSI shares, which have their
  own elevators to merge IOs. Furthermore, commercial ZFSOnLinux
  distributions report that regular files are more performant than zvols.
  That strongly suggests that the original rationale for using Linux'
  generic ->make_request() handler was invalid.

  Some minor refactoring allows us to register zfs_request() as our
  ->make_request() handler. This eliminates an obstacle to importing the
  Illumos taskq code while giving us several additional benefits:

  1. No per zvol spinlocks.
  2. No redundant IO elevator processing.
  3. Interrupts are disabled only when actually necessary.
  4. No redispatching of IOs under heavy load.
  5. Linux's page out routines will properly block.
  6. Many autotools checks become obsolete.

  It is worth noting that the previous zvol code would redispatch IOs when
  all zio taskq threads were in use. The consequence being that IOs could
  be redispatched and potentially, reordered across barriers. This
  explains an obscure IRC report about corruption on zvol-backed iSCSI
  shares triggered by a kernel panic during heavy load. It was thought
  that the initiator did something wrong, but now it is clear that the
  zvol code itself could reorder, which explains the incident.

  Signed-off-by: Richard Yao <ryao@gentoo.org>

* Remove rq_for_each_segment() autotools check
  Signed-off-by: Richard Yao <ryao@gentoo.org>

* Remove rq_is_sync() autotools check
  Signed-off-by: Richard Yao <ryao@gentoo.org>

* Remove blk_end_request() autotools check.
  Signed-off-by: Richard Yao <ryao@gentoo.org>

* Remove blk_requeue_request() autotools check
  Signed-off-by: Richard Yao <ryao@gentoo.org>

* Remove blk_fetch_request() autotools check
  Signed-off-by: Richard Yao <ryao@gentoo.org>

* Remove blk_rq_pos() autotools check
  Signed-off-by: Richard Yao <ryao@gentoo.org>

* Remove blk_rq_bytes()/blk_rq_sectors autotools checks
  Signed-off-by: Richard Yao <ryao@gentoo.org>
illumos 4970 through 4974 - extreme rewind enhancements

4970 need controls on i/o issued by zpool import -XF
4971 zpool import -T should accept hex values
4972 zpool import -T implies extreme rewind, and thus a scrub
4973 spa_load_retry retries the same txg
4974 spa_load_verify() reads all data twice
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Reviewed by: Dan McDonald <danmcd@omniti.com>
Reviewed by: George Wilson <george.wilson@delphix.com>
Approved by: Robert Mustacchi <rm@joyent.com>

References:
    https://www.illumos.org/issues/4970
    https://www.illumos.org/issues/4971
    https://www.illumos.org/issues/4972
    https://www.illumos.org/issues/4973
    https://www.illumos.org/issues/4974

Notes:
    This set of patches adds a set of tunable parameters for the "extreme
    rewind" mode of pool import which allows control over the implicit
    scrub performed during such an import.

Ported by: Tim Chase <tim@chase2k.com>
* Illumos 4976-4984 - metaslab improvements
  4976 zfs should only avoid writing to a failing non-redundant top-level vdev
  4978 ztest fails in get_metaslab_refcount()
  4979 extend free space histogram to device and pool
  4980 metaslabs should have a fragmentation metric
  4981 remove fragmented ops vector from block allocator
  4982 space_map object should proactively upgrade when feature is enabled
  4983 need to collect metaslab information via mdb
  4984 device selection should use fragmentation metric
  Reviewed by: Matthew Ahrens <mahrens@delphix.com>
  Reviewed by: Adam Leventhal <adam.leventhal@delphix.com>
  Reviewed by: Christopher Siden <christopher.siden@delphix.com>
  Approved by: Garrett D'Amore <garrett@damore.org>

  References:
      https://www.illumos.org/issues/4976
      https://www.illumos.org/issues/4978
      https://www.illumos.org/issues/4979
      https://www.illumos.org/issues/4980
      https://www.illumos.org/issues/4981
      https://www.illumos.org/issues/4982
      https://www.illumos.org/issues/4983
      https://www.illumos.org/issues/4984

  Notes:
      The "zdb -M" option has been re-tasked to display the new metaslab
      fragmentation metric and the new "zdb -I" option is used to control
      the maximum number of in-flight I/Os.

      The new fragmentation metric is derived from the space map histogram
      which has been rolled up to the vdev and pool level and is presented
      to the user via "zpool list".

      Add a number of module parameters related to the new metaslab weighting
      logic.

  Ported by: Tim Chase <tim@chase2k.com>

* Don't upgrade a metaslab when the pool is not writable
  Illumos 4982 added code to metaslab_fragmentation() to proactively update
  space maps when the spacemap_histogram feature is enabled.  This should
  only happen when the pool is writeable.

  References:
      https://www.illumos.org/issues/4982
illumos-gate commit bbfa8ea8bb4168c969ba27d632dfe0aeec3fc0da
Author: Matthew Ahrens <mahrens@delphix.com>
Date:   Thu Jul 17 09:27:13 2014 -0800

    4631 zvol_get_stats triggering too many reads
    Reviewed by: Adam Leventhal <ahl@delphix.com>
    Reviewed by: Sebastien Roy <sebastien.roy@delphix.com>
    Reviewed by: Matt Ahrens <mahrens@delphix.com>
    Approved by: Dan McDonald <danmcd@omniti.com>
zvol_create_minors(): check snapdev before traversing snapshots
ZFS_IOC_RECV should only call zvol_create_minors() on zvols

perf profiling revealed significant time spent in these functions on a
system without zvols during a recv. I know of one company that is
explicitly disabling this in their own builds because they found that it
wastes CPU time. This is the intermediate approach.

Signed-off-by: Richard Yao <ryao@gentoo.org>
My commits...