src, branch zfs-0.7.0-rc4 FreeBSD source tree Tag 0.7.0-rc4 2017-05-05T17:33:40+00:00 Brian Behlendorf behlendorf1@llnl.gov 2017-05-05T17:33:40+00:00 a0e84010c94570fd2b6c8b43da49f0cd3e1a8e09 Fourth release candidate. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> 
Fourth release candidate.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Fix unused variable warning 2017-05-05T17:23:58+00:00 Brian Behlendorf behlendorf1@llnl.gov 2017-05-05T17:17:32+00:00 1eab430af7828cc1f85a7c26ef37d5da88884977 Remove the lz4_ac local variable from dmu_write_policy() to resolve the following unused variable warning on non-debug builds. dmu.c: In function ‘dmu_write_policy’: dmu.c:1892:12: warning: unused variable ‘lz4_ac’ [-Wunused-variable] boolean_t lz4_ac = spa_feature_is_active(os->os_spa, Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> 
Remove the lz4_ac local variable from dmu_write_policy() to resolve
the following unused variable warning on non-debug builds.

dmu.c: In function ‘dmu_write_policy’:
dmu.c:1892:12: warning: unused variable ‘lz4_ac’ [-Wunused-variable]
  boolean_t lz4_ac = spa_feature_is_active(os->os_spa,

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Add missing *_destroy/*_fini calls 2017-05-04T23:26:28+00:00 Gvozden Neskovic neskovic@gmail.com 2016-11-26T20:30:44+00:00 c17486b2178fc545c50d48effd4be47d33208933 The proposed debugging enhancements in zfsonlinux/spl#587 identified the following missing *_destroy/*_fini calls. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Gvozden Neskovic <neskovic@gmail.com> Closes #5428 
The proposed debugging enhancements in zfsonlinux/spl#587
identified the following missing *_destroy/*_fini calls.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Gvozden Neskovic <neskovic@gmail.com>
Closes #5428
Default to zvol_request_async=0 2017-05-04T22:01:50+00:00 Brian Behlendorf behlendorf1@llnl.gov 2017-05-03T00:37:14+00:00 8fa5250f5d779e577406c581fc2d7fbf0baceea5 Change the default ZVOL behavior so requests are handled asynchronously. This behavior is functionally the same as in the zfs-0.6.4 release. Reviewed-by: Chunwei Chen <david.chen@osnexus.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #5902 
Change the default ZVOL behavior so requests are handled asynchronously.
This behavior is functionally the same as in the zfs-0.6.4 release.

Reviewed-by: Chunwei Chen <david.chen@osnexus.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #5902
Enable Linux read-ahead for a single page on ZVOLs 2017-05-04T22:00:27+00:00 Richard Yao ryao@gentoo.org 2014-07-11T18:35:58+00:00 bc17f1047a83cc8c4065e0ef84333a0d9b9d73aa Linux has read-ahead logic designed to accelerate sequential workloads. ZFS has its own read-ahead logic called zprefetch that operates on both ZVOLs and datasets. Having two prefetchers active at the same time can cause overprefetching, which unnecessarily reduces IOPS performance on CoW filesystems like ZFS. Testing shows that entirely disabling the Linux prefetch results in a significant performance penalty for reads while commensurate benefits are seen in random writes. It appears that read-ahead benefits are inversely proportional to random write benefits, and so a single page of Linux-layer read-ahead appears to offer the middle ground for both workloads. Reviewed-by: Chunwei Chen <david.chen@osnexus.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Richard Yao <ryao@gentoo.org> Issue #5902 
Linux has read-ahead logic designed to accelerate sequential workloads.
ZFS has its own read-ahead logic called zprefetch that operates on both
ZVOLs and datasets. Having two prefetchers active at the same time can
cause overprefetching, which unnecessarily reduces IOPS performance on
CoW filesystems like ZFS.

Testing shows that entirely disabling the Linux prefetch results in
a significant performance penalty for reads while commensurate benefits
are seen in random writes. It appears that read-ahead benefits are
inversely proportional to random write benefits, and so a single page
of Linux-layer read-ahead appears to offer the middle ground for both
workloads.

Reviewed-by: Chunwei Chen <david.chen@osnexus.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Richard Yao <ryao@gentoo.org>
Issue #5902
Disable write merging on ZVOLs 2017-05-04T21:59:52+00:00 RageLtMan rageltman [at] sempervictus 2017-03-18T04:51:36+00:00 5731140eaf4aaf2526a8bfdbfe250195842e79eb The current ZVOL implementation does not explicitly set merge options on ZVOL device queues, which results in the default merge behavior. Explicitly set QUEUE_FLAG_NOMERGES on ZVOL queues allowing the ZIO pipeline to do its work. Initial benchmarks (tiotest with no O_DIRECT) show random write performance going up almost 3X on 8K ZVOLs, even after significant rewrites of the logical space allocation. Reviewed-by: Richard Yao <ryao@gentoo.org> Reviewed-by: Chunwei Chen <david.chen@osnexus.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: RageLtMan <rageltman@sempervictus> Issue #5902 
The current ZVOL implementation does not explicitly set merge
options on ZVOL device queues, which results in the default merge
behavior.

Explicitly set QUEUE_FLAG_NOMERGES on ZVOL queues allowing the
ZIO pipeline to do its work.

Initial benchmarks (tiotest with no O_DIRECT) show random write
performance going up almost 3X on 8K ZVOLs, even after significant
rewrites of the logical space allocation.

Reviewed-by: Richard Yao <ryao@gentoo.org>
Reviewed-by: Chunwei Chen <david.chen@osnexus.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: RageLtMan <rageltman@sempervictus>
Issue #5902
Update rsend_014_pos and send-c_volume test cases 2017-05-04T21:32:43+00:00 Brian Behlendorf behlendorf1@llnl.gov 2017-05-04T21:32:43+00:00 4cb932d95140e358426cb7ca8505ee5e66939bcc The send-c_volume test case has been observed to occasionally fail on 32-bit systems. Until this issue is fully understood disable this test case. The rsend_014_pos test case can occasionally fail due to an EBUSY during export. This can lead to subsequent test failures. Resolve the issue by retrying the export on EBUSY. Additionally, remove the gratuitous use of eval. Reviewed-by: Giuseppe Di Natale <dinatale2@llnl.gov> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #6088 
The send-c_volume test case has been observed to occasionally
fail on 32-bit systems.  Until this issue is fully understood
disable this test case.

The rsend_014_pos test case can occasionally fail due to an
EBUSY during export.  This can lead to subsequent test failures.
Resolve the issue by retrying the export on EBUSY.  Additionally,
remove the gratuitous use of eval.

Reviewed-by: Giuseppe Di Natale <dinatale2@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #6088
Enable all zfs_destroy test cases 2017-05-04T01:27:59+00:00 Brian Behlendorf behlendorf1@llnl.gov 2017-05-04T01:27:59+00:00 35b7842f6821ecbf019e64204730cc0425ecc331 * zfs_destroy_001_pos - Unable to reproduce the failures locally. Re-enabled to determine observed buildbot failure rate. * zfs_destroy_005_neg - Updated for expected Linux behavior. Busy mount points, even snapshots, are expected to fail. * zfs_destroy_010_pos - Resolved transient EBUSY with retry. Reviewed-by: Giuseppe Di Natale <dinatale2@llnl.gov> Reviewed-by: George Melikov <mail@gmelikov.ru> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #5635 Issue #5893 Closes #6091 
* zfs_destroy_001_pos - Unable to reproduce the failures locally.
  Re-enabled to determine observed buildbot failure rate.

* zfs_destroy_005_neg - Updated for expected Linux behavior.
  Busy mount points, even snapshots, are expected to fail.

* zfs_destroy_010_pos - Resolved transient EBUSY with retry.

Reviewed-by: Giuseppe Di Natale <dinatale2@llnl.gov>
Reviewed-by: George Melikov <mail@gmelikov.ru>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #5635 
Issue #5893 
Closes #6091
More ashift improvements 2017-05-03T16:31:05+00:00 LOLi loli10K@users.noreply.github.com 2017-05-03T16:31:05+00:00 dddef7d600580ea35177299fe8394f665cc13387 This commit allow higher ashift values (up to 16) in 'zpool create' The ashift value was previously limited to 13 (8K block) in b41c990 because the limited number of uberblocks we could fit in the statically sized (128K) vdev label ring buffer could prevent the ability the safely roll back a pool to recover it. Since b02fe35 the largest uberblock size we support is 8K: this allow us to store a minimum number of 16 uberblocks in the vdev label, even with higher ashift values. Additionally change 'ashift' pool property behaviour: if set it will be used as the default hint value in subsequent vdev operations ('zpool add', 'attach' and 'replace'). A custom ashift value can still be specified from the command line, if desired. Finally, fix a bug in add-o_ashift.ksh caused by a missing variable. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: loli10K <ezomori.nozomu@gmail.com> Closes #2024 Closes #4205 Closes #4740 Closes #5763 
This commit allow higher ashift values (up to 16) in 'zpool create'

The ashift value was previously limited to 13 (8K block) in b41c990
because the limited number of uberblocks we could fit in the
statically sized (128K) vdev label ring buffer could prevent the
ability the safely roll back a pool to recover it.

Since b02fe35 the largest uberblock size we support is 8K: this
allow us to store a minimum number of 16 uberblocks in the vdev
label, even with higher ashift values.

Additionally change 'ashift' pool property behaviour: if set it will
be used as the default hint value in subsequent vdev operations
('zpool add', 'attach' and 'replace'). A custom ashift value can still
be specified from the command line, if desired.

Finally, fix a bug in add-o_ashift.ksh caused by a missing variable.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: loli10K <ezomori.nozomu@gmail.com>
Closes #2024 
Closes #4205 
Closes #4740 
Closes #5763
Write label 2,3 uberblocks when vdev expands 2017-05-02T20:55:24+00:00 Olaf Faaland faaland1@llnl.gov 2017-05-02T20:55:24+00:00 9d3f7b87919b7d0d869153ca72844f565cd0bf52 When vdev_psize increases, the location of labels 2 and 3 changes because their location is relative to the end of the device. The configs for labels 2 and 3 are written during the next spa_sync() because the vdev is added to the dirty config list. However, the uberblock rings are not re-written in their new location, leaving the device vulnerable to the beginning of the device being overwritten or damaged. This patch copies the uberblock ring from label 0 to labels 2 and 3, in their new locations, at the next sync after vdev_psize increases. Also, add a test zpool_expand_004_pos.ksh to confirm the uberblocks are copied. Reviewed-by: BearBabyLiu <liu.huang@zte.com.cn> Reviewed-by: Andreas Dilger <andreas.dilger@intel.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Olaf Faaland <faaland1@llnl.gov> Closes #5108 
When vdev_psize increases, the location of labels 2 and 3 changes
because their location is relative to the end of the device.

The configs for labels 2 and 3 are written during the next spa_sync()
because the vdev is added to the dirty config list.  However, the
uberblock rings are not re-written in their new location, leaving the
device vulnerable to the beginning of the device being overwritten or
damaged.

This patch copies the uberblock ring from label 0 to labels 2 and 3,
in their new locations, at the next sync after vdev_psize increases.

Also, add a test zpool_expand_004_pos.ksh to confirm the uberblocks
are copied.

Reviewed-by: BearBabyLiu <liu.huang@zte.com.cn>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Olaf Faaland <faaland1@llnl.gov>
Closes #5108