=> 2689: turbo/illumos-3693 - restore_object uses at least two transactions to restore an object

restore_object uses at least two transactions to restore an object:

  * one transaction is used for dmu_object_claim
  * another transaction is used to set compression, checksum and most
    importantly bonus data
  * furthermore dmu_object_reclaim internally uses multiple transactions
  * dmu_free_long_range frees chunks in separate transactions
  * dnode_reallocate is executed in a distinct transaction

The fact the dnode_allocate/dnode_reallocate are executed in one
transaction and bonus (re-)population is executed in a different
transaction may lead to violation of ZFS consistency assertions if the
transactions are assigned to different transaction groups.  Also, if
the first transaction group is successfully written to a permanent
storage, but the second transaction is lost, then an invalid dnode may
be created on the stable storage.

Reviewed by: Christopher Siden christopher.siden@delphix.com
Reviewed by: George Wilson george.wilson@delphix.com

Original authors: Matthew Ahrens and Andriy Gapon

References:
  https://www.illumos.org/projects/illumos-gate//issues/3693
  https://reviews.csiden.org/r/90

Ported by: Turbo Fredriksson <turbo@bayour.com>
=> 2669: turbo/illumos-5134 - if ZFS_DEBUG or debug= is set, libzpool should enable debug prints

Reviewed by: Christopher Siden christopher.siden@delphix.com
Reviewed by: Adam Leventhal adam.leventhal@delphix.com

References:
  https://www.illumos.org/projects/illumos-gate/issues/5134
  https://github.com/illumos/illumos-gate/commit/7fa49ea

Porting notes:
  Run dprintf_setup() in main.

Ported by: Turbo Fredriksson <turbo@bayour.com>
=> 2690: turbo/illumos-5150 - zfs clone of a defer_destroy snapshot causes strangeness

When a clone is created of a snapshot that has been marked for
deferred destroy (with "zfs destroy -d"), the clone "inherits" the
defer_destroy flag from the origin, and any snapshots of the clone
"inherit" the defer_destroy flag from the clone. This causes a strange
situation where the clone's snapshots are marked for defer_destroy but
they have no holds or clones. If the clone's snapshot gets a hold or
clone, which is then deleted, we will honor the incorrectly-set
defer_destroy flag and delete the snapshot!

Steps to reproduce:

  * zpool create test c1t1d0
  * zfs create test/fs
  * zfs snapshot test/fs@a
  * zfs clone test/fs@a test/clone
  * zfs destroy -d test/fs@a
  * zfs clone test/fs@a test/clone2
  * zfs snapshot test/clone2@a
  * zfs hold hld test/clone2@a
  * zfs release hld test/clone2@a
  * zfs list -r -t all test

  <test/clone2@a has been destroyed>

We noticed that this causes dcenter to get very confused, because it
treats snapshots that are marked defer_destroy as not existing. So it
won't see any snapshots of the clone that's marked defer_destroy.

Reviewed by: George Wilson george.wilson@delphix.com
Reviewed by: Christopher Siden christopher.siden@delphix.com
Reviewed by: Max Grossman max.grossman@delphix.com

Original author: Matthew Ahrens

References:
  https://www.illumos.org/projects/illumos-gate//issues/5150
  https://reviews.csiden.org/r/93/

Ported by: Turbo Fredriksson <turbo@bayour.com>
=> 2697: turbo/illumos-5164+5165 - zdb trips assert on pools with ashift >= 0xe

Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Max Grossman <max.grossman@delphix.com>
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Approved by: Garrett D'Amore <garrett@damore.org>

References:
  https://www.illumos.org/issues/4958
  https://github.com/illumos/illumos-gate/commit/2a104a5

Porting notes:

Keep the ZIO_FLAG_FASTWRITE define, because that is used in
Linux but not in *BSD.

Ported by: Turbo Fredriksson <turbo@bayour.com>

Illumos 5164+5165 - space_map fixes

5164 space_map_max_blksz causes panic, does not work
5165 zdb fails assertion when run on pool with recently-enabled spacemap_histogram feature
Reviewed by: George Wilson george.wilson@delphix.com
Reviewed by: Christopher Siden christopher.siden@delphix.com

References:
  https://www.illumos.org/issues/5164
  https://www.illumos.org/issues/5165
  https://github.com/illumos/illumos-gate/commit/b1be289

Ported by: Turbo Fredriksson <turbo@bayour.com>
=> 2707: turbo/illumos-5169-5171 - zdb fixes

5169 zdb should limit its ARC size
5170 zdb -c should create more scrub i/os by default
5171 zdb should print status while loading metaslabs for leak detection
Reviewed by: George Wilson george.wilson@delphix.com\
Reviewed by: Paul Dagnelie paul.dagnelie@delphix.com\
Reviewed by: Christopher Siden christopher.siden@delphix.com\

References:
  https://www.illumos.org/issues/5169
  https://www.illumos.org/issues/5170
  https://www.illumos.org/issues/5171
  https://reviews.csiden.org/r/100/

Ported by: Turbo Fredriksson <turbo@bayour.com>
=> 2711: turbo/illumos-5176 - lock contention on godfather zio

5176 lock contention on godfather zio
Reviewed by: Alex Reece alex.reece@delphix.com
Reviewed by: George Wilson george.wilson@delphix.com
Reviewed by: Christopher Siden christopher.siden@delphix.com
Reviewed by: Adam Leventhal ahl@delphix.com

References:
  https://www.illumos.org/issues/5176
  https://reviews.csiden.org/r/103/

Ported by: Turbo Fredriksson <turbo@bayour.com>
=> 2713: turbo/illumos-5178 - zdb -vvvvv on old-format pool fails in dump_deadlist()

5178 zdb -vvvvv on old-format pool fails in dump_deadlist()
Reviewed by: Christopher Siden christopher.siden@delphix.com
Reviewed by: George Wilson george.wilson@delphix.com

References:
  https://www.illumos.org/issues/5178
  https://reviews.csiden.org/r/105/

Ported by: Turbo Fredriksson <turbo@bayour.com>
=> 2751: turbo/man.bookmarks - Add an example for 'zfs bookmark' to the Example section.
=> 2754: turbo/man.dedup - Add a stern warning about dedup requiring lots and lots of memory.
=> 2678: behlendorf/issue-2678 - Handle block pointers with a corrupt logical size

The general strategy used by ZFS to verify that blocks are is to
checksum everything.  This has the advantage of being extremely
robust and generically applicable regardless of the contents of
the block.  If a blocks checksum is valid then its contents are
trusted by the higher layers.

This system works exceptionally well as long bad data is never
written with a valid checksum.  However, if this does somehow
occur due to a software bug or a memory bit-flip on a non-ECC
system it may result in kernel panic.

One such place where this could occur is if somehow the logical
size stored in a block pointer exceeds the maximum block size.
This will result in an attempt to allocate a buffer greater than
the maximum block size causing a system panic.

To prevent this from happening the arc_read() function has been
updated to detect this specific case.  If a block pointer with an
invalid logical size is passed it will treat the block as if it
contained a checksum error.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #2678
=> 1350: behlendorf/issue-1350 - Adds support for property overrides

Adds support for property overrides (-o property=value), property
excludes (-x property) and dataset limits (-l <volume|filesystem>)
to zfs receive.

Both -o and -x options mirror the functionality already available
in Oracle's ZFS implementation which is also mentioned in the
upstream feature request #2745:

The -l option allows receive to be limited to specific datasets within
the stream effectively allowing partial restores from a multi dataset
stream.

References:
  https://www.illumos.org/issues/2745

Ported-by: Milan-Benes
Issue #1350

NOTES: Man page updates missing and must be added, see patch:
http://blog.multiplay.co.uk/dropzone/freebsd/zfs-recv-properties.patch
=> 2479: bprotopopov/zvol-scale - zvol_create_minors(): check snapdev before traversing snapshots
=> 2484: ryao/zvol - zvol rework

* 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 conitext 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. In addition, commercial ZFSOnLinux
  distributions report that regular files are more performant than zvols.
  That stronlgy 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>
=> 2387: ryao/timeout - Introduce module parameters for handling IO timeouts

The low level formatting of magnetic drives contains ECC that permits
error correction. When a drive reads a bad sector, it will keep trying
to read it is reached in the hope that a different read attempt will
allow the ECC to reconstruct the bad data until an internal time out
occurs. This is useful on filesystems that cannot recover from drive
errors. However, it is unnecessary as ZFS can easily self heal when
errors occur.

We introduce a tunable called zfs_vdev_disk_timeout_ms that allows us to
tell the block layer to send the errors to ZFS earlier than normal. We
also introduce zfs_vdev_disk_timeout_ticks, which is the maximum number
of consecutive timeouts before a disk is marked as being bad.

Signed-off-by: Richard Yao <ryao@gentoo.org>
=> 2129: tuxoko/abd - Move ARC data buffers out of vmalloc
* Add compatibility layer for {kmap,kunmap}_atomic
  Starting from linux-2.6.37, {kmap,kunmap}_atomic takes 1 argument instead of 2.
  Signed-off-by: Chunwei Chen <tuxoko@gmail.com>

* Introduce ABD: linear/scatter dual typed buffer for ARC
  zfsolinux currently uses vmalloc backed slab for ARC buffers. There are some
  major problems with this approach. One is that 32-bit system have only a
  handful of vmalloc space. Another is that the fragmentation in slab will easily
  trigger OOM in busy system.

  With ABD, we use scatterlist to allocate data buffers. In this approach we can
  allocate in HIGHMEM, which alleviates vmalloc space pressure on 32-bit. Also,
  we don't have to rely on slab, so there's no fragmentation issue.

  But for metadata buffers, we still uses linear buffer from slab. The reason for
  this is that there are a lot of *_phys pointers directly point to metadata
  buffers. So it's kind of impractical to change all those code. And metadata
  should only be a small percentage so we probably don't have to worry about
  the 32-bit and fragmentation issue, right?

  Currently, ABD is not enabled and its API will treat them as normal buffers.
  We will enable it once all relevant code is modified to use the API.
  Signed-off-by: Chunwei Chen <tuxoko@gmail.com>

* Modify/Add incremental checksum function for abd_iterate_rfunc
  Modify/Add incremental fletcher function prototype to match abd_iterate_rfunc
  callback type. Also, reduce duplicated code a bit in zfs_fletcher.c.
  Signed-off-by: Chunwei Chen <tuxoko@gmail.com>

* Use abd_t in arc.h, dmu.h and zio.h
  1. Use abd_t in arc_buf_t->b_data, dmu_buf_t->db_data, zio_t->io_data and
  zio_transform_t->zt_orig_data
  2. zio_* function take abd_t for data
  Signed-off-by: Chunwei Chen <tuxoko@gmail.com>

* Convert zio_checksum to ABD version
  1. Add checksum function for abd_t
  2. Use abd_t version checksum function in zio_checksum_table
  3. Make zio_checksum_compute and zio_checksum_error handle abd_t
  Signed-off-by: Chunwei Chen <tuxoko@gmail.com>

* Handle abd_t in arc.c, bpobj.c and bptree.c
  Signed-off-by: Chunwei Chen <tuxoko@gmail.com>

* Handle abd_t in dbuf.c, ddt.c, dmu*.c
  Signed-off-by: Chunwei Chen <tuxoko@gmail.com>

* Handle abd_t in dnode*.c, dsl_*.c
  Signed-off-by: Chunwei Chen <tuxoko@gmail.com>

* Handle abd_t in sa_impl.h, sa.c, space_map.c, spa.c, spa_history.c and zil.c
  Signed-off-by: Chunwei Chen <tuxoko@gmail.com>

* Handle abd_t in metaslab.c, zap*.c, zfs_fuid.c, zfs_sa.c and zfs_vnops.c
  Signed-off-by: Chunwei Chen <tuxoko@gmail.com>

* Handle abd_t in zio.c
  Signed-off-by: Chunwei Chen <tuxoko@gmail.com>

* Handle abd_t in vdev*.c sans vdev_raidz.c
  Signed-off-by: Chunwei Chen <tuxoko@gmail.com>

* Handle abd_t in vdev_raidz.c
  Signed-off-by: Chunwei Chen <tuxoko@gmail.com>

* Handle ABD in ztest and zdb
  Use ABD API on related pointers and functions.(b_data, db_data, zio_*(), etc.)
  Note that the userspace still only support linear ABD.

  Suggested-by: DHE <git@dehacked.net>
  Signed-off-by: Chunwei Chen <tuxoko@gmail.com>

* Enable ABD
  Signed-off-by: Chunwei Chen <tuxoko@gmail.com>
My commits...