Revert "Fix __zio_execute() asynchronous dispatch"

This reverts commit 91579709fccd3e55a21970742b66c388fb1403db which
limited the asynchronous dispatch to kernel space.  We want to do
this for two reasons:

1) While we have slightly more headroom in user space excessively
   deep stacks have been observed while running ztest, see #2293.

2) Removing this conditional makes the pipeline behave consistently
   regardless of if it's executing in kernel space or user space.
   This way we're more likely to uncover subtle issues with ztest.

Signed-off-by: Richard Yao <ryao@gentoo.org>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #2384
Accept udev and dracut paths specified by ./configure

There are two common locations where udev and dracut components are
commonly installed.  When building packages using the 'make rpm|deb'
targets check those common locations and pass them to rpmbuild.  For
non-standard configurations these values can be provided by the
the following configure options:

  --with-udevdir=DIR      install udev helpers [default=check]
  --with-udevruledir=DIR  install udev rules [[UDEVDIR/rules.d]]
  --with-dracutdir=DIR    install dracut helpers [default=check]

When rebuilding using the source packages the per-distribution
default values specified in the spec file will be used.  This is
the preferred way to build packages for a distribution but the
ability to override the defaults is provided as a convenience.

Signed-off-by: Turbo Fredriksson <turbo@bayour.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #2310
Closes #1680
Fix zfs.spec.in defaults

Commit 2ee4e7da accidentally introduced two issues which only occur
when rebuilding the ZFS source rpm outside the ZFS build system.

1) The _dracutdir, _udevdir, and _udevruledir macros must be checked
   using the 'undefined' keyword.  This was just overlooked in the
   patch review and does not cause a failure when using 'make pkg'
   because the values are provided by the make target.

2) The default _udevruledir path included a typo.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #2310
Tag zfs-0.6.3

META file and release log updated.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Illumos #3641 compressed block histograms with zdb

This patch is a zdb extension of the '-b' option, producing a histogram
of the physical compressed block sizes per DMU object type on disk. The
'-bbbb' option to zdb will uncover this new feature; here's an example
usage on a new pool and snippet of the output it generates:

    # zpool create tank /dev/vd{b,c,d}
    # dd bs=1k  if=/dev/urandom of=/tank/1kfile  count=1
    # dd bs=3k  if=/dev/urandom of=/tank/3kfile  count=1
    # dd bs=64k if=/dev/urandom of=/tank/64kfile count=1
    # zdb -bbbb tank
    ...
         3  68.0K   68.0K   68.0K   22.7K    1.00    34.26  ZFS plain file
    psize (in 512-byte sectors): number of blocks
                              2:      1 *
                              3:      0
                              4:      0
                              5:      0
                              6:      1 *
                              7:      0
    ...
                            127:      0
                            128:      1 *
    ...

The blocks are also broken down by their indirection level. Expanding on
the above example:

    # zfs set recordsize=1k tank
    # dd bs=1k if=/dev/urandom of=/tank/2x1kfile count=2
    # zdb -bbbb tank
    ...
         1    16K      1K      2K      2K   16.00     1.02      L1 ZFS plain file
    psize (in 512-byte sectors): number of blocks
                              2:      1 *
         5  70.0K   70.0K   70.0K   14.0K    1.00    35.71      L0 ZFS plain file
    psize (in 512-byte sectors): number of blocks
                              2:      3 ***
                              3:      0
                              4:      0
                              5:      0
                              6:      1 *
                              7:      0
    ...
                            127:      0
                            128:      1 *
         6  86.0K   71.0K   72.0K   12.0K    1.21    36.73  ZFS plain file
    psize (in 512-byte sectors): number of blocks
                              2:      4 ****
                              3:      0
                              4:      0
                              5:      0
                              6:      1 *
                              7:      0
    ...
                            127:      0
                            128:      1 *
    ...

There's now a single 1K L1 block which is the indirect block needed for
the '2x1kfile' file just created, as well as two more 1K L0 blocks from
the same file.

This can be used to get a distribution of the block sizes used within
the pool, on a per object type basis.

References:
  https://illumos.org/issues/3641
  https://github.com/illumos/illumos-gate/commit/490d05b

Ported by: Tim Chase <tim@chase2k.com>
Signed-off-by: Prakash Surya <surya1@llnl.gov>