2013-11-16 06:52:54 +00:00
|
|
|
'\" te
|
|
|
|
.\" Copyright (c) 2013 by Turbo Fredriksson <turbo@bayour.com>. All rights reserved.
|
|
|
|
.\" The contents of this file are subject to the terms of the Common Development
|
|
|
|
.\" and Distribution License (the "License"). You may not use this file except
|
|
|
|
.\" in compliance with the License. You can obtain a copy of the license at
|
|
|
|
.\" usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.
|
|
|
|
.\"
|
|
|
|
.\" See the License for the specific language governing permissions and
|
|
|
|
.\" limitations under the License. When distributing Covered Code, include this
|
|
|
|
.\" CDDL HEADER in each file and include the License file at
|
|
|
|
.\" usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this
|
|
|
|
.\" CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your
|
|
|
|
.\" own identifying information:
|
|
|
|
.\" Portions Copyright [yyyy] [name of copyright owner]
|
|
|
|
.TH ZFS-MODULE-PARAMETERS 5 "Nov 16, 2013"
|
|
|
|
.SH NAME
|
|
|
|
zfs\-module\-parameters \- ZFS module parameters
|
|
|
|
.SH DESCRIPTION
|
|
|
|
.sp
|
|
|
|
.LP
|
|
|
|
Description of the different parameters to the ZFS module.
|
|
|
|
|
|
|
|
.SS "Module parameters"
|
|
|
|
.sp
|
|
|
|
.LP
|
|
|
|
|
2016-07-08 20:51:50 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBignore_hole_birth\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
When set, the hole_birth optimization will not be used, and all holes will
|
|
|
|
always be sent on zfs send. Useful if you suspect your datasets are affected
|
|
|
|
by a bug in hole_birth.
|
|
|
|
.sp
|
|
|
|
Use \fB1\fR for on and \fB0\fR (default) for off.
|
|
|
|
.RE
|
|
|
|
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBl2arc_feed_again\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Turbo L2ARC warm-up. When the L2ARC is cold the fill interval will be set as
|
|
|
|
fast as possible.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes (default) and \fB0\fR to disable.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBl2arc_feed_min_ms\fR (ulong)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Min feed interval in milliseconds. Requires \fBl2arc_feed_again=1\fR and only
|
|
|
|
applicable in related situations.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB200\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBl2arc_feed_secs\fR (ulong)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Seconds between L2ARC writing
|
|
|
|
.sp
|
|
|
|
Default value: \fB1\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBl2arc_headroom\fR (ulong)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
How far through the ARC lists to search for L2ARC cacheable content, expressed
|
|
|
|
as a multiplier of \fBl2arc_write_max\fR
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB2\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBl2arc_headroom_boost\fR (ulong)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Scales \fBl2arc_headroom\fR by this percentage when L2ARC contents are being
|
|
|
|
successfully compressed before writing. A value of 100 disables this feature.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB200\fR.
|
|
|
|
.RE
|
|
|
|
|
2016-02-10 18:42:01 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBl2arc_max_block_size\fR (ulong)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
The maximum block size which may be written to an L2ARC device, after
|
|
|
|
compression and other factors. This setting is used to prevent a small
|
|
|
|
number of large blocks from pushing a larger number of small blocks out
|
|
|
|
of the cache.
|
|
|
|
.sp
|
|
|
|
Default value: \fB16,777,216\fR.
|
|
|
|
.RE
|
|
|
|
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBl2arc_nocompress\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Skip compressing L2ARC buffers
|
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes and \fB0\fR for no (default).
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBl2arc_noprefetch\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Do not write buffers to L2ARC if they were prefetched but not used by
|
|
|
|
applications
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes (default) and \fB0\fR to disable.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBl2arc_norw\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
No reads during writes
|
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes and \fB0\fR for no (default).
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBl2arc_write_boost\fR (ulong)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Cold L2ARC devices will have \fBl2arc_write_nax\fR increased by this amount
|
|
|
|
while they remain cold.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB8,388,608\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBl2arc_write_max\fR (ulong)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Max write bytes per interval
|
|
|
|
.sp
|
|
|
|
Default value: \fB8,388,608\fR.
|
|
|
|
.RE
|
|
|
|
|
2015-05-10 15:40:20 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBmetaslab_aliquot\fR (ulong)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Metaslab granularity, in bytes. This is roughly similar to what would be
|
|
|
|
referred to as the "stripe size" in traditional RAID arrays. In normal
|
|
|
|
operation, ZFS will try to write this amount of data to a top-level vdev
|
|
|
|
before moving on to the next one.
|
|
|
|
.sp
|
|
|
|
Default value: \fB524,288\fR.
|
|
|
|
.RE
|
|
|
|
|
2014-07-19 20:19:24 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBmetaslab_bias_enabled\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Enable metaslab group biasing based on its vdev's over- or under-utilization
|
|
|
|
relative to the pool.
|
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes (default) and \fB0\fR for no.
|
|
|
|
.RE
|
|
|
|
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
2014-04-01 00:22:55 +00:00
|
|
|
\fBmetaslab_debug_load\fR (int)
|
2013-11-16 06:52:54 +00:00
|
|
|
.ad
|
|
|
|
.RS 12n
|
2014-04-01 00:22:55 +00:00
|
|
|
Load all metaslabs during pool import.
|
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes and \fB0\fR for no (default).
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBmetaslab_debug_unload\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Prevent metaslabs from being unloaded.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes and \fB0\fR for no (default).
|
|
|
|
.RE
|
|
|
|
|
2014-07-19 20:19:24 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBmetaslab_fragmentation_factor_enabled\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Enable use of the fragmentation metric in computing metaslab weights.
|
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes (default) and \fB0\fR for no.
|
|
|
|
.RE
|
|
|
|
|
2014-09-13 14:13:00 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBmetaslabs_per_vdev\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
When a vdev is added, it will be divided into approximately (but no more than) this number of metaslabs.
|
|
|
|
.sp
|
|
|
|
Default value: \fB200\fR.
|
|
|
|
.RE
|
|
|
|
|
2014-07-19 20:19:24 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBmetaslab_preload_enabled\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Enable metaslab group preloading.
|
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes (default) and \fB0\fR for no.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBmetaslab_lba_weighting_enabled\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Give more weight to metaslabs with lower LBAs, assuming they have
|
|
|
|
greater bandwidth as is typically the case on a modern constant
|
|
|
|
angular velocity disk drive.
|
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes (default) and \fB0\fR for no.
|
|
|
|
.RE
|
|
|
|
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBspa_config_path\fR (charp)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
SPA config file
|
|
|
|
.sp
|
|
|
|
Default value: \fB/etc/zfs/zpool.cache\fR.
|
|
|
|
.RE
|
|
|
|
|
Illumos #4045 write throttle & i/o scheduler performance work
4045 zfs write throttle & i/o scheduler performance work
1. The ZFS i/o scheduler (vdev_queue.c) now divides i/os into 5 classes: sync
read, sync write, async read, async write, and scrub/resilver. The scheduler
issues a number of concurrent i/os from each class to the device. Once a class
has been selected, an i/o is selected from this class using either an elevator
algorithem (async, scrub classes) or FIFO (sync classes). The number of
concurrent async write i/os is tuned dynamically based on i/o load, to achieve
good sync i/o latency when there is not a high load of writes, and good write
throughput when there is. See the block comment in vdev_queue.c (reproduced
below) for more details.
2. The write throttle (dsl_pool_tempreserve_space() and
txg_constrain_throughput()) is rewritten to produce much more consistent delays
when under constant load. The new write throttle is based on the amount of
dirty data, rather than guesses about future performance of the system. When
there is a lot of dirty data, each transaction (e.g. write() syscall) will be
delayed by the same small amount. This eliminates the "brick wall of wait"
that the old write throttle could hit, causing all transactions to wait several
seconds until the next txg opens. One of the keys to the new write throttle is
decrementing the amount of dirty data as i/o completes, rather than at the end
of spa_sync(). Note that the write throttle is only applied once the i/o
scheduler is issuing the maximum number of outstanding async writes. See the
block comments in dsl_pool.c and above dmu_tx_delay() (reproduced below) for
more details.
This diff has several other effects, including:
* the commonly-tuned global variable zfs_vdev_max_pending has been removed;
use per-class zfs_vdev_*_max_active values or zfs_vdev_max_active instead.
* the size of each txg (meaning the amount of dirty data written, and thus the
time it takes to write out) is now controlled differently. There is no longer
an explicit time goal; the primary determinant is amount of dirty data.
Systems that are under light or medium load will now often see that a txg is
always syncing, but the impact to performance (e.g. read latency) is minimal.
Tune zfs_dirty_data_max and zfs_dirty_data_sync to control this.
* zio_taskq_batch_pct = 75 -- Only use 75% of all CPUs for compression,
checksum, etc. This improves latency by not allowing these CPU-intensive tasks
to consume all CPU (on machines with at least 4 CPU's; the percentage is
rounded up).
--matt
APPENDIX: problems with the current i/o scheduler
The current ZFS i/o scheduler (vdev_queue.c) is deadline based. The problem
with this is that if there are always i/os pending, then certain classes of
i/os can see very long delays.
For example, if there are always synchronous reads outstanding, then no async
writes will be serviced until they become "past due". One symptom of this
situation is that each pass of the txg sync takes at least several seconds
(typically 3 seconds).
If many i/os become "past due" (their deadline is in the past), then we must
service all of these overdue i/os before any new i/os. This happens when we
enqueue a batch of async writes for the txg sync, with deadlines 2.5 seconds in
the future. If we can't complete all the i/os in 2.5 seconds (e.g. because
there were always reads pending), then these i/os will become past due. Now we
must service all the "async" writes (which could be hundreds of megabytes)
before we service any reads, introducing considerable latency to synchronous
i/os (reads or ZIL writes).
Notes on porting to ZFS on Linux:
- zio_t gained new members io_physdone and io_phys_children. Because
object caches in the Linux port call the constructor only once at
allocation time, objects may contain residual data when retrieved
from the cache. Therefore zio_create() was updated to zero out the two
new fields.
- vdev_mirror_pending() relied on the depth of the per-vdev pending queue
(vq->vq_pending_tree) to select the least-busy leaf vdev to read from.
This tree has been replaced by vq->vq_active_tree which is now used
for the same purpose.
- vdev_queue_init() used the value of zfs_vdev_max_pending to determine
the number of vdev I/O buffers to pre-allocate. That global no longer
exists, so we instead use the sum of the *_max_active values for each of
the five I/O classes described above.
- The Illumos implementation of dmu_tx_delay() delays a transaction by
sleeping in condition variable embedded in the thread
(curthread->t_delay_cv). We do not have an equivalent CV to use in
Linux, so this change replaced the delay logic with a wrapper called
zfs_sleep_until(). This wrapper could be adopted upstream and in other
downstream ports to abstract away operating system-specific delay logic.
- These tunables are added as module parameters, and descriptions added
to the zfs-module-parameters.5 man page.
spa_asize_inflation
zfs_deadman_synctime_ms
zfs_vdev_max_active
zfs_vdev_async_write_active_min_dirty_percent
zfs_vdev_async_write_active_max_dirty_percent
zfs_vdev_async_read_max_active
zfs_vdev_async_read_min_active
zfs_vdev_async_write_max_active
zfs_vdev_async_write_min_active
zfs_vdev_scrub_max_active
zfs_vdev_scrub_min_active
zfs_vdev_sync_read_max_active
zfs_vdev_sync_read_min_active
zfs_vdev_sync_write_max_active
zfs_vdev_sync_write_min_active
zfs_dirty_data_max_percent
zfs_delay_min_dirty_percent
zfs_dirty_data_max_max_percent
zfs_dirty_data_max
zfs_dirty_data_max_max
zfs_dirty_data_sync
zfs_delay_scale
The latter four have type unsigned long, whereas they are uint64_t in
Illumos. This accommodates Linux's module_param() supported types, but
means they may overflow on 32-bit architectures.
The values zfs_dirty_data_max and zfs_dirty_data_max_max are the most
likely to overflow on 32-bit systems, since they express physical RAM
sizes in bytes. In fact, Illumos initializes zfs_dirty_data_max_max to
2^32 which does overflow. To resolve that, this port instead initializes
it in arc_init() to 25% of physical RAM, and adds the tunable
zfs_dirty_data_max_max_percent to override that percentage. While this
solution doesn't completely avoid the overflow issue, it should be a
reasonable default for most systems, and the minority of affected
systems can work around the issue by overriding the defaults.
- Fixed reversed logic in comment above zfs_delay_scale declaration.
- Clarified comments in vdev_queue.c regarding when per-queue minimums take
effect.
- Replaced dmu_tx_write_limit in the dmu_tx kstat file
with dmu_tx_dirty_delay and dmu_tx_dirty_over_max. The first counts
how many times a transaction has been delayed because the pool dirty
data has exceeded zfs_delay_min_dirty_percent. The latter counts how
many times the pool dirty data has exceeded zfs_dirty_data_max (which
we expect to never happen).
- The original patch would have regressed the bug fixed in
zfsonlinux/zfs@c418410, which prevented users from setting the
zfs_vdev_aggregation_limit tuning larger than SPA_MAXBLOCKSIZE.
A similar fix is added to vdev_queue_aggregate().
- In vdev_queue_io_to_issue(), dynamically allocate 'zio_t search' on the
heap instead of the stack. In Linux we can't afford such large
structures on the stack.
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Reviewed by: Ned Bass <bass6@llnl.gov>
Reviewed by: Brendan Gregg <brendan.gregg@joyent.com>
Approved by: Robert Mustacchi <rm@joyent.com>
References:
http://www.illumos.org/issues/4045
illumos/illumos-gate@69962b5647e4a8b9b14998733b765925381b727e
Ported-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1913
2013-08-29 03:01:20 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBspa_asize_inflation\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Multiplication factor used to estimate actual disk consumption from the
|
|
|
|
size of data being written. The default value is a worst case estimate,
|
|
|
|
but lower values may be valid for a given pool depending on its
|
|
|
|
configuration. Pool administrators who understand the factors involved
|
|
|
|
may wish to specify a more realistic inflation factor, particularly if
|
|
|
|
they operate close to quota or capacity limits.
|
|
|
|
.sp
|
2015-12-30 17:44:46 +00:00
|
|
|
Default value: \fB24\fR.
|
Illumos #4045 write throttle & i/o scheduler performance work
4045 zfs write throttle & i/o scheduler performance work
1. The ZFS i/o scheduler (vdev_queue.c) now divides i/os into 5 classes: sync
read, sync write, async read, async write, and scrub/resilver. The scheduler
issues a number of concurrent i/os from each class to the device. Once a class
has been selected, an i/o is selected from this class using either an elevator
algorithem (async, scrub classes) or FIFO (sync classes). The number of
concurrent async write i/os is tuned dynamically based on i/o load, to achieve
good sync i/o latency when there is not a high load of writes, and good write
throughput when there is. See the block comment in vdev_queue.c (reproduced
below) for more details.
2. The write throttle (dsl_pool_tempreserve_space() and
txg_constrain_throughput()) is rewritten to produce much more consistent delays
when under constant load. The new write throttle is based on the amount of
dirty data, rather than guesses about future performance of the system. When
there is a lot of dirty data, each transaction (e.g. write() syscall) will be
delayed by the same small amount. This eliminates the "brick wall of wait"
that the old write throttle could hit, causing all transactions to wait several
seconds until the next txg opens. One of the keys to the new write throttle is
decrementing the amount of dirty data as i/o completes, rather than at the end
of spa_sync(). Note that the write throttle is only applied once the i/o
scheduler is issuing the maximum number of outstanding async writes. See the
block comments in dsl_pool.c and above dmu_tx_delay() (reproduced below) for
more details.
This diff has several other effects, including:
* the commonly-tuned global variable zfs_vdev_max_pending has been removed;
use per-class zfs_vdev_*_max_active values or zfs_vdev_max_active instead.
* the size of each txg (meaning the amount of dirty data written, and thus the
time it takes to write out) is now controlled differently. There is no longer
an explicit time goal; the primary determinant is amount of dirty data.
Systems that are under light or medium load will now often see that a txg is
always syncing, but the impact to performance (e.g. read latency) is minimal.
Tune zfs_dirty_data_max and zfs_dirty_data_sync to control this.
* zio_taskq_batch_pct = 75 -- Only use 75% of all CPUs for compression,
checksum, etc. This improves latency by not allowing these CPU-intensive tasks
to consume all CPU (on machines with at least 4 CPU's; the percentage is
rounded up).
--matt
APPENDIX: problems with the current i/o scheduler
The current ZFS i/o scheduler (vdev_queue.c) is deadline based. The problem
with this is that if there are always i/os pending, then certain classes of
i/os can see very long delays.
For example, if there are always synchronous reads outstanding, then no async
writes will be serviced until they become "past due". One symptom of this
situation is that each pass of the txg sync takes at least several seconds
(typically 3 seconds).
If many i/os become "past due" (their deadline is in the past), then we must
service all of these overdue i/os before any new i/os. This happens when we
enqueue a batch of async writes for the txg sync, with deadlines 2.5 seconds in
the future. If we can't complete all the i/os in 2.5 seconds (e.g. because
there were always reads pending), then these i/os will become past due. Now we
must service all the "async" writes (which could be hundreds of megabytes)
before we service any reads, introducing considerable latency to synchronous
i/os (reads or ZIL writes).
Notes on porting to ZFS on Linux:
- zio_t gained new members io_physdone and io_phys_children. Because
object caches in the Linux port call the constructor only once at
allocation time, objects may contain residual data when retrieved
from the cache. Therefore zio_create() was updated to zero out the two
new fields.
- vdev_mirror_pending() relied on the depth of the per-vdev pending queue
(vq->vq_pending_tree) to select the least-busy leaf vdev to read from.
This tree has been replaced by vq->vq_active_tree which is now used
for the same purpose.
- vdev_queue_init() used the value of zfs_vdev_max_pending to determine
the number of vdev I/O buffers to pre-allocate. That global no longer
exists, so we instead use the sum of the *_max_active values for each of
the five I/O classes described above.
- The Illumos implementation of dmu_tx_delay() delays a transaction by
sleeping in condition variable embedded in the thread
(curthread->t_delay_cv). We do not have an equivalent CV to use in
Linux, so this change replaced the delay logic with a wrapper called
zfs_sleep_until(). This wrapper could be adopted upstream and in other
downstream ports to abstract away operating system-specific delay logic.
- These tunables are added as module parameters, and descriptions added
to the zfs-module-parameters.5 man page.
spa_asize_inflation
zfs_deadman_synctime_ms
zfs_vdev_max_active
zfs_vdev_async_write_active_min_dirty_percent
zfs_vdev_async_write_active_max_dirty_percent
zfs_vdev_async_read_max_active
zfs_vdev_async_read_min_active
zfs_vdev_async_write_max_active
zfs_vdev_async_write_min_active
zfs_vdev_scrub_max_active
zfs_vdev_scrub_min_active
zfs_vdev_sync_read_max_active
zfs_vdev_sync_read_min_active
zfs_vdev_sync_write_max_active
zfs_vdev_sync_write_min_active
zfs_dirty_data_max_percent
zfs_delay_min_dirty_percent
zfs_dirty_data_max_max_percent
zfs_dirty_data_max
zfs_dirty_data_max_max
zfs_dirty_data_sync
zfs_delay_scale
The latter four have type unsigned long, whereas they are uint64_t in
Illumos. This accommodates Linux's module_param() supported types, but
means they may overflow on 32-bit architectures.
The values zfs_dirty_data_max and zfs_dirty_data_max_max are the most
likely to overflow on 32-bit systems, since they express physical RAM
sizes in bytes. In fact, Illumos initializes zfs_dirty_data_max_max to
2^32 which does overflow. To resolve that, this port instead initializes
it in arc_init() to 25% of physical RAM, and adds the tunable
zfs_dirty_data_max_max_percent to override that percentage. While this
solution doesn't completely avoid the overflow issue, it should be a
reasonable default for most systems, and the minority of affected
systems can work around the issue by overriding the defaults.
- Fixed reversed logic in comment above zfs_delay_scale declaration.
- Clarified comments in vdev_queue.c regarding when per-queue minimums take
effect.
- Replaced dmu_tx_write_limit in the dmu_tx kstat file
with dmu_tx_dirty_delay and dmu_tx_dirty_over_max. The first counts
how many times a transaction has been delayed because the pool dirty
data has exceeded zfs_delay_min_dirty_percent. The latter counts how
many times the pool dirty data has exceeded zfs_dirty_data_max (which
we expect to never happen).
- The original patch would have regressed the bug fixed in
zfsonlinux/zfs@c418410, which prevented users from setting the
zfs_vdev_aggregation_limit tuning larger than SPA_MAXBLOCKSIZE.
A similar fix is added to vdev_queue_aggregate().
- In vdev_queue_io_to_issue(), dynamically allocate 'zio_t search' on the
heap instead of the stack. In Linux we can't afford such large
structures on the stack.
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Reviewed by: Ned Bass <bass6@llnl.gov>
Reviewed by: Brendan Gregg <brendan.gregg@joyent.com>
Approved by: Robert Mustacchi <rm@joyent.com>
References:
http://www.illumos.org/issues/4045
illumos/illumos-gate@69962b5647e4a8b9b14998733b765925381b727e
Ported-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1913
2013-08-29 03:01:20 +00:00
|
|
|
.RE
|
|
|
|
|
2014-07-15 18:58:41 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBspa_load_verify_data\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Whether to traverse data blocks during an "extreme rewind" (\fB-X\fR)
|
|
|
|
import. Use 0 to disable and 1 to enable.
|
|
|
|
|
|
|
|
An extreme rewind import normally performs a full traversal of all
|
|
|
|
blocks in the pool for verification. If this parameter is set to 0,
|
|
|
|
the traversal skips non-metadata blocks. It can be toggled once the
|
|
|
|
import has started to stop or start the traversal of non-metadata blocks.
|
|
|
|
.sp
|
2015-12-30 17:44:46 +00:00
|
|
|
Default value: \fB1\fR.
|
2014-07-15 18:58:41 +00:00
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBspa_load_verify_metadata\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Whether to traverse blocks during an "extreme rewind" (\fB-X\fR)
|
|
|
|
pool import. Use 0 to disable and 1 to enable.
|
|
|
|
|
|
|
|
An extreme rewind import normally performs a full traversal of all
|
2016-03-28 22:13:42 +00:00
|
|
|
blocks in the pool for verification. If this parameter is set to 0,
|
2014-07-15 18:58:41 +00:00
|
|
|
the traversal is not performed. It can be toggled once the import has
|
|
|
|
started to stop or start the traversal.
|
|
|
|
.sp
|
2015-12-30 17:44:46 +00:00
|
|
|
Default value: \fB1\fR.
|
2014-07-15 18:58:41 +00:00
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBspa_load_verify_maxinflight\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Maximum concurrent I/Os during the traversal performed during an "extreme
|
|
|
|
rewind" (\fB-X\fR) pool import.
|
|
|
|
.sp
|
2015-12-30 17:44:46 +00:00
|
|
|
Default value: \fB10000\fR.
|
2014-07-15 18:58:41 +00:00
|
|
|
.RE
|
|
|
|
|
2015-09-01 16:45:10 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBspa_slop_shift\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Normally, we don't allow the last 3.2% (1/(2^spa_slop_shift)) of space
|
|
|
|
in the pool to be consumed. This ensures that we don't run the pool
|
|
|
|
completely out of space, due to unaccounted changes (e.g. to the MOS).
|
|
|
|
It also limits the worst-case time to allocate space. If we have
|
|
|
|
less than this amount of free space, most ZPL operations (e.g. write,
|
|
|
|
create) will return ENOSPC.
|
|
|
|
.sp
|
2015-12-30 17:44:46 +00:00
|
|
|
Default value: \fB5\fR.
|
2015-09-01 16:45:10 +00:00
|
|
|
.RE
|
|
|
|
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfetch_array_rd_sz\fR (ulong)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2014-06-04 12:23:31 +00:00
|
|
|
If prefetching is enabled, disable prefetching for reads larger than this size.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB1,048,576\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
2015-12-26 21:10:31 +00:00
|
|
|
\fBzfetch_max_distance\fR (uint)
|
2013-11-16 06:52:54 +00:00
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-26 21:10:31 +00:00
|
|
|
Max bytes to prefetch per stream (default 8MB).
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
2015-12-26 21:10:31 +00:00
|
|
|
Default value: \fB8,388,608\fR.
|
2013-11-16 06:52:54 +00:00
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfetch_max_streams\fR (uint)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2014-06-04 12:23:31 +00:00
|
|
|
Max number of streams per zfetch (prefetch streams per file).
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB8\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfetch_min_sec_reap\fR (uint)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2014-06-04 12:23:31 +00:00
|
|
|
Min time before an active prefetch stream can be reclaimed
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB2\fR.
|
|
|
|
.RE
|
|
|
|
|
2016-07-13 12:42:40 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_arc_dnode_limit\fR (ulong)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
When the number of bytes consumed by dnodes in the ARC exceeds this number of
|
|
|
|
bytes, try to unpin some of it in response to demand for non-metadata. This
|
|
|
|
value acts as a floor to the amount of dnode metadata.
|
|
|
|
|
|
|
|
See also \fBzfs_arc_meta_prune\fR which serves a similar purpose but is used
|
|
|
|
when the amount of metadata in the ARC exceeds \fBzfs_arc_meta_limit\fR rather
|
|
|
|
than in response to overall demand for non-metadata.
|
|
|
|
|
|
|
|
.sp
|
|
|
|
Default value: \fB10% of zfs_arc_meta_limit\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_arc_dnode_reduce_percent\fR (ulong)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Percentage of ARC dnodes to try to scan in response to demand for non-metadata
|
|
|
|
when the number of bytes consumed by dnodes exceeds \fBzfs_arc_dnode_limit\fB.
|
|
|
|
|
|
|
|
.sp
|
|
|
|
Default value: \fB10% of the number of dnodes in the ARC\fR.
|
|
|
|
.RE
|
|
|
|
|
2014-08-20 17:09:40 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_arc_average_blocksize\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
The ARC's buffer hash table is sized based on the assumption of an average
|
|
|
|
block size of \fBzfs_arc_average_blocksize\fR (default 8K). This works out
|
|
|
|
to roughly 1MB of hash table per 1GB of physical memory with 8-byte pointers.
|
|
|
|
For configurations with a known larger average block size this value can be
|
|
|
|
increased to reduce the memory footprint.
|
|
|
|
|
|
|
|
.sp
|
|
|
|
Default value: \fB8192\fR.
|
|
|
|
.RE
|
|
|
|
|
2015-01-13 03:52:19 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_arc_evict_batch_limit\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-07-01 11:42:35 +00:00
|
|
|
Number ARC headers to evict per sub-list before proceeding to another sub-list.
|
2015-01-13 03:52:19 +00:00
|
|
|
This batch-style operation prevents entire sub-lists from being evicted at once
|
|
|
|
but comes at a cost of additional unlocking and locking.
|
|
|
|
.sp
|
|
|
|
Default value: \fB10\fR.
|
|
|
|
.RE
|
|
|
|
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_arc_grow_retry\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
After a memory pressure event the ARC will wait this many seconds before trying
|
|
|
|
to resume growth
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB5\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
2015-07-28 18:30:00 +00:00
|
|
|
\fBzfs_arc_lotsfree_percent\fR (int)
|
2013-11-16 06:52:54 +00:00
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-07-28 18:30:00 +00:00
|
|
|
Throttle I/O when free system memory drops below this percentage of total
|
|
|
|
system memory. Setting this value to 0 will disable the throttle.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
2015-07-28 18:30:00 +00:00
|
|
|
Default value: \fB10\fR.
|
2013-11-16 06:52:54 +00:00
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
2015-07-28 18:30:00 +00:00
|
|
|
\fBzfs_arc_max\fR (ulong)
|
2013-11-16 06:52:54 +00:00
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Max arc size of ARC in bytes. If set to 0 then it will consume 1/2 of system
|
|
|
|
RAM. This value must be at least 67108864 (64 megabytes).
|
|
|
|
.sp
|
|
|
|
This value can be changed dynamically with some caveats. It cannot be set back
|
|
|
|
to 0 while running and reducing it below the current ARC size will not cause
|
|
|
|
the ARC to shrink without memory pressure to induce shrinking.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
2015-07-28 18:30:00 +00:00
|
|
|
Default value: \fB0\fR.
|
2013-11-16 06:52:54 +00:00
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_arc_meta_limit\fR (ulong)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-03-17 22:07:47 +00:00
|
|
|
The maximum allowed size in bytes that meta data buffers are allowed to
|
|
|
|
consume in the ARC. When this limit is reached meta data buffers will
|
|
|
|
be reclaimed even if the overall arc_c_max has not been reached. This
|
|
|
|
value defaults to 0 which indicates that 3/4 of the ARC may be used
|
|
|
|
for meta data.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
2015-12-30 17:44:46 +00:00
|
|
|
This value my be changed dynamically except that it cannot be set back to 0
|
|
|
|
for 3/4 of the ARC; it must be set to an explicit value.
|
|
|
|
.sp
|
2013-11-16 06:52:54 +00:00
|
|
|
Default value: \fB0\fR.
|
|
|
|
.RE
|
|
|
|
|
2015-01-13 03:52:19 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_arc_meta_min\fR (ulong)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
The minimum allowed size in bytes that meta data buffers may consume in
|
|
|
|
the ARC. This value defaults to 0 which disables a floor on the amount
|
|
|
|
of the ARC devoted meta data.
|
|
|
|
.sp
|
|
|
|
Default value: \fB0\fR.
|
|
|
|
.RE
|
|
|
|
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_arc_meta_prune\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-03-17 22:07:47 +00:00
|
|
|
The number of dentries and inodes to be scanned looking for entries
|
|
|
|
which can be dropped. This may be required when the ARC reaches the
|
|
|
|
\fBzfs_arc_meta_limit\fR because dentries and inodes can pin buffers
|
|
|
|
in the ARC. Increasing this value will cause to dentry and inode caches
|
|
|
|
to be pruned more aggressively. Setting this value to 0 will disable
|
|
|
|
pruning the inode and dentry caches.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
2015-03-17 22:07:47 +00:00
|
|
|
Default value: \fB10,000\fR.
|
2013-11-16 06:52:54 +00:00
|
|
|
.RE
|
|
|
|
|
2015-03-17 22:08:22 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_arc_meta_adjust_restarts\fR (ulong)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
The number of restart passes to make while scanning the ARC attempting
|
|
|
|
the free buffers in order to stay below the \fBzfs_arc_meta_limit\fR.
|
|
|
|
This value should not need to be tuned but is available to facilitate
|
|
|
|
performance analysis.
|
|
|
|
.sp
|
|
|
|
Default value: \fB4096\fR.
|
|
|
|
.RE
|
|
|
|
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_arc_min\fR (ulong)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Min arc size
|
|
|
|
.sp
|
|
|
|
Default value: \fB100\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_arc_min_prefetch_lifespan\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Minimum time prefetched blocks are locked in the ARC, specified in jiffies.
|
|
|
|
A value of 0 will default to 1 second.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
2015-12-30 17:44:46 +00:00
|
|
|
Default value: \fB0\fR.
|
2013-11-16 06:52:54 +00:00
|
|
|
.RE
|
|
|
|
|
2015-01-13 03:52:19 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_arc_num_sublists_per_state\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
To allow more fine-grained locking, each ARC state contains a series
|
|
|
|
of lists for both data and meta data objects. Locking is performed at
|
|
|
|
the level of these "sub-lists". This parameters controls the number of
|
|
|
|
sub-lists per ARC state.
|
|
|
|
.sp
|
2015-12-30 17:44:46 +00:00
|
|
|
Default value: \fR1\fB or the number of online CPUs, whichever is greater
|
2015-01-13 03:52:19 +00:00
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_arc_overflow_shift\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
The ARC size is considered to be overflowing if it exceeds the current
|
|
|
|
ARC target size (arc_c) by a threshold determined by this parameter.
|
|
|
|
The threshold is calculated as a fraction of arc_c using the formula
|
|
|
|
"arc_c >> \fBzfs_arc_overflow_shift\fR".
|
|
|
|
|
|
|
|
The default value of 8 causes the ARC to be considered to be overflowing
|
|
|
|
if it exceeds the target size by 1/256th (0.3%) of the target size.
|
|
|
|
|
|
|
|
When the ARC is overflowing, new buffer allocations are stalled until
|
|
|
|
the reclaim thread catches up and the overflow condition no longer exists.
|
|
|
|
.sp
|
|
|
|
Default value: \fB8\fR.
|
|
|
|
.RE
|
|
|
|
|
2015-06-26 22:59:23 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
|
|
|
|
\fBzfs_arc_p_min_shift\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
arc_c shift to calc min/max arc_p
|
|
|
|
.sp
|
|
|
|
Default value: \fB4\fR.
|
|
|
|
.RE
|
|
|
|
|
Disable aggressive arc_p growth by default
For specific workloads consisting mainly of mfu data and new anon data
buffers, the aggressive growth of arc_p found in the arc_get_data_buf()
function can have detrimental effects on the mfu list size and ghost
list hit rate.
Running a workload consisting of two processes:
* Process 1 is creating many small files
* Process 2 is tar'ing a directory consisting of many small files
I've seen arc_p and the mru grow to their maximum size, while the mru
ghost list receives 100K times fewer hits than the mfu ghost list.
Ideally, as the mfu ghost list receives hits, arc_p should be driven
down and the size of the mfu should increase. Given the specific
workload I was testing with, the mfu list size should grow to a point
where almost no mfu ghost list hits would occur. Unfortunately, this
does not happen because the newly dirtied anon buffers constancy drive
arc_p to its maximum value and keep it there (effectively prioritizing
the mru list and starving the mfu list down to a negligible size).
The logic to increment arc_p from within the arc_get_data_buf() function
was introduced many years ago in this upstream commit:
commit 641fbdae3a027d12b3c3dcd18927ccafae6d58bc
Author: maybee <none@none>
Date: Wed Dec 20 15:46:12 2006 -0800
6505658 target MRU size (arc.p) needs to be adjusted more aggressively
and since I don't fully understand the motivation for the change, I am
reluctant to completely remove it.
As a way to test out how it's removal might affect performance, I've
disabled that code by default, but left it tunable via a module option.
Thus, if its removal is found to be grossly detrimental for certain
workloads, it can be re-enabled on the fly, without a code change.
Signed-off-by: Prakash Surya <surya1@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #2110
2013-12-11 17:40:13 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_arc_p_aggressive_disable\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Disable aggressive arc_p growth
|
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes (default) and \fB0\fR to disable.
|
|
|
|
.RE
|
|
|
|
|
2014-01-03 18:36:26 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_arc_p_dampener_disable\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Disable arc_p adapt dampener
|
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes (default) and \fB0\fR to disable.
|
|
|
|
.RE
|
|
|
|
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_arc_shrink_shift\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
log2(fraction of arc to reclaim)
|
|
|
|
.sp
|
|
|
|
Default value: \fB5\fR.
|
|
|
|
.RE
|
|
|
|
|
2015-07-27 20:17:32 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_arc_sys_free\fR (ulong)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
The target number of bytes the ARC should leave as free memory on the system.
|
|
|
|
Defaults to the larger of 1/64 of physical memory or 512K. Setting this
|
|
|
|
option to a non-zero value will override the default.
|
|
|
|
.sp
|
|
|
|
Default value: \fB0\fR.
|
|
|
|
.RE
|
|
|
|
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_autoimport_disable\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2014-06-04 12:23:31 +00:00
|
|
|
Disable pool import at module load by ignoring the cache file (typically \fB/etc/zfs/zpool.cache\fR).
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
2015-04-24 18:03:26 +00:00
|
|
|
Use \fB1\fR for yes (default) and \fB0\fR for no.
|
2013-11-16 06:52:54 +00:00
|
|
|
.RE
|
|
|
|
|
2015-09-01 20:19:10 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_dbgmsg_enable\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Internally ZFS keeps a small log to facilitate debugging. By default the log
|
|
|
|
is disabled, to enable it set this option to 1. The contents of the log can
|
|
|
|
be accessed by reading the /proc/spl/kstat/zfs/dbgmsg file. Writing 0 to
|
|
|
|
this proc file clears the log.
|
|
|
|
.sp
|
|
|
|
Default value: \fB0\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_dbgmsg_maxsize\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
The maximum size in bytes of the internal ZFS debug log.
|
|
|
|
.sp
|
|
|
|
Default value: \fB4M\fR.
|
|
|
|
.RE
|
|
|
|
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_dbuf_state_index\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
This feature is currently unused. It is normally used for controlling what
|
|
|
|
reporting is available under /proc/spl/kstat/zfs.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB0\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_deadman_enabled\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Enable deadman timer. See description below.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes (default) and \fB0\fR to disable.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
Illumos #4045 write throttle & i/o scheduler performance work
4045 zfs write throttle & i/o scheduler performance work
1. The ZFS i/o scheduler (vdev_queue.c) now divides i/os into 5 classes: sync
read, sync write, async read, async write, and scrub/resilver. The scheduler
issues a number of concurrent i/os from each class to the device. Once a class
has been selected, an i/o is selected from this class using either an elevator
algorithem (async, scrub classes) or FIFO (sync classes). The number of
concurrent async write i/os is tuned dynamically based on i/o load, to achieve
good sync i/o latency when there is not a high load of writes, and good write
throughput when there is. See the block comment in vdev_queue.c (reproduced
below) for more details.
2. The write throttle (dsl_pool_tempreserve_space() and
txg_constrain_throughput()) is rewritten to produce much more consistent delays
when under constant load. The new write throttle is based on the amount of
dirty data, rather than guesses about future performance of the system. When
there is a lot of dirty data, each transaction (e.g. write() syscall) will be
delayed by the same small amount. This eliminates the "brick wall of wait"
that the old write throttle could hit, causing all transactions to wait several
seconds until the next txg opens. One of the keys to the new write throttle is
decrementing the amount of dirty data as i/o completes, rather than at the end
of spa_sync(). Note that the write throttle is only applied once the i/o
scheduler is issuing the maximum number of outstanding async writes. See the
block comments in dsl_pool.c and above dmu_tx_delay() (reproduced below) for
more details.
This diff has several other effects, including:
* the commonly-tuned global variable zfs_vdev_max_pending has been removed;
use per-class zfs_vdev_*_max_active values or zfs_vdev_max_active instead.
* the size of each txg (meaning the amount of dirty data written, and thus the
time it takes to write out) is now controlled differently. There is no longer
an explicit time goal; the primary determinant is amount of dirty data.
Systems that are under light or medium load will now often see that a txg is
always syncing, but the impact to performance (e.g. read latency) is minimal.
Tune zfs_dirty_data_max and zfs_dirty_data_sync to control this.
* zio_taskq_batch_pct = 75 -- Only use 75% of all CPUs for compression,
checksum, etc. This improves latency by not allowing these CPU-intensive tasks
to consume all CPU (on machines with at least 4 CPU's; the percentage is
rounded up).
--matt
APPENDIX: problems with the current i/o scheduler
The current ZFS i/o scheduler (vdev_queue.c) is deadline based. The problem
with this is that if there are always i/os pending, then certain classes of
i/os can see very long delays.
For example, if there are always synchronous reads outstanding, then no async
writes will be serviced until they become "past due". One symptom of this
situation is that each pass of the txg sync takes at least several seconds
(typically 3 seconds).
If many i/os become "past due" (their deadline is in the past), then we must
service all of these overdue i/os before any new i/os. This happens when we
enqueue a batch of async writes for the txg sync, with deadlines 2.5 seconds in
the future. If we can't complete all the i/os in 2.5 seconds (e.g. because
there were always reads pending), then these i/os will become past due. Now we
must service all the "async" writes (which could be hundreds of megabytes)
before we service any reads, introducing considerable latency to synchronous
i/os (reads or ZIL writes).
Notes on porting to ZFS on Linux:
- zio_t gained new members io_physdone and io_phys_children. Because
object caches in the Linux port call the constructor only once at
allocation time, objects may contain residual data when retrieved
from the cache. Therefore zio_create() was updated to zero out the two
new fields.
- vdev_mirror_pending() relied on the depth of the per-vdev pending queue
(vq->vq_pending_tree) to select the least-busy leaf vdev to read from.
This tree has been replaced by vq->vq_active_tree which is now used
for the same purpose.
- vdev_queue_init() used the value of zfs_vdev_max_pending to determine
the number of vdev I/O buffers to pre-allocate. That global no longer
exists, so we instead use the sum of the *_max_active values for each of
the five I/O classes described above.
- The Illumos implementation of dmu_tx_delay() delays a transaction by
sleeping in condition variable embedded in the thread
(curthread->t_delay_cv). We do not have an equivalent CV to use in
Linux, so this change replaced the delay logic with a wrapper called
zfs_sleep_until(). This wrapper could be adopted upstream and in other
downstream ports to abstract away operating system-specific delay logic.
- These tunables are added as module parameters, and descriptions added
to the zfs-module-parameters.5 man page.
spa_asize_inflation
zfs_deadman_synctime_ms
zfs_vdev_max_active
zfs_vdev_async_write_active_min_dirty_percent
zfs_vdev_async_write_active_max_dirty_percent
zfs_vdev_async_read_max_active
zfs_vdev_async_read_min_active
zfs_vdev_async_write_max_active
zfs_vdev_async_write_min_active
zfs_vdev_scrub_max_active
zfs_vdev_scrub_min_active
zfs_vdev_sync_read_max_active
zfs_vdev_sync_read_min_active
zfs_vdev_sync_write_max_active
zfs_vdev_sync_write_min_active
zfs_dirty_data_max_percent
zfs_delay_min_dirty_percent
zfs_dirty_data_max_max_percent
zfs_dirty_data_max
zfs_dirty_data_max_max
zfs_dirty_data_sync
zfs_delay_scale
The latter four have type unsigned long, whereas they are uint64_t in
Illumos. This accommodates Linux's module_param() supported types, but
means they may overflow on 32-bit architectures.
The values zfs_dirty_data_max and zfs_dirty_data_max_max are the most
likely to overflow on 32-bit systems, since they express physical RAM
sizes in bytes. In fact, Illumos initializes zfs_dirty_data_max_max to
2^32 which does overflow. To resolve that, this port instead initializes
it in arc_init() to 25% of physical RAM, and adds the tunable
zfs_dirty_data_max_max_percent to override that percentage. While this
solution doesn't completely avoid the overflow issue, it should be a
reasonable default for most systems, and the minority of affected
systems can work around the issue by overriding the defaults.
- Fixed reversed logic in comment above zfs_delay_scale declaration.
- Clarified comments in vdev_queue.c regarding when per-queue minimums take
effect.
- Replaced dmu_tx_write_limit in the dmu_tx kstat file
with dmu_tx_dirty_delay and dmu_tx_dirty_over_max. The first counts
how many times a transaction has been delayed because the pool dirty
data has exceeded zfs_delay_min_dirty_percent. The latter counts how
many times the pool dirty data has exceeded zfs_dirty_data_max (which
we expect to never happen).
- The original patch would have regressed the bug fixed in
zfsonlinux/zfs@c418410, which prevented users from setting the
zfs_vdev_aggregation_limit tuning larger than SPA_MAXBLOCKSIZE.
A similar fix is added to vdev_queue_aggregate().
- In vdev_queue_io_to_issue(), dynamically allocate 'zio_t search' on the
heap instead of the stack. In Linux we can't afford such large
structures on the stack.
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Reviewed by: Ned Bass <bass6@llnl.gov>
Reviewed by: Brendan Gregg <brendan.gregg@joyent.com>
Approved by: Robert Mustacchi <rm@joyent.com>
References:
http://www.illumos.org/issues/4045
illumos/illumos-gate@69962b5647e4a8b9b14998733b765925381b727e
Ported-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1913
2013-08-29 03:01:20 +00:00
|
|
|
\fBzfs_deadman_synctime_ms\fR (ulong)
|
2013-11-16 06:52:54 +00:00
|
|
|
.ad
|
|
|
|
.RS 12n
|
Illumos #4045 write throttle & i/o scheduler performance work
4045 zfs write throttle & i/o scheduler performance work
1. The ZFS i/o scheduler (vdev_queue.c) now divides i/os into 5 classes: sync
read, sync write, async read, async write, and scrub/resilver. The scheduler
issues a number of concurrent i/os from each class to the device. Once a class
has been selected, an i/o is selected from this class using either an elevator
algorithem (async, scrub classes) or FIFO (sync classes). The number of
concurrent async write i/os is tuned dynamically based on i/o load, to achieve
good sync i/o latency when there is not a high load of writes, and good write
throughput when there is. See the block comment in vdev_queue.c (reproduced
below) for more details.
2. The write throttle (dsl_pool_tempreserve_space() and
txg_constrain_throughput()) is rewritten to produce much more consistent delays
when under constant load. The new write throttle is based on the amount of
dirty data, rather than guesses about future performance of the system. When
there is a lot of dirty data, each transaction (e.g. write() syscall) will be
delayed by the same small amount. This eliminates the "brick wall of wait"
that the old write throttle could hit, causing all transactions to wait several
seconds until the next txg opens. One of the keys to the new write throttle is
decrementing the amount of dirty data as i/o completes, rather than at the end
of spa_sync(). Note that the write throttle is only applied once the i/o
scheduler is issuing the maximum number of outstanding async writes. See the
block comments in dsl_pool.c and above dmu_tx_delay() (reproduced below) for
more details.
This diff has several other effects, including:
* the commonly-tuned global variable zfs_vdev_max_pending has been removed;
use per-class zfs_vdev_*_max_active values or zfs_vdev_max_active instead.
* the size of each txg (meaning the amount of dirty data written, and thus the
time it takes to write out) is now controlled differently. There is no longer
an explicit time goal; the primary determinant is amount of dirty data.
Systems that are under light or medium load will now often see that a txg is
always syncing, but the impact to performance (e.g. read latency) is minimal.
Tune zfs_dirty_data_max and zfs_dirty_data_sync to control this.
* zio_taskq_batch_pct = 75 -- Only use 75% of all CPUs for compression,
checksum, etc. This improves latency by not allowing these CPU-intensive tasks
to consume all CPU (on machines with at least 4 CPU's; the percentage is
rounded up).
--matt
APPENDIX: problems with the current i/o scheduler
The current ZFS i/o scheduler (vdev_queue.c) is deadline based. The problem
with this is that if there are always i/os pending, then certain classes of
i/os can see very long delays.
For example, if there are always synchronous reads outstanding, then no async
writes will be serviced until they become "past due". One symptom of this
situation is that each pass of the txg sync takes at least several seconds
(typically 3 seconds).
If many i/os become "past due" (their deadline is in the past), then we must
service all of these overdue i/os before any new i/os. This happens when we
enqueue a batch of async writes for the txg sync, with deadlines 2.5 seconds in
the future. If we can't complete all the i/os in 2.5 seconds (e.g. because
there were always reads pending), then these i/os will become past due. Now we
must service all the "async" writes (which could be hundreds of megabytes)
before we service any reads, introducing considerable latency to synchronous
i/os (reads or ZIL writes).
Notes on porting to ZFS on Linux:
- zio_t gained new members io_physdone and io_phys_children. Because
object caches in the Linux port call the constructor only once at
allocation time, objects may contain residual data when retrieved
from the cache. Therefore zio_create() was updated to zero out the two
new fields.
- vdev_mirror_pending() relied on the depth of the per-vdev pending queue
(vq->vq_pending_tree) to select the least-busy leaf vdev to read from.
This tree has been replaced by vq->vq_active_tree which is now used
for the same purpose.
- vdev_queue_init() used the value of zfs_vdev_max_pending to determine
the number of vdev I/O buffers to pre-allocate. That global no longer
exists, so we instead use the sum of the *_max_active values for each of
the five I/O classes described above.
- The Illumos implementation of dmu_tx_delay() delays a transaction by
sleeping in condition variable embedded in the thread
(curthread->t_delay_cv). We do not have an equivalent CV to use in
Linux, so this change replaced the delay logic with a wrapper called
zfs_sleep_until(). This wrapper could be adopted upstream and in other
downstream ports to abstract away operating system-specific delay logic.
- These tunables are added as module parameters, and descriptions added
to the zfs-module-parameters.5 man page.
spa_asize_inflation
zfs_deadman_synctime_ms
zfs_vdev_max_active
zfs_vdev_async_write_active_min_dirty_percent
zfs_vdev_async_write_active_max_dirty_percent
zfs_vdev_async_read_max_active
zfs_vdev_async_read_min_active
zfs_vdev_async_write_max_active
zfs_vdev_async_write_min_active
zfs_vdev_scrub_max_active
zfs_vdev_scrub_min_active
zfs_vdev_sync_read_max_active
zfs_vdev_sync_read_min_active
zfs_vdev_sync_write_max_active
zfs_vdev_sync_write_min_active
zfs_dirty_data_max_percent
zfs_delay_min_dirty_percent
zfs_dirty_data_max_max_percent
zfs_dirty_data_max
zfs_dirty_data_max_max
zfs_dirty_data_sync
zfs_delay_scale
The latter four have type unsigned long, whereas they are uint64_t in
Illumos. This accommodates Linux's module_param() supported types, but
means they may overflow on 32-bit architectures.
The values zfs_dirty_data_max and zfs_dirty_data_max_max are the most
likely to overflow on 32-bit systems, since they express physical RAM
sizes in bytes. In fact, Illumos initializes zfs_dirty_data_max_max to
2^32 which does overflow. To resolve that, this port instead initializes
it in arc_init() to 25% of physical RAM, and adds the tunable
zfs_dirty_data_max_max_percent to override that percentage. While this
solution doesn't completely avoid the overflow issue, it should be a
reasonable default for most systems, and the minority of affected
systems can work around the issue by overriding the defaults.
- Fixed reversed logic in comment above zfs_delay_scale declaration.
- Clarified comments in vdev_queue.c regarding when per-queue minimums take
effect.
- Replaced dmu_tx_write_limit in the dmu_tx kstat file
with dmu_tx_dirty_delay and dmu_tx_dirty_over_max. The first counts
how many times a transaction has been delayed because the pool dirty
data has exceeded zfs_delay_min_dirty_percent. The latter counts how
many times the pool dirty data has exceeded zfs_dirty_data_max (which
we expect to never happen).
- The original patch would have regressed the bug fixed in
zfsonlinux/zfs@c418410, which prevented users from setting the
zfs_vdev_aggregation_limit tuning larger than SPA_MAXBLOCKSIZE.
A similar fix is added to vdev_queue_aggregate().
- In vdev_queue_io_to_issue(), dynamically allocate 'zio_t search' on the
heap instead of the stack. In Linux we can't afford such large
structures on the stack.
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Reviewed by: Ned Bass <bass6@llnl.gov>
Reviewed by: Brendan Gregg <brendan.gregg@joyent.com>
Approved by: Robert Mustacchi <rm@joyent.com>
References:
http://www.illumos.org/issues/4045
illumos/illumos-gate@69962b5647e4a8b9b14998733b765925381b727e
Ported-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1913
2013-08-29 03:01:20 +00:00
|
|
|
Expiration time in milliseconds. This value has two meanings. First it is
|
|
|
|
used to determine when the spa_deadman() logic should fire. By default the
|
|
|
|
spa_deadman() will fire if spa_sync() has not completed in 1000 seconds.
|
|
|
|
Secondly, the value determines if an I/O is considered "hung". Any I/O that
|
|
|
|
has not completed in zfs_deadman_synctime_ms is considered "hung" resulting
|
|
|
|
in a zevent being logged.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
Illumos #4045 write throttle & i/o scheduler performance work
4045 zfs write throttle & i/o scheduler performance work
1. The ZFS i/o scheduler (vdev_queue.c) now divides i/os into 5 classes: sync
read, sync write, async read, async write, and scrub/resilver. The scheduler
issues a number of concurrent i/os from each class to the device. Once a class
has been selected, an i/o is selected from this class using either an elevator
algorithem (async, scrub classes) or FIFO (sync classes). The number of
concurrent async write i/os is tuned dynamically based on i/o load, to achieve
good sync i/o latency when there is not a high load of writes, and good write
throughput when there is. See the block comment in vdev_queue.c (reproduced
below) for more details.
2. The write throttle (dsl_pool_tempreserve_space() and
txg_constrain_throughput()) is rewritten to produce much more consistent delays
when under constant load. The new write throttle is based on the amount of
dirty data, rather than guesses about future performance of the system. When
there is a lot of dirty data, each transaction (e.g. write() syscall) will be
delayed by the same small amount. This eliminates the "brick wall of wait"
that the old write throttle could hit, causing all transactions to wait several
seconds until the next txg opens. One of the keys to the new write throttle is
decrementing the amount of dirty data as i/o completes, rather than at the end
of spa_sync(). Note that the write throttle is only applied once the i/o
scheduler is issuing the maximum number of outstanding async writes. See the
block comments in dsl_pool.c and above dmu_tx_delay() (reproduced below) for
more details.
This diff has several other effects, including:
* the commonly-tuned global variable zfs_vdev_max_pending has been removed;
use per-class zfs_vdev_*_max_active values or zfs_vdev_max_active instead.
* the size of each txg (meaning the amount of dirty data written, and thus the
time it takes to write out) is now controlled differently. There is no longer
an explicit time goal; the primary determinant is amount of dirty data.
Systems that are under light or medium load will now often see that a txg is
always syncing, but the impact to performance (e.g. read latency) is minimal.
Tune zfs_dirty_data_max and zfs_dirty_data_sync to control this.
* zio_taskq_batch_pct = 75 -- Only use 75% of all CPUs for compression,
checksum, etc. This improves latency by not allowing these CPU-intensive tasks
to consume all CPU (on machines with at least 4 CPU's; the percentage is
rounded up).
--matt
APPENDIX: problems with the current i/o scheduler
The current ZFS i/o scheduler (vdev_queue.c) is deadline based. The problem
with this is that if there are always i/os pending, then certain classes of
i/os can see very long delays.
For example, if there are always synchronous reads outstanding, then no async
writes will be serviced until they become "past due". One symptom of this
situation is that each pass of the txg sync takes at least several seconds
(typically 3 seconds).
If many i/os become "past due" (their deadline is in the past), then we must
service all of these overdue i/os before any new i/os. This happens when we
enqueue a batch of async writes for the txg sync, with deadlines 2.5 seconds in
the future. If we can't complete all the i/os in 2.5 seconds (e.g. because
there were always reads pending), then these i/os will become past due. Now we
must service all the "async" writes (which could be hundreds of megabytes)
before we service any reads, introducing considerable latency to synchronous
i/os (reads or ZIL writes).
Notes on porting to ZFS on Linux:
- zio_t gained new members io_physdone and io_phys_children. Because
object caches in the Linux port call the constructor only once at
allocation time, objects may contain residual data when retrieved
from the cache. Therefore zio_create() was updated to zero out the two
new fields.
- vdev_mirror_pending() relied on the depth of the per-vdev pending queue
(vq->vq_pending_tree) to select the least-busy leaf vdev to read from.
This tree has been replaced by vq->vq_active_tree which is now used
for the same purpose.
- vdev_queue_init() used the value of zfs_vdev_max_pending to determine
the number of vdev I/O buffers to pre-allocate. That global no longer
exists, so we instead use the sum of the *_max_active values for each of
the five I/O classes described above.
- The Illumos implementation of dmu_tx_delay() delays a transaction by
sleeping in condition variable embedded in the thread
(curthread->t_delay_cv). We do not have an equivalent CV to use in
Linux, so this change replaced the delay logic with a wrapper called
zfs_sleep_until(). This wrapper could be adopted upstream and in other
downstream ports to abstract away operating system-specific delay logic.
- These tunables are added as module parameters, and descriptions added
to the zfs-module-parameters.5 man page.
spa_asize_inflation
zfs_deadman_synctime_ms
zfs_vdev_max_active
zfs_vdev_async_write_active_min_dirty_percent
zfs_vdev_async_write_active_max_dirty_percent
zfs_vdev_async_read_max_active
zfs_vdev_async_read_min_active
zfs_vdev_async_write_max_active
zfs_vdev_async_write_min_active
zfs_vdev_scrub_max_active
zfs_vdev_scrub_min_active
zfs_vdev_sync_read_max_active
zfs_vdev_sync_read_min_active
zfs_vdev_sync_write_max_active
zfs_vdev_sync_write_min_active
zfs_dirty_data_max_percent
zfs_delay_min_dirty_percent
zfs_dirty_data_max_max_percent
zfs_dirty_data_max
zfs_dirty_data_max_max
zfs_dirty_data_sync
zfs_delay_scale
The latter four have type unsigned long, whereas they are uint64_t in
Illumos. This accommodates Linux's module_param() supported types, but
means they may overflow on 32-bit architectures.
The values zfs_dirty_data_max and zfs_dirty_data_max_max are the most
likely to overflow on 32-bit systems, since they express physical RAM
sizes in bytes. In fact, Illumos initializes zfs_dirty_data_max_max to
2^32 which does overflow. To resolve that, this port instead initializes
it in arc_init() to 25% of physical RAM, and adds the tunable
zfs_dirty_data_max_max_percent to override that percentage. While this
solution doesn't completely avoid the overflow issue, it should be a
reasonable default for most systems, and the minority of affected
systems can work around the issue by overriding the defaults.
- Fixed reversed logic in comment above zfs_delay_scale declaration.
- Clarified comments in vdev_queue.c regarding when per-queue minimums take
effect.
- Replaced dmu_tx_write_limit in the dmu_tx kstat file
with dmu_tx_dirty_delay and dmu_tx_dirty_over_max. The first counts
how many times a transaction has been delayed because the pool dirty
data has exceeded zfs_delay_min_dirty_percent. The latter counts how
many times the pool dirty data has exceeded zfs_dirty_data_max (which
we expect to never happen).
- The original patch would have regressed the bug fixed in
zfsonlinux/zfs@c418410, which prevented users from setting the
zfs_vdev_aggregation_limit tuning larger than SPA_MAXBLOCKSIZE.
A similar fix is added to vdev_queue_aggregate().
- In vdev_queue_io_to_issue(), dynamically allocate 'zio_t search' on the
heap instead of the stack. In Linux we can't afford such large
structures on the stack.
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Reviewed by: Ned Bass <bass6@llnl.gov>
Reviewed by: Brendan Gregg <brendan.gregg@joyent.com>
Approved by: Robert Mustacchi <rm@joyent.com>
References:
http://www.illumos.org/issues/4045
illumos/illumos-gate@69962b5647e4a8b9b14998733b765925381b727e
Ported-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1913
2013-08-29 03:01:20 +00:00
|
|
|
Default value: \fB1,000,000\fR.
|
2013-11-16 06:52:54 +00:00
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_dedup_prefetch\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Enable prefetching dedup-ed blks
|
|
|
|
.sp
|
2014-08-30 02:13:26 +00:00
|
|
|
Use \fB1\fR for yes and \fB0\fR to disable (default).
|
2013-11-16 06:52:54 +00:00
|
|
|
.RE
|
|
|
|
|
Illumos #4045 write throttle & i/o scheduler performance work
4045 zfs write throttle & i/o scheduler performance work
1. The ZFS i/o scheduler (vdev_queue.c) now divides i/os into 5 classes: sync
read, sync write, async read, async write, and scrub/resilver. The scheduler
issues a number of concurrent i/os from each class to the device. Once a class
has been selected, an i/o is selected from this class using either an elevator
algorithem (async, scrub classes) or FIFO (sync classes). The number of
concurrent async write i/os is tuned dynamically based on i/o load, to achieve
good sync i/o latency when there is not a high load of writes, and good write
throughput when there is. See the block comment in vdev_queue.c (reproduced
below) for more details.
2. The write throttle (dsl_pool_tempreserve_space() and
txg_constrain_throughput()) is rewritten to produce much more consistent delays
when under constant load. The new write throttle is based on the amount of
dirty data, rather than guesses about future performance of the system. When
there is a lot of dirty data, each transaction (e.g. write() syscall) will be
delayed by the same small amount. This eliminates the "brick wall of wait"
that the old write throttle could hit, causing all transactions to wait several
seconds until the next txg opens. One of the keys to the new write throttle is
decrementing the amount of dirty data as i/o completes, rather than at the end
of spa_sync(). Note that the write throttle is only applied once the i/o
scheduler is issuing the maximum number of outstanding async writes. See the
block comments in dsl_pool.c and above dmu_tx_delay() (reproduced below) for
more details.
This diff has several other effects, including:
* the commonly-tuned global variable zfs_vdev_max_pending has been removed;
use per-class zfs_vdev_*_max_active values or zfs_vdev_max_active instead.
* the size of each txg (meaning the amount of dirty data written, and thus the
time it takes to write out) is now controlled differently. There is no longer
an explicit time goal; the primary determinant is amount of dirty data.
Systems that are under light or medium load will now often see that a txg is
always syncing, but the impact to performance (e.g. read latency) is minimal.
Tune zfs_dirty_data_max and zfs_dirty_data_sync to control this.
* zio_taskq_batch_pct = 75 -- Only use 75% of all CPUs for compression,
checksum, etc. This improves latency by not allowing these CPU-intensive tasks
to consume all CPU (on machines with at least 4 CPU's; the percentage is
rounded up).
--matt
APPENDIX: problems with the current i/o scheduler
The current ZFS i/o scheduler (vdev_queue.c) is deadline based. The problem
with this is that if there are always i/os pending, then certain classes of
i/os can see very long delays.
For example, if there are always synchronous reads outstanding, then no async
writes will be serviced until they become "past due". One symptom of this
situation is that each pass of the txg sync takes at least several seconds
(typically 3 seconds).
If many i/os become "past due" (their deadline is in the past), then we must
service all of these overdue i/os before any new i/os. This happens when we
enqueue a batch of async writes for the txg sync, with deadlines 2.5 seconds in
the future. If we can't complete all the i/os in 2.5 seconds (e.g. because
there were always reads pending), then these i/os will become past due. Now we
must service all the "async" writes (which could be hundreds of megabytes)
before we service any reads, introducing considerable latency to synchronous
i/os (reads or ZIL writes).
Notes on porting to ZFS on Linux:
- zio_t gained new members io_physdone and io_phys_children. Because
object caches in the Linux port call the constructor only once at
allocation time, objects may contain residual data when retrieved
from the cache. Therefore zio_create() was updated to zero out the two
new fields.
- vdev_mirror_pending() relied on the depth of the per-vdev pending queue
(vq->vq_pending_tree) to select the least-busy leaf vdev to read from.
This tree has been replaced by vq->vq_active_tree which is now used
for the same purpose.
- vdev_queue_init() used the value of zfs_vdev_max_pending to determine
the number of vdev I/O buffers to pre-allocate. That global no longer
exists, so we instead use the sum of the *_max_active values for each of
the five I/O classes described above.
- The Illumos implementation of dmu_tx_delay() delays a transaction by
sleeping in condition variable embedded in the thread
(curthread->t_delay_cv). We do not have an equivalent CV to use in
Linux, so this change replaced the delay logic with a wrapper called
zfs_sleep_until(). This wrapper could be adopted upstream and in other
downstream ports to abstract away operating system-specific delay logic.
- These tunables are added as module parameters, and descriptions added
to the zfs-module-parameters.5 man page.
spa_asize_inflation
zfs_deadman_synctime_ms
zfs_vdev_max_active
zfs_vdev_async_write_active_min_dirty_percent
zfs_vdev_async_write_active_max_dirty_percent
zfs_vdev_async_read_max_active
zfs_vdev_async_read_min_active
zfs_vdev_async_write_max_active
zfs_vdev_async_write_min_active
zfs_vdev_scrub_max_active
zfs_vdev_scrub_min_active
zfs_vdev_sync_read_max_active
zfs_vdev_sync_read_min_active
zfs_vdev_sync_write_max_active
zfs_vdev_sync_write_min_active
zfs_dirty_data_max_percent
zfs_delay_min_dirty_percent
zfs_dirty_data_max_max_percent
zfs_dirty_data_max
zfs_dirty_data_max_max
zfs_dirty_data_sync
zfs_delay_scale
The latter four have type unsigned long, whereas they are uint64_t in
Illumos. This accommodates Linux's module_param() supported types, but
means they may overflow on 32-bit architectures.
The values zfs_dirty_data_max and zfs_dirty_data_max_max are the most
likely to overflow on 32-bit systems, since they express physical RAM
sizes in bytes. In fact, Illumos initializes zfs_dirty_data_max_max to
2^32 which does overflow. To resolve that, this port instead initializes
it in arc_init() to 25% of physical RAM, and adds the tunable
zfs_dirty_data_max_max_percent to override that percentage. While this
solution doesn't completely avoid the overflow issue, it should be a
reasonable default for most systems, and the minority of affected
systems can work around the issue by overriding the defaults.
- Fixed reversed logic in comment above zfs_delay_scale declaration.
- Clarified comments in vdev_queue.c regarding when per-queue minimums take
effect.
- Replaced dmu_tx_write_limit in the dmu_tx kstat file
with dmu_tx_dirty_delay and dmu_tx_dirty_over_max. The first counts
how many times a transaction has been delayed because the pool dirty
data has exceeded zfs_delay_min_dirty_percent. The latter counts how
many times the pool dirty data has exceeded zfs_dirty_data_max (which
we expect to never happen).
- The original patch would have regressed the bug fixed in
zfsonlinux/zfs@c418410, which prevented users from setting the
zfs_vdev_aggregation_limit tuning larger than SPA_MAXBLOCKSIZE.
A similar fix is added to vdev_queue_aggregate().
- In vdev_queue_io_to_issue(), dynamically allocate 'zio_t search' on the
heap instead of the stack. In Linux we can't afford such large
structures on the stack.
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Reviewed by: Ned Bass <bass6@llnl.gov>
Reviewed by: Brendan Gregg <brendan.gregg@joyent.com>
Approved by: Robert Mustacchi <rm@joyent.com>
References:
http://www.illumos.org/issues/4045
illumos/illumos-gate@69962b5647e4a8b9b14998733b765925381b727e
Ported-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1913
2013-08-29 03:01:20 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_delay_min_dirty_percent\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Start to delay each transaction once there is this amount of dirty data,
|
|
|
|
expressed as a percentage of \fBzfs_dirty_data_max\fR.
|
|
|
|
This value should be >= zfs_vdev_async_write_active_max_dirty_percent.
|
|
|
|
See the section "ZFS TRANSACTION DELAY".
|
|
|
|
.sp
|
|
|
|
Default value: \fB60\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_delay_scale\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
This controls how quickly the transaction delay approaches infinity.
|
|
|
|
Larger values cause longer delays for a given amount of dirty data.
|
|
|
|
.sp
|
|
|
|
For the smoothest delay, this value should be about 1 billion divided
|
|
|
|
by the maximum number of operations per second. This will smoothly
|
|
|
|
handle between 10x and 1/10th this number.
|
|
|
|
.sp
|
|
|
|
See the section "ZFS TRANSACTION DELAY".
|
|
|
|
.sp
|
|
|
|
Note: \fBzfs_delay_scale\fR * \fBzfs_dirty_data_max\fR must be < 2^64.
|
|
|
|
.sp
|
|
|
|
Default value: \fB500,000\fR.
|
|
|
|
.RE
|
|
|
|
|
2015-08-21 01:43:10 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_delete_blocks\fR (ulong)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
This is the used to define a large file for the purposes of delete. Files
|
|
|
|
containing more than \fBzfs_delete_blocks\fR will be deleted asynchronously
|
|
|
|
while smaller files are deleted synchronously. Decreasing this value will
|
|
|
|
reduce the time spent in an unlink(2) system call at the expense of a longer
|
|
|
|
delay before the freed space is available.
|
|
|
|
.sp
|
|
|
|
Default value: \fB20,480\fR.
|
|
|
|
.RE
|
|
|
|
|
Illumos #4045 write throttle & i/o scheduler performance work
4045 zfs write throttle & i/o scheduler performance work
1. The ZFS i/o scheduler (vdev_queue.c) now divides i/os into 5 classes: sync
read, sync write, async read, async write, and scrub/resilver. The scheduler
issues a number of concurrent i/os from each class to the device. Once a class
has been selected, an i/o is selected from this class using either an elevator
algorithem (async, scrub classes) or FIFO (sync classes). The number of
concurrent async write i/os is tuned dynamically based on i/o load, to achieve
good sync i/o latency when there is not a high load of writes, and good write
throughput when there is. See the block comment in vdev_queue.c (reproduced
below) for more details.
2. The write throttle (dsl_pool_tempreserve_space() and
txg_constrain_throughput()) is rewritten to produce much more consistent delays
when under constant load. The new write throttle is based on the amount of
dirty data, rather than guesses about future performance of the system. When
there is a lot of dirty data, each transaction (e.g. write() syscall) will be
delayed by the same small amount. This eliminates the "brick wall of wait"
that the old write throttle could hit, causing all transactions to wait several
seconds until the next txg opens. One of the keys to the new write throttle is
decrementing the amount of dirty data as i/o completes, rather than at the end
of spa_sync(). Note that the write throttle is only applied once the i/o
scheduler is issuing the maximum number of outstanding async writes. See the
block comments in dsl_pool.c and above dmu_tx_delay() (reproduced below) for
more details.
This diff has several other effects, including:
* the commonly-tuned global variable zfs_vdev_max_pending has been removed;
use per-class zfs_vdev_*_max_active values or zfs_vdev_max_active instead.
* the size of each txg (meaning the amount of dirty data written, and thus the
time it takes to write out) is now controlled differently. There is no longer
an explicit time goal; the primary determinant is amount of dirty data.
Systems that are under light or medium load will now often see that a txg is
always syncing, but the impact to performance (e.g. read latency) is minimal.
Tune zfs_dirty_data_max and zfs_dirty_data_sync to control this.
* zio_taskq_batch_pct = 75 -- Only use 75% of all CPUs for compression,
checksum, etc. This improves latency by not allowing these CPU-intensive tasks
to consume all CPU (on machines with at least 4 CPU's; the percentage is
rounded up).
--matt
APPENDIX: problems with the current i/o scheduler
The current ZFS i/o scheduler (vdev_queue.c) is deadline based. The problem
with this is that if there are always i/os pending, then certain classes of
i/os can see very long delays.
For example, if there are always synchronous reads outstanding, then no async
writes will be serviced until they become "past due". One symptom of this
situation is that each pass of the txg sync takes at least several seconds
(typically 3 seconds).
If many i/os become "past due" (their deadline is in the past), then we must
service all of these overdue i/os before any new i/os. This happens when we
enqueue a batch of async writes for the txg sync, with deadlines 2.5 seconds in
the future. If we can't complete all the i/os in 2.5 seconds (e.g. because
there were always reads pending), then these i/os will become past due. Now we
must service all the "async" writes (which could be hundreds of megabytes)
before we service any reads, introducing considerable latency to synchronous
i/os (reads or ZIL writes).
Notes on porting to ZFS on Linux:
- zio_t gained new members io_physdone and io_phys_children. Because
object caches in the Linux port call the constructor only once at
allocation time, objects may contain residual data when retrieved
from the cache. Therefore zio_create() was updated to zero out the two
new fields.
- vdev_mirror_pending() relied on the depth of the per-vdev pending queue
(vq->vq_pending_tree) to select the least-busy leaf vdev to read from.
This tree has been replaced by vq->vq_active_tree which is now used
for the same purpose.
- vdev_queue_init() used the value of zfs_vdev_max_pending to determine
the number of vdev I/O buffers to pre-allocate. That global no longer
exists, so we instead use the sum of the *_max_active values for each of
the five I/O classes described above.
- The Illumos implementation of dmu_tx_delay() delays a transaction by
sleeping in condition variable embedded in the thread
(curthread->t_delay_cv). We do not have an equivalent CV to use in
Linux, so this change replaced the delay logic with a wrapper called
zfs_sleep_until(). This wrapper could be adopted upstream and in other
downstream ports to abstract away operating system-specific delay logic.
- These tunables are added as module parameters, and descriptions added
to the zfs-module-parameters.5 man page.
spa_asize_inflation
zfs_deadman_synctime_ms
zfs_vdev_max_active
zfs_vdev_async_write_active_min_dirty_percent
zfs_vdev_async_write_active_max_dirty_percent
zfs_vdev_async_read_max_active
zfs_vdev_async_read_min_active
zfs_vdev_async_write_max_active
zfs_vdev_async_write_min_active
zfs_vdev_scrub_max_active
zfs_vdev_scrub_min_active
zfs_vdev_sync_read_max_active
zfs_vdev_sync_read_min_active
zfs_vdev_sync_write_max_active
zfs_vdev_sync_write_min_active
zfs_dirty_data_max_percent
zfs_delay_min_dirty_percent
zfs_dirty_data_max_max_percent
zfs_dirty_data_max
zfs_dirty_data_max_max
zfs_dirty_data_sync
zfs_delay_scale
The latter four have type unsigned long, whereas they are uint64_t in
Illumos. This accommodates Linux's module_param() supported types, but
means they may overflow on 32-bit architectures.
The values zfs_dirty_data_max and zfs_dirty_data_max_max are the most
likely to overflow on 32-bit systems, since they express physical RAM
sizes in bytes. In fact, Illumos initializes zfs_dirty_data_max_max to
2^32 which does overflow. To resolve that, this port instead initializes
it in arc_init() to 25% of physical RAM, and adds the tunable
zfs_dirty_data_max_max_percent to override that percentage. While this
solution doesn't completely avoid the overflow issue, it should be a
reasonable default for most systems, and the minority of affected
systems can work around the issue by overriding the defaults.
- Fixed reversed logic in comment above zfs_delay_scale declaration.
- Clarified comments in vdev_queue.c regarding when per-queue minimums take
effect.
- Replaced dmu_tx_write_limit in the dmu_tx kstat file
with dmu_tx_dirty_delay and dmu_tx_dirty_over_max. The first counts
how many times a transaction has been delayed because the pool dirty
data has exceeded zfs_delay_min_dirty_percent. The latter counts how
many times the pool dirty data has exceeded zfs_dirty_data_max (which
we expect to never happen).
- The original patch would have regressed the bug fixed in
zfsonlinux/zfs@c418410, which prevented users from setting the
zfs_vdev_aggregation_limit tuning larger than SPA_MAXBLOCKSIZE.
A similar fix is added to vdev_queue_aggregate().
- In vdev_queue_io_to_issue(), dynamically allocate 'zio_t search' on the
heap instead of the stack. In Linux we can't afford such large
structures on the stack.
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Reviewed by: Ned Bass <bass6@llnl.gov>
Reviewed by: Brendan Gregg <brendan.gregg@joyent.com>
Approved by: Robert Mustacchi <rm@joyent.com>
References:
http://www.illumos.org/issues/4045
illumos/illumos-gate@69962b5647e4a8b9b14998733b765925381b727e
Ported-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1913
2013-08-29 03:01:20 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_dirty_data_max\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Determines the dirty space limit in bytes. Once this limit is exceeded, new
|
|
|
|
writes are halted until space frees up. This parameter takes precedence
|
|
|
|
over \fBzfs_dirty_data_max_percent\fR.
|
|
|
|
See the section "ZFS TRANSACTION DELAY".
|
|
|
|
.sp
|
|
|
|
Default value: 10 percent of all memory, capped at \fBzfs_dirty_data_max_max\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_dirty_data_max_max\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Maximum allowable value of \fBzfs_dirty_data_max\fR, expressed in bytes.
|
|
|
|
This limit is only enforced at module load time, and will be ignored if
|
|
|
|
\fBzfs_dirty_data_max\fR is later changed. This parameter takes
|
|
|
|
precedence over \fBzfs_dirty_data_max_max_percent\fR. See the section
|
|
|
|
"ZFS TRANSACTION DELAY".
|
|
|
|
.sp
|
|
|
|
Default value: 25% of physical RAM.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_dirty_data_max_max_percent\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Maximum allowable value of \fBzfs_dirty_data_max\fR, expressed as a
|
|
|
|
percentage of physical RAM. This limit is only enforced at module load
|
|
|
|
time, and will be ignored if \fBzfs_dirty_data_max\fR is later changed.
|
|
|
|
The parameter \fBzfs_dirty_data_max_max\fR takes precedence over this
|
|
|
|
one. See the section "ZFS TRANSACTION DELAY".
|
|
|
|
.sp
|
2015-12-30 17:44:46 +00:00
|
|
|
Default value: \fN25\fR.
|
Illumos #4045 write throttle & i/o scheduler performance work
4045 zfs write throttle & i/o scheduler performance work
1. The ZFS i/o scheduler (vdev_queue.c) now divides i/os into 5 classes: sync
read, sync write, async read, async write, and scrub/resilver. The scheduler
issues a number of concurrent i/os from each class to the device. Once a class
has been selected, an i/o is selected from this class using either an elevator
algorithem (async, scrub classes) or FIFO (sync classes). The number of
concurrent async write i/os is tuned dynamically based on i/o load, to achieve
good sync i/o latency when there is not a high load of writes, and good write
throughput when there is. See the block comment in vdev_queue.c (reproduced
below) for more details.
2. The write throttle (dsl_pool_tempreserve_space() and
txg_constrain_throughput()) is rewritten to produce much more consistent delays
when under constant load. The new write throttle is based on the amount of
dirty data, rather than guesses about future performance of the system. When
there is a lot of dirty data, each transaction (e.g. write() syscall) will be
delayed by the same small amount. This eliminates the "brick wall of wait"
that the old write throttle could hit, causing all transactions to wait several
seconds until the next txg opens. One of the keys to the new write throttle is
decrementing the amount of dirty data as i/o completes, rather than at the end
of spa_sync(). Note that the write throttle is only applied once the i/o
scheduler is issuing the maximum number of outstanding async writes. See the
block comments in dsl_pool.c and above dmu_tx_delay() (reproduced below) for
more details.
This diff has several other effects, including:
* the commonly-tuned global variable zfs_vdev_max_pending has been removed;
use per-class zfs_vdev_*_max_active values or zfs_vdev_max_active instead.
* the size of each txg (meaning the amount of dirty data written, and thus the
time it takes to write out) is now controlled differently. There is no longer
an explicit time goal; the primary determinant is amount of dirty data.
Systems that are under light or medium load will now often see that a txg is
always syncing, but the impact to performance (e.g. read latency) is minimal.
Tune zfs_dirty_data_max and zfs_dirty_data_sync to control this.
* zio_taskq_batch_pct = 75 -- Only use 75% of all CPUs for compression,
checksum, etc. This improves latency by not allowing these CPU-intensive tasks
to consume all CPU (on machines with at least 4 CPU's; the percentage is
rounded up).
--matt
APPENDIX: problems with the current i/o scheduler
The current ZFS i/o scheduler (vdev_queue.c) is deadline based. The problem
with this is that if there are always i/os pending, then certain classes of
i/os can see very long delays.
For example, if there are always synchronous reads outstanding, then no async
writes will be serviced until they become "past due". One symptom of this
situation is that each pass of the txg sync takes at least several seconds
(typically 3 seconds).
If many i/os become "past due" (their deadline is in the past), then we must
service all of these overdue i/os before any new i/os. This happens when we
enqueue a batch of async writes for the txg sync, with deadlines 2.5 seconds in
the future. If we can't complete all the i/os in 2.5 seconds (e.g. because
there were always reads pending), then these i/os will become past due. Now we
must service all the "async" writes (which could be hundreds of megabytes)
before we service any reads, introducing considerable latency to synchronous
i/os (reads or ZIL writes).
Notes on porting to ZFS on Linux:
- zio_t gained new members io_physdone and io_phys_children. Because
object caches in the Linux port call the constructor only once at
allocation time, objects may contain residual data when retrieved
from the cache. Therefore zio_create() was updated to zero out the two
new fields.
- vdev_mirror_pending() relied on the depth of the per-vdev pending queue
(vq->vq_pending_tree) to select the least-busy leaf vdev to read from.
This tree has been replaced by vq->vq_active_tree which is now used
for the same purpose.
- vdev_queue_init() used the value of zfs_vdev_max_pending to determine
the number of vdev I/O buffers to pre-allocate. That global no longer
exists, so we instead use the sum of the *_max_active values for each of
the five I/O classes described above.
- The Illumos implementation of dmu_tx_delay() delays a transaction by
sleeping in condition variable embedded in the thread
(curthread->t_delay_cv). We do not have an equivalent CV to use in
Linux, so this change replaced the delay logic with a wrapper called
zfs_sleep_until(). This wrapper could be adopted upstream and in other
downstream ports to abstract away operating system-specific delay logic.
- These tunables are added as module parameters, and descriptions added
to the zfs-module-parameters.5 man page.
spa_asize_inflation
zfs_deadman_synctime_ms
zfs_vdev_max_active
zfs_vdev_async_write_active_min_dirty_percent
zfs_vdev_async_write_active_max_dirty_percent
zfs_vdev_async_read_max_active
zfs_vdev_async_read_min_active
zfs_vdev_async_write_max_active
zfs_vdev_async_write_min_active
zfs_vdev_scrub_max_active
zfs_vdev_scrub_min_active
zfs_vdev_sync_read_max_active
zfs_vdev_sync_read_min_active
zfs_vdev_sync_write_max_active
zfs_vdev_sync_write_min_active
zfs_dirty_data_max_percent
zfs_delay_min_dirty_percent
zfs_dirty_data_max_max_percent
zfs_dirty_data_max
zfs_dirty_data_max_max
zfs_dirty_data_sync
zfs_delay_scale
The latter four have type unsigned long, whereas they are uint64_t in
Illumos. This accommodates Linux's module_param() supported types, but
means they may overflow on 32-bit architectures.
The values zfs_dirty_data_max and zfs_dirty_data_max_max are the most
likely to overflow on 32-bit systems, since they express physical RAM
sizes in bytes. In fact, Illumos initializes zfs_dirty_data_max_max to
2^32 which does overflow. To resolve that, this port instead initializes
it in arc_init() to 25% of physical RAM, and adds the tunable
zfs_dirty_data_max_max_percent to override that percentage. While this
solution doesn't completely avoid the overflow issue, it should be a
reasonable default for most systems, and the minority of affected
systems can work around the issue by overriding the defaults.
- Fixed reversed logic in comment above zfs_delay_scale declaration.
- Clarified comments in vdev_queue.c regarding when per-queue minimums take
effect.
- Replaced dmu_tx_write_limit in the dmu_tx kstat file
with dmu_tx_dirty_delay and dmu_tx_dirty_over_max. The first counts
how many times a transaction has been delayed because the pool dirty
data has exceeded zfs_delay_min_dirty_percent. The latter counts how
many times the pool dirty data has exceeded zfs_dirty_data_max (which
we expect to never happen).
- The original patch would have regressed the bug fixed in
zfsonlinux/zfs@c418410, which prevented users from setting the
zfs_vdev_aggregation_limit tuning larger than SPA_MAXBLOCKSIZE.
A similar fix is added to vdev_queue_aggregate().
- In vdev_queue_io_to_issue(), dynamically allocate 'zio_t search' on the
heap instead of the stack. In Linux we can't afford such large
structures on the stack.
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Reviewed by: Ned Bass <bass6@llnl.gov>
Reviewed by: Brendan Gregg <brendan.gregg@joyent.com>
Approved by: Robert Mustacchi <rm@joyent.com>
References:
http://www.illumos.org/issues/4045
illumos/illumos-gate@69962b5647e4a8b9b14998733b765925381b727e
Ported-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1913
2013-08-29 03:01:20 +00:00
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_dirty_data_max_percent\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Determines the dirty space limit, expressed as a percentage of all
|
|
|
|
memory. Once this limit is exceeded, new writes are halted until space frees
|
|
|
|
up. The parameter \fBzfs_dirty_data_max\fR takes precedence over this
|
|
|
|
one. See the section "ZFS TRANSACTION DELAY".
|
|
|
|
.sp
|
|
|
|
Default value: 10%, subject to \fBzfs_dirty_data_max_max\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_dirty_data_sync\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Start syncing out a transaction group if there is at least this much dirty data.
|
|
|
|
.sp
|
|
|
|
Default value: \fB67,108,864\fR.
|
|
|
|
.RE
|
|
|
|
|
2015-12-09 23:34:16 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_fletcher_4_impl\fR (string)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Select a fletcher 4 implementation.
|
|
|
|
.sp
|
2016-06-24 03:32:40 +00:00
|
|
|
Supported selectors are: \fBfastest\fR, \fBscalar\fR, \fBsse2\fR, \fBssse3\fR,
|
|
|
|
and \fBavx2\fR. All of the selectors except \fBfastest\fR and \fBscalar\fR
|
|
|
|
require instruction set extensions to be available and will only appear if ZFS
|
|
|
|
detects that they are present at runtime. If multiple implementations of
|
|
|
|
fletcher 4 are available, the \fBfastest\fR will be chosen using a micro
|
|
|
|
benchmark. Selecting \fBscalar\fR results in the original CPU based calculation
|
|
|
|
being used. Selecting any option other than \fBfastest\fR and \fBscalar\fR
|
|
|
|
results in vector instructions from the respective CPU instruction set being
|
|
|
|
used.
|
2015-12-09 23:34:16 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fBfastest\fR.
|
|
|
|
.RE
|
|
|
|
|
2016-01-23 00:41:02 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_free_bpobj_enabled\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Enable/disable the processing of the free_bpobj object.
|
|
|
|
.sp
|
|
|
|
Default value: \fB1\fR.
|
|
|
|
.RE
|
|
|
|
|
2014-09-07 15:06:08 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_free_max_blocks\fR (ulong)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Maximum number of blocks freed in a single txg.
|
|
|
|
.sp
|
|
|
|
Default value: \fB100,000\fR.
|
|
|
|
.RE
|
|
|
|
|
Illumos #4045 write throttle & i/o scheduler performance work
4045 zfs write throttle & i/o scheduler performance work
1. The ZFS i/o scheduler (vdev_queue.c) now divides i/os into 5 classes: sync
read, sync write, async read, async write, and scrub/resilver. The scheduler
issues a number of concurrent i/os from each class to the device. Once a class
has been selected, an i/o is selected from this class using either an elevator
algorithem (async, scrub classes) or FIFO (sync classes). The number of
concurrent async write i/os is tuned dynamically based on i/o load, to achieve
good sync i/o latency when there is not a high load of writes, and good write
throughput when there is. See the block comment in vdev_queue.c (reproduced
below) for more details.
2. The write throttle (dsl_pool_tempreserve_space() and
txg_constrain_throughput()) is rewritten to produce much more consistent delays
when under constant load. The new write throttle is based on the amount of
dirty data, rather than guesses about future performance of the system. When
there is a lot of dirty data, each transaction (e.g. write() syscall) will be
delayed by the same small amount. This eliminates the "brick wall of wait"
that the old write throttle could hit, causing all transactions to wait several
seconds until the next txg opens. One of the keys to the new write throttle is
decrementing the amount of dirty data as i/o completes, rather than at the end
of spa_sync(). Note that the write throttle is only applied once the i/o
scheduler is issuing the maximum number of outstanding async writes. See the
block comments in dsl_pool.c and above dmu_tx_delay() (reproduced below) for
more details.
This diff has several other effects, including:
* the commonly-tuned global variable zfs_vdev_max_pending has been removed;
use per-class zfs_vdev_*_max_active values or zfs_vdev_max_active instead.
* the size of each txg (meaning the amount of dirty data written, and thus the
time it takes to write out) is now controlled differently. There is no longer
an explicit time goal; the primary determinant is amount of dirty data.
Systems that are under light or medium load will now often see that a txg is
always syncing, but the impact to performance (e.g. read latency) is minimal.
Tune zfs_dirty_data_max and zfs_dirty_data_sync to control this.
* zio_taskq_batch_pct = 75 -- Only use 75% of all CPUs for compression,
checksum, etc. This improves latency by not allowing these CPU-intensive tasks
to consume all CPU (on machines with at least 4 CPU's; the percentage is
rounded up).
--matt
APPENDIX: problems with the current i/o scheduler
The current ZFS i/o scheduler (vdev_queue.c) is deadline based. The problem
with this is that if there are always i/os pending, then certain classes of
i/os can see very long delays.
For example, if there are always synchronous reads outstanding, then no async
writes will be serviced until they become "past due". One symptom of this
situation is that each pass of the txg sync takes at least several seconds
(typically 3 seconds).
If many i/os become "past due" (their deadline is in the past), then we must
service all of these overdue i/os before any new i/os. This happens when we
enqueue a batch of async writes for the txg sync, with deadlines 2.5 seconds in
the future. If we can't complete all the i/os in 2.5 seconds (e.g. because
there were always reads pending), then these i/os will become past due. Now we
must service all the "async" writes (which could be hundreds of megabytes)
before we service any reads, introducing considerable latency to synchronous
i/os (reads or ZIL writes).
Notes on porting to ZFS on Linux:
- zio_t gained new members io_physdone and io_phys_children. Because
object caches in the Linux port call the constructor only once at
allocation time, objects may contain residual data when retrieved
from the cache. Therefore zio_create() was updated to zero out the two
new fields.
- vdev_mirror_pending() relied on the depth of the per-vdev pending queue
(vq->vq_pending_tree) to select the least-busy leaf vdev to read from.
This tree has been replaced by vq->vq_active_tree which is now used
for the same purpose.
- vdev_queue_init() used the value of zfs_vdev_max_pending to determine
the number of vdev I/O buffers to pre-allocate. That global no longer
exists, so we instead use the sum of the *_max_active values for each of
the five I/O classes described above.
- The Illumos implementation of dmu_tx_delay() delays a transaction by
sleeping in condition variable embedded in the thread
(curthread->t_delay_cv). We do not have an equivalent CV to use in
Linux, so this change replaced the delay logic with a wrapper called
zfs_sleep_until(). This wrapper could be adopted upstream and in other
downstream ports to abstract away operating system-specific delay logic.
- These tunables are added as module parameters, and descriptions added
to the zfs-module-parameters.5 man page.
spa_asize_inflation
zfs_deadman_synctime_ms
zfs_vdev_max_active
zfs_vdev_async_write_active_min_dirty_percent
zfs_vdev_async_write_active_max_dirty_percent
zfs_vdev_async_read_max_active
zfs_vdev_async_read_min_active
zfs_vdev_async_write_max_active
zfs_vdev_async_write_min_active
zfs_vdev_scrub_max_active
zfs_vdev_scrub_min_active
zfs_vdev_sync_read_max_active
zfs_vdev_sync_read_min_active
zfs_vdev_sync_write_max_active
zfs_vdev_sync_write_min_active
zfs_dirty_data_max_percent
zfs_delay_min_dirty_percent
zfs_dirty_data_max_max_percent
zfs_dirty_data_max
zfs_dirty_data_max_max
zfs_dirty_data_sync
zfs_delay_scale
The latter four have type unsigned long, whereas they are uint64_t in
Illumos. This accommodates Linux's module_param() supported types, but
means they may overflow on 32-bit architectures.
The values zfs_dirty_data_max and zfs_dirty_data_max_max are the most
likely to overflow on 32-bit systems, since they express physical RAM
sizes in bytes. In fact, Illumos initializes zfs_dirty_data_max_max to
2^32 which does overflow. To resolve that, this port instead initializes
it in arc_init() to 25% of physical RAM, and adds the tunable
zfs_dirty_data_max_max_percent to override that percentage. While this
solution doesn't completely avoid the overflow issue, it should be a
reasonable default for most systems, and the minority of affected
systems can work around the issue by overriding the defaults.
- Fixed reversed logic in comment above zfs_delay_scale declaration.
- Clarified comments in vdev_queue.c regarding when per-queue minimums take
effect.
- Replaced dmu_tx_write_limit in the dmu_tx kstat file
with dmu_tx_dirty_delay and dmu_tx_dirty_over_max. The first counts
how many times a transaction has been delayed because the pool dirty
data has exceeded zfs_delay_min_dirty_percent. The latter counts how
many times the pool dirty data has exceeded zfs_dirty_data_max (which
we expect to never happen).
- The original patch would have regressed the bug fixed in
zfsonlinux/zfs@c418410, which prevented users from setting the
zfs_vdev_aggregation_limit tuning larger than SPA_MAXBLOCKSIZE.
A similar fix is added to vdev_queue_aggregate().
- In vdev_queue_io_to_issue(), dynamically allocate 'zio_t search' on the
heap instead of the stack. In Linux we can't afford such large
structures on the stack.
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Reviewed by: Ned Bass <bass6@llnl.gov>
Reviewed by: Brendan Gregg <brendan.gregg@joyent.com>
Approved by: Robert Mustacchi <rm@joyent.com>
References:
http://www.illumos.org/issues/4045
illumos/illumos-gate@69962b5647e4a8b9b14998733b765925381b727e
Ported-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1913
2013-08-29 03:01:20 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_async_read_max_active\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Maximum asynchronous read I/Os active to each device.
|
Illumos #4045 write throttle & i/o scheduler performance work
4045 zfs write throttle & i/o scheduler performance work
1. The ZFS i/o scheduler (vdev_queue.c) now divides i/os into 5 classes: sync
read, sync write, async read, async write, and scrub/resilver. The scheduler
issues a number of concurrent i/os from each class to the device. Once a class
has been selected, an i/o is selected from this class using either an elevator
algorithem (async, scrub classes) or FIFO (sync classes). The number of
concurrent async write i/os is tuned dynamically based on i/o load, to achieve
good sync i/o latency when there is not a high load of writes, and good write
throughput when there is. See the block comment in vdev_queue.c (reproduced
below) for more details.
2. The write throttle (dsl_pool_tempreserve_space() and
txg_constrain_throughput()) is rewritten to produce much more consistent delays
when under constant load. The new write throttle is based on the amount of
dirty data, rather than guesses about future performance of the system. When
there is a lot of dirty data, each transaction (e.g. write() syscall) will be
delayed by the same small amount. This eliminates the "brick wall of wait"
that the old write throttle could hit, causing all transactions to wait several
seconds until the next txg opens. One of the keys to the new write throttle is
decrementing the amount of dirty data as i/o completes, rather than at the end
of spa_sync(). Note that the write throttle is only applied once the i/o
scheduler is issuing the maximum number of outstanding async writes. See the
block comments in dsl_pool.c and above dmu_tx_delay() (reproduced below) for
more details.
This diff has several other effects, including:
* the commonly-tuned global variable zfs_vdev_max_pending has been removed;
use per-class zfs_vdev_*_max_active values or zfs_vdev_max_active instead.
* the size of each txg (meaning the amount of dirty data written, and thus the
time it takes to write out) is now controlled differently. There is no longer
an explicit time goal; the primary determinant is amount of dirty data.
Systems that are under light or medium load will now often see that a txg is
always syncing, but the impact to performance (e.g. read latency) is minimal.
Tune zfs_dirty_data_max and zfs_dirty_data_sync to control this.
* zio_taskq_batch_pct = 75 -- Only use 75% of all CPUs for compression,
checksum, etc. This improves latency by not allowing these CPU-intensive tasks
to consume all CPU (on machines with at least 4 CPU's; the percentage is
rounded up).
--matt
APPENDIX: problems with the current i/o scheduler
The current ZFS i/o scheduler (vdev_queue.c) is deadline based. The problem
with this is that if there are always i/os pending, then certain classes of
i/os can see very long delays.
For example, if there are always synchronous reads outstanding, then no async
writes will be serviced until they become "past due". One symptom of this
situation is that each pass of the txg sync takes at least several seconds
(typically 3 seconds).
If many i/os become "past due" (their deadline is in the past), then we must
service all of these overdue i/os before any new i/os. This happens when we
enqueue a batch of async writes for the txg sync, with deadlines 2.5 seconds in
the future. If we can't complete all the i/os in 2.5 seconds (e.g. because
there were always reads pending), then these i/os will become past due. Now we
must service all the "async" writes (which could be hundreds of megabytes)
before we service any reads, introducing considerable latency to synchronous
i/os (reads or ZIL writes).
Notes on porting to ZFS on Linux:
- zio_t gained new members io_physdone and io_phys_children. Because
object caches in the Linux port call the constructor only once at
allocation time, objects may contain residual data when retrieved
from the cache. Therefore zio_create() was updated to zero out the two
new fields.
- vdev_mirror_pending() relied on the depth of the per-vdev pending queue
(vq->vq_pending_tree) to select the least-busy leaf vdev to read from.
This tree has been replaced by vq->vq_active_tree which is now used
for the same purpose.
- vdev_queue_init() used the value of zfs_vdev_max_pending to determine
the number of vdev I/O buffers to pre-allocate. That global no longer
exists, so we instead use the sum of the *_max_active values for each of
the five I/O classes described above.
- The Illumos implementation of dmu_tx_delay() delays a transaction by
sleeping in condition variable embedded in the thread
(curthread->t_delay_cv). We do not have an equivalent CV to use in
Linux, so this change replaced the delay logic with a wrapper called
zfs_sleep_until(). This wrapper could be adopted upstream and in other
downstream ports to abstract away operating system-specific delay logic.
- These tunables are added as module parameters, and descriptions added
to the zfs-module-parameters.5 man page.
spa_asize_inflation
zfs_deadman_synctime_ms
zfs_vdev_max_active
zfs_vdev_async_write_active_min_dirty_percent
zfs_vdev_async_write_active_max_dirty_percent
zfs_vdev_async_read_max_active
zfs_vdev_async_read_min_active
zfs_vdev_async_write_max_active
zfs_vdev_async_write_min_active
zfs_vdev_scrub_max_active
zfs_vdev_scrub_min_active
zfs_vdev_sync_read_max_active
zfs_vdev_sync_read_min_active
zfs_vdev_sync_write_max_active
zfs_vdev_sync_write_min_active
zfs_dirty_data_max_percent
zfs_delay_min_dirty_percent
zfs_dirty_data_max_max_percent
zfs_dirty_data_max
zfs_dirty_data_max_max
zfs_dirty_data_sync
zfs_delay_scale
The latter four have type unsigned long, whereas they are uint64_t in
Illumos. This accommodates Linux's module_param() supported types, but
means they may overflow on 32-bit architectures.
The values zfs_dirty_data_max and zfs_dirty_data_max_max are the most
likely to overflow on 32-bit systems, since they express physical RAM
sizes in bytes. In fact, Illumos initializes zfs_dirty_data_max_max to
2^32 which does overflow. To resolve that, this port instead initializes
it in arc_init() to 25% of physical RAM, and adds the tunable
zfs_dirty_data_max_max_percent to override that percentage. While this
solution doesn't completely avoid the overflow issue, it should be a
reasonable default for most systems, and the minority of affected
systems can work around the issue by overriding the defaults.
- Fixed reversed logic in comment above zfs_delay_scale declaration.
- Clarified comments in vdev_queue.c regarding when per-queue minimums take
effect.
- Replaced dmu_tx_write_limit in the dmu_tx kstat file
with dmu_tx_dirty_delay and dmu_tx_dirty_over_max. The first counts
how many times a transaction has been delayed because the pool dirty
data has exceeded zfs_delay_min_dirty_percent. The latter counts how
many times the pool dirty data has exceeded zfs_dirty_data_max (which
we expect to never happen).
- The original patch would have regressed the bug fixed in
zfsonlinux/zfs@c418410, which prevented users from setting the
zfs_vdev_aggregation_limit tuning larger than SPA_MAXBLOCKSIZE.
A similar fix is added to vdev_queue_aggregate().
- In vdev_queue_io_to_issue(), dynamically allocate 'zio_t search' on the
heap instead of the stack. In Linux we can't afford such large
structures on the stack.
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Reviewed by: Ned Bass <bass6@llnl.gov>
Reviewed by: Brendan Gregg <brendan.gregg@joyent.com>
Approved by: Robert Mustacchi <rm@joyent.com>
References:
http://www.illumos.org/issues/4045
illumos/illumos-gate@69962b5647e4a8b9b14998733b765925381b727e
Ported-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1913
2013-08-29 03:01:20 +00:00
|
|
|
See the section "ZFS I/O SCHEDULER".
|
|
|
|
.sp
|
|
|
|
Default value: \fB3\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_async_read_min_active\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Minimum asynchronous read I/Os active to each device.
|
|
|
|
See the section "ZFS I/O SCHEDULER".
|
|
|
|
.sp
|
|
|
|
Default value: \fB1\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_async_write_active_max_dirty_percent\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
When the pool has more than
|
|
|
|
\fBzfs_vdev_async_write_active_max_dirty_percent\fR dirty data, use
|
|
|
|
\fBzfs_vdev_async_write_max_active\fR to limit active async writes. If
|
|
|
|
the dirty data is between min and max, the active I/O limit is linearly
|
|
|
|
interpolated. See the section "ZFS I/O SCHEDULER".
|
|
|
|
.sp
|
|
|
|
Default value: \fB60\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_async_write_active_min_dirty_percent\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
When the pool has less than
|
|
|
|
\fBzfs_vdev_async_write_active_min_dirty_percent\fR dirty data, use
|
|
|
|
\fBzfs_vdev_async_write_min_active\fR to limit active async writes. If
|
|
|
|
the dirty data is between min and max, the active I/O limit is linearly
|
|
|
|
interpolated. See the section "ZFS I/O SCHEDULER".
|
|
|
|
.sp
|
|
|
|
Default value: \fB30\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_async_write_max_active\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Maximum asynchronous write I/Os active to each device.
|
Illumos #4045 write throttle & i/o scheduler performance work
4045 zfs write throttle & i/o scheduler performance work
1. The ZFS i/o scheduler (vdev_queue.c) now divides i/os into 5 classes: sync
read, sync write, async read, async write, and scrub/resilver. The scheduler
issues a number of concurrent i/os from each class to the device. Once a class
has been selected, an i/o is selected from this class using either an elevator
algorithem (async, scrub classes) or FIFO (sync classes). The number of
concurrent async write i/os is tuned dynamically based on i/o load, to achieve
good sync i/o latency when there is not a high load of writes, and good write
throughput when there is. See the block comment in vdev_queue.c (reproduced
below) for more details.
2. The write throttle (dsl_pool_tempreserve_space() and
txg_constrain_throughput()) is rewritten to produce much more consistent delays
when under constant load. The new write throttle is based on the amount of
dirty data, rather than guesses about future performance of the system. When
there is a lot of dirty data, each transaction (e.g. write() syscall) will be
delayed by the same small amount. This eliminates the "brick wall of wait"
that the old write throttle could hit, causing all transactions to wait several
seconds until the next txg opens. One of the keys to the new write throttle is
decrementing the amount of dirty data as i/o completes, rather than at the end
of spa_sync(). Note that the write throttle is only applied once the i/o
scheduler is issuing the maximum number of outstanding async writes. See the
block comments in dsl_pool.c and above dmu_tx_delay() (reproduced below) for
more details.
This diff has several other effects, including:
* the commonly-tuned global variable zfs_vdev_max_pending has been removed;
use per-class zfs_vdev_*_max_active values or zfs_vdev_max_active instead.
* the size of each txg (meaning the amount of dirty data written, and thus the
time it takes to write out) is now controlled differently. There is no longer
an explicit time goal; the primary determinant is amount of dirty data.
Systems that are under light or medium load will now often see that a txg is
always syncing, but the impact to performance (e.g. read latency) is minimal.
Tune zfs_dirty_data_max and zfs_dirty_data_sync to control this.
* zio_taskq_batch_pct = 75 -- Only use 75% of all CPUs for compression,
checksum, etc. This improves latency by not allowing these CPU-intensive tasks
to consume all CPU (on machines with at least 4 CPU's; the percentage is
rounded up).
--matt
APPENDIX: problems with the current i/o scheduler
The current ZFS i/o scheduler (vdev_queue.c) is deadline based. The problem
with this is that if there are always i/os pending, then certain classes of
i/os can see very long delays.
For example, if there are always synchronous reads outstanding, then no async
writes will be serviced until they become "past due". One symptom of this
situation is that each pass of the txg sync takes at least several seconds
(typically 3 seconds).
If many i/os become "past due" (their deadline is in the past), then we must
service all of these overdue i/os before any new i/os. This happens when we
enqueue a batch of async writes for the txg sync, with deadlines 2.5 seconds in
the future. If we can't complete all the i/os in 2.5 seconds (e.g. because
there were always reads pending), then these i/os will become past due. Now we
must service all the "async" writes (which could be hundreds of megabytes)
before we service any reads, introducing considerable latency to synchronous
i/os (reads or ZIL writes).
Notes on porting to ZFS on Linux:
- zio_t gained new members io_physdone and io_phys_children. Because
object caches in the Linux port call the constructor only once at
allocation time, objects may contain residual data when retrieved
from the cache. Therefore zio_create() was updated to zero out the two
new fields.
- vdev_mirror_pending() relied on the depth of the per-vdev pending queue
(vq->vq_pending_tree) to select the least-busy leaf vdev to read from.
This tree has been replaced by vq->vq_active_tree which is now used
for the same purpose.
- vdev_queue_init() used the value of zfs_vdev_max_pending to determine
the number of vdev I/O buffers to pre-allocate. That global no longer
exists, so we instead use the sum of the *_max_active values for each of
the five I/O classes described above.
- The Illumos implementation of dmu_tx_delay() delays a transaction by
sleeping in condition variable embedded in the thread
(curthread->t_delay_cv). We do not have an equivalent CV to use in
Linux, so this change replaced the delay logic with a wrapper called
zfs_sleep_until(). This wrapper could be adopted upstream and in other
downstream ports to abstract away operating system-specific delay logic.
- These tunables are added as module parameters, and descriptions added
to the zfs-module-parameters.5 man page.
spa_asize_inflation
zfs_deadman_synctime_ms
zfs_vdev_max_active
zfs_vdev_async_write_active_min_dirty_percent
zfs_vdev_async_write_active_max_dirty_percent
zfs_vdev_async_read_max_active
zfs_vdev_async_read_min_active
zfs_vdev_async_write_max_active
zfs_vdev_async_write_min_active
zfs_vdev_scrub_max_active
zfs_vdev_scrub_min_active
zfs_vdev_sync_read_max_active
zfs_vdev_sync_read_min_active
zfs_vdev_sync_write_max_active
zfs_vdev_sync_write_min_active
zfs_dirty_data_max_percent
zfs_delay_min_dirty_percent
zfs_dirty_data_max_max_percent
zfs_dirty_data_max
zfs_dirty_data_max_max
zfs_dirty_data_sync
zfs_delay_scale
The latter four have type unsigned long, whereas they are uint64_t in
Illumos. This accommodates Linux's module_param() supported types, but
means they may overflow on 32-bit architectures.
The values zfs_dirty_data_max and zfs_dirty_data_max_max are the most
likely to overflow on 32-bit systems, since they express physical RAM
sizes in bytes. In fact, Illumos initializes zfs_dirty_data_max_max to
2^32 which does overflow. To resolve that, this port instead initializes
it in arc_init() to 25% of physical RAM, and adds the tunable
zfs_dirty_data_max_max_percent to override that percentage. While this
solution doesn't completely avoid the overflow issue, it should be a
reasonable default for most systems, and the minority of affected
systems can work around the issue by overriding the defaults.
- Fixed reversed logic in comment above zfs_delay_scale declaration.
- Clarified comments in vdev_queue.c regarding when per-queue minimums take
effect.
- Replaced dmu_tx_write_limit in the dmu_tx kstat file
with dmu_tx_dirty_delay and dmu_tx_dirty_over_max. The first counts
how many times a transaction has been delayed because the pool dirty
data has exceeded zfs_delay_min_dirty_percent. The latter counts how
many times the pool dirty data has exceeded zfs_dirty_data_max (which
we expect to never happen).
- The original patch would have regressed the bug fixed in
zfsonlinux/zfs@c418410, which prevented users from setting the
zfs_vdev_aggregation_limit tuning larger than SPA_MAXBLOCKSIZE.
A similar fix is added to vdev_queue_aggregate().
- In vdev_queue_io_to_issue(), dynamically allocate 'zio_t search' on the
heap instead of the stack. In Linux we can't afford such large
structures on the stack.
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Reviewed by: Ned Bass <bass6@llnl.gov>
Reviewed by: Brendan Gregg <brendan.gregg@joyent.com>
Approved by: Robert Mustacchi <rm@joyent.com>
References:
http://www.illumos.org/issues/4045
illumos/illumos-gate@69962b5647e4a8b9b14998733b765925381b727e
Ported-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1913
2013-08-29 03:01:20 +00:00
|
|
|
See the section "ZFS I/O SCHEDULER".
|
|
|
|
.sp
|
|
|
|
Default value: \fB10\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_async_write_min_active\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Minimum asynchronous write I/Os active to each device.
|
|
|
|
See the section "ZFS I/O SCHEDULER".
|
|
|
|
.sp
|
|
|
|
Default value: \fB1\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_max_active\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
The maximum number of I/Os active to each device. Ideally, this will be >=
|
|
|
|
the sum of each queue's max_active. It must be at least the sum of each
|
|
|
|
queue's min_active. See the section "ZFS I/O SCHEDULER".
|
|
|
|
.sp
|
|
|
|
Default value: \fB1,000\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_scrub_max_active\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Maximum scrub I/Os active to each device.
|
Illumos #4045 write throttle & i/o scheduler performance work
4045 zfs write throttle & i/o scheduler performance work
1. The ZFS i/o scheduler (vdev_queue.c) now divides i/os into 5 classes: sync
read, sync write, async read, async write, and scrub/resilver. The scheduler
issues a number of concurrent i/os from each class to the device. Once a class
has been selected, an i/o is selected from this class using either an elevator
algorithem (async, scrub classes) or FIFO (sync classes). The number of
concurrent async write i/os is tuned dynamically based on i/o load, to achieve
good sync i/o latency when there is not a high load of writes, and good write
throughput when there is. See the block comment in vdev_queue.c (reproduced
below) for more details.
2. The write throttle (dsl_pool_tempreserve_space() and
txg_constrain_throughput()) is rewritten to produce much more consistent delays
when under constant load. The new write throttle is based on the amount of
dirty data, rather than guesses about future performance of the system. When
there is a lot of dirty data, each transaction (e.g. write() syscall) will be
delayed by the same small amount. This eliminates the "brick wall of wait"
that the old write throttle could hit, causing all transactions to wait several
seconds until the next txg opens. One of the keys to the new write throttle is
decrementing the amount of dirty data as i/o completes, rather than at the end
of spa_sync(). Note that the write throttle is only applied once the i/o
scheduler is issuing the maximum number of outstanding async writes. See the
block comments in dsl_pool.c and above dmu_tx_delay() (reproduced below) for
more details.
This diff has several other effects, including:
* the commonly-tuned global variable zfs_vdev_max_pending has been removed;
use per-class zfs_vdev_*_max_active values or zfs_vdev_max_active instead.
* the size of each txg (meaning the amount of dirty data written, and thus the
time it takes to write out) is now controlled differently. There is no longer
an explicit time goal; the primary determinant is amount of dirty data.
Systems that are under light or medium load will now often see that a txg is
always syncing, but the impact to performance (e.g. read latency) is minimal.
Tune zfs_dirty_data_max and zfs_dirty_data_sync to control this.
* zio_taskq_batch_pct = 75 -- Only use 75% of all CPUs for compression,
checksum, etc. This improves latency by not allowing these CPU-intensive tasks
to consume all CPU (on machines with at least 4 CPU's; the percentage is
rounded up).
--matt
APPENDIX: problems with the current i/o scheduler
The current ZFS i/o scheduler (vdev_queue.c) is deadline based. The problem
with this is that if there are always i/os pending, then certain classes of
i/os can see very long delays.
For example, if there are always synchronous reads outstanding, then no async
writes will be serviced until they become "past due". One symptom of this
situation is that each pass of the txg sync takes at least several seconds
(typically 3 seconds).
If many i/os become "past due" (their deadline is in the past), then we must
service all of these overdue i/os before any new i/os. This happens when we
enqueue a batch of async writes for the txg sync, with deadlines 2.5 seconds in
the future. If we can't complete all the i/os in 2.5 seconds (e.g. because
there were always reads pending), then these i/os will become past due. Now we
must service all the "async" writes (which could be hundreds of megabytes)
before we service any reads, introducing considerable latency to synchronous
i/os (reads or ZIL writes).
Notes on porting to ZFS on Linux:
- zio_t gained new members io_physdone and io_phys_children. Because
object caches in the Linux port call the constructor only once at
allocation time, objects may contain residual data when retrieved
from the cache. Therefore zio_create() was updated to zero out the two
new fields.
- vdev_mirror_pending() relied on the depth of the per-vdev pending queue
(vq->vq_pending_tree) to select the least-busy leaf vdev to read from.
This tree has been replaced by vq->vq_active_tree which is now used
for the same purpose.
- vdev_queue_init() used the value of zfs_vdev_max_pending to determine
the number of vdev I/O buffers to pre-allocate. That global no longer
exists, so we instead use the sum of the *_max_active values for each of
the five I/O classes described above.
- The Illumos implementation of dmu_tx_delay() delays a transaction by
sleeping in condition variable embedded in the thread
(curthread->t_delay_cv). We do not have an equivalent CV to use in
Linux, so this change replaced the delay logic with a wrapper called
zfs_sleep_until(). This wrapper could be adopted upstream and in other
downstream ports to abstract away operating system-specific delay logic.
- These tunables are added as module parameters, and descriptions added
to the zfs-module-parameters.5 man page.
spa_asize_inflation
zfs_deadman_synctime_ms
zfs_vdev_max_active
zfs_vdev_async_write_active_min_dirty_percent
zfs_vdev_async_write_active_max_dirty_percent
zfs_vdev_async_read_max_active
zfs_vdev_async_read_min_active
zfs_vdev_async_write_max_active
zfs_vdev_async_write_min_active
zfs_vdev_scrub_max_active
zfs_vdev_scrub_min_active
zfs_vdev_sync_read_max_active
zfs_vdev_sync_read_min_active
zfs_vdev_sync_write_max_active
zfs_vdev_sync_write_min_active
zfs_dirty_data_max_percent
zfs_delay_min_dirty_percent
zfs_dirty_data_max_max_percent
zfs_dirty_data_max
zfs_dirty_data_max_max
zfs_dirty_data_sync
zfs_delay_scale
The latter four have type unsigned long, whereas they are uint64_t in
Illumos. This accommodates Linux's module_param() supported types, but
means they may overflow on 32-bit architectures.
The values zfs_dirty_data_max and zfs_dirty_data_max_max are the most
likely to overflow on 32-bit systems, since they express physical RAM
sizes in bytes. In fact, Illumos initializes zfs_dirty_data_max_max to
2^32 which does overflow. To resolve that, this port instead initializes
it in arc_init() to 25% of physical RAM, and adds the tunable
zfs_dirty_data_max_max_percent to override that percentage. While this
solution doesn't completely avoid the overflow issue, it should be a
reasonable default for most systems, and the minority of affected
systems can work around the issue by overriding the defaults.
- Fixed reversed logic in comment above zfs_delay_scale declaration.
- Clarified comments in vdev_queue.c regarding when per-queue minimums take
effect.
- Replaced dmu_tx_write_limit in the dmu_tx kstat file
with dmu_tx_dirty_delay and dmu_tx_dirty_over_max. The first counts
how many times a transaction has been delayed because the pool dirty
data has exceeded zfs_delay_min_dirty_percent. The latter counts how
many times the pool dirty data has exceeded zfs_dirty_data_max (which
we expect to never happen).
- The original patch would have regressed the bug fixed in
zfsonlinux/zfs@c418410, which prevented users from setting the
zfs_vdev_aggregation_limit tuning larger than SPA_MAXBLOCKSIZE.
A similar fix is added to vdev_queue_aggregate().
- In vdev_queue_io_to_issue(), dynamically allocate 'zio_t search' on the
heap instead of the stack. In Linux we can't afford such large
structures on the stack.
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Reviewed by: Ned Bass <bass6@llnl.gov>
Reviewed by: Brendan Gregg <brendan.gregg@joyent.com>
Approved by: Robert Mustacchi <rm@joyent.com>
References:
http://www.illumos.org/issues/4045
illumos/illumos-gate@69962b5647e4a8b9b14998733b765925381b727e
Ported-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1913
2013-08-29 03:01:20 +00:00
|
|
|
See the section "ZFS I/O SCHEDULER".
|
|
|
|
.sp
|
|
|
|
Default value: \fB2\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_scrub_min_active\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Minimum scrub I/Os active to each device.
|
|
|
|
See the section "ZFS I/O SCHEDULER".
|
|
|
|
.sp
|
|
|
|
Default value: \fB1\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_sync_read_max_active\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Maximum synchronous read I/Os active to each device.
|
Illumos #4045 write throttle & i/o scheduler performance work
4045 zfs write throttle & i/o scheduler performance work
1. The ZFS i/o scheduler (vdev_queue.c) now divides i/os into 5 classes: sync
read, sync write, async read, async write, and scrub/resilver. The scheduler
issues a number of concurrent i/os from each class to the device. Once a class
has been selected, an i/o is selected from this class using either an elevator
algorithem (async, scrub classes) or FIFO (sync classes). The number of
concurrent async write i/os is tuned dynamically based on i/o load, to achieve
good sync i/o latency when there is not a high load of writes, and good write
throughput when there is. See the block comment in vdev_queue.c (reproduced
below) for more details.
2. The write throttle (dsl_pool_tempreserve_space() and
txg_constrain_throughput()) is rewritten to produce much more consistent delays
when under constant load. The new write throttle is based on the amount of
dirty data, rather than guesses about future performance of the system. When
there is a lot of dirty data, each transaction (e.g. write() syscall) will be
delayed by the same small amount. This eliminates the "brick wall of wait"
that the old write throttle could hit, causing all transactions to wait several
seconds until the next txg opens. One of the keys to the new write throttle is
decrementing the amount of dirty data as i/o completes, rather than at the end
of spa_sync(). Note that the write throttle is only applied once the i/o
scheduler is issuing the maximum number of outstanding async writes. See the
block comments in dsl_pool.c and above dmu_tx_delay() (reproduced below) for
more details.
This diff has several other effects, including:
* the commonly-tuned global variable zfs_vdev_max_pending has been removed;
use per-class zfs_vdev_*_max_active values or zfs_vdev_max_active instead.
* the size of each txg (meaning the amount of dirty data written, and thus the
time it takes to write out) is now controlled differently. There is no longer
an explicit time goal; the primary determinant is amount of dirty data.
Systems that are under light or medium load will now often see that a txg is
always syncing, but the impact to performance (e.g. read latency) is minimal.
Tune zfs_dirty_data_max and zfs_dirty_data_sync to control this.
* zio_taskq_batch_pct = 75 -- Only use 75% of all CPUs for compression,
checksum, etc. This improves latency by not allowing these CPU-intensive tasks
to consume all CPU (on machines with at least 4 CPU's; the percentage is
rounded up).
--matt
APPENDIX: problems with the current i/o scheduler
The current ZFS i/o scheduler (vdev_queue.c) is deadline based. The problem
with this is that if there are always i/os pending, then certain classes of
i/os can see very long delays.
For example, if there are always synchronous reads outstanding, then no async
writes will be serviced until they become "past due". One symptom of this
situation is that each pass of the txg sync takes at least several seconds
(typically 3 seconds).
If many i/os become "past due" (their deadline is in the past), then we must
service all of these overdue i/os before any new i/os. This happens when we
enqueue a batch of async writes for the txg sync, with deadlines 2.5 seconds in
the future. If we can't complete all the i/os in 2.5 seconds (e.g. because
there were always reads pending), then these i/os will become past due. Now we
must service all the "async" writes (which could be hundreds of megabytes)
before we service any reads, introducing considerable latency to synchronous
i/os (reads or ZIL writes).
Notes on porting to ZFS on Linux:
- zio_t gained new members io_physdone and io_phys_children. Because
object caches in the Linux port call the constructor only once at
allocation time, objects may contain residual data when retrieved
from the cache. Therefore zio_create() was updated to zero out the two
new fields.
- vdev_mirror_pending() relied on the depth of the per-vdev pending queue
(vq->vq_pending_tree) to select the least-busy leaf vdev to read from.
This tree has been replaced by vq->vq_active_tree which is now used
for the same purpose.
- vdev_queue_init() used the value of zfs_vdev_max_pending to determine
the number of vdev I/O buffers to pre-allocate. That global no longer
exists, so we instead use the sum of the *_max_active values for each of
the five I/O classes described above.
- The Illumos implementation of dmu_tx_delay() delays a transaction by
sleeping in condition variable embedded in the thread
(curthread->t_delay_cv). We do not have an equivalent CV to use in
Linux, so this change replaced the delay logic with a wrapper called
zfs_sleep_until(). This wrapper could be adopted upstream and in other
downstream ports to abstract away operating system-specific delay logic.
- These tunables are added as module parameters, and descriptions added
to the zfs-module-parameters.5 man page.
spa_asize_inflation
zfs_deadman_synctime_ms
zfs_vdev_max_active
zfs_vdev_async_write_active_min_dirty_percent
zfs_vdev_async_write_active_max_dirty_percent
zfs_vdev_async_read_max_active
zfs_vdev_async_read_min_active
zfs_vdev_async_write_max_active
zfs_vdev_async_write_min_active
zfs_vdev_scrub_max_active
zfs_vdev_scrub_min_active
zfs_vdev_sync_read_max_active
zfs_vdev_sync_read_min_active
zfs_vdev_sync_write_max_active
zfs_vdev_sync_write_min_active
zfs_dirty_data_max_percent
zfs_delay_min_dirty_percent
zfs_dirty_data_max_max_percent
zfs_dirty_data_max
zfs_dirty_data_max_max
zfs_dirty_data_sync
zfs_delay_scale
The latter four have type unsigned long, whereas they are uint64_t in
Illumos. This accommodates Linux's module_param() supported types, but
means they may overflow on 32-bit architectures.
The values zfs_dirty_data_max and zfs_dirty_data_max_max are the most
likely to overflow on 32-bit systems, since they express physical RAM
sizes in bytes. In fact, Illumos initializes zfs_dirty_data_max_max to
2^32 which does overflow. To resolve that, this port instead initializes
it in arc_init() to 25% of physical RAM, and adds the tunable
zfs_dirty_data_max_max_percent to override that percentage. While this
solution doesn't completely avoid the overflow issue, it should be a
reasonable default for most systems, and the minority of affected
systems can work around the issue by overriding the defaults.
- Fixed reversed logic in comment above zfs_delay_scale declaration.
- Clarified comments in vdev_queue.c regarding when per-queue minimums take
effect.
- Replaced dmu_tx_write_limit in the dmu_tx kstat file
with dmu_tx_dirty_delay and dmu_tx_dirty_over_max. The first counts
how many times a transaction has been delayed because the pool dirty
data has exceeded zfs_delay_min_dirty_percent. The latter counts how
many times the pool dirty data has exceeded zfs_dirty_data_max (which
we expect to never happen).
- The original patch would have regressed the bug fixed in
zfsonlinux/zfs@c418410, which prevented users from setting the
zfs_vdev_aggregation_limit tuning larger than SPA_MAXBLOCKSIZE.
A similar fix is added to vdev_queue_aggregate().
- In vdev_queue_io_to_issue(), dynamically allocate 'zio_t search' on the
heap instead of the stack. In Linux we can't afford such large
structures on the stack.
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Reviewed by: Ned Bass <bass6@llnl.gov>
Reviewed by: Brendan Gregg <brendan.gregg@joyent.com>
Approved by: Robert Mustacchi <rm@joyent.com>
References:
http://www.illumos.org/issues/4045
illumos/illumos-gate@69962b5647e4a8b9b14998733b765925381b727e
Ported-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1913
2013-08-29 03:01:20 +00:00
|
|
|
See the section "ZFS I/O SCHEDULER".
|
|
|
|
.sp
|
|
|
|
Default value: \fB10\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_sync_read_min_active\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Minimum synchronous read I/Os active to each device.
|
|
|
|
See the section "ZFS I/O SCHEDULER".
|
|
|
|
.sp
|
|
|
|
Default value: \fB10\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_sync_write_max_active\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Maximum synchronous write I/Os active to each device.
|
Illumos #4045 write throttle & i/o scheduler performance work
4045 zfs write throttle & i/o scheduler performance work
1. The ZFS i/o scheduler (vdev_queue.c) now divides i/os into 5 classes: sync
read, sync write, async read, async write, and scrub/resilver. The scheduler
issues a number of concurrent i/os from each class to the device. Once a class
has been selected, an i/o is selected from this class using either an elevator
algorithem (async, scrub classes) or FIFO (sync classes). The number of
concurrent async write i/os is tuned dynamically based on i/o load, to achieve
good sync i/o latency when there is not a high load of writes, and good write
throughput when there is. See the block comment in vdev_queue.c (reproduced
below) for more details.
2. The write throttle (dsl_pool_tempreserve_space() and
txg_constrain_throughput()) is rewritten to produce much more consistent delays
when under constant load. The new write throttle is based on the amount of
dirty data, rather than guesses about future performance of the system. When
there is a lot of dirty data, each transaction (e.g. write() syscall) will be
delayed by the same small amount. This eliminates the "brick wall of wait"
that the old write throttle could hit, causing all transactions to wait several
seconds until the next txg opens. One of the keys to the new write throttle is
decrementing the amount of dirty data as i/o completes, rather than at the end
of spa_sync(). Note that the write throttle is only applied once the i/o
scheduler is issuing the maximum number of outstanding async writes. See the
block comments in dsl_pool.c and above dmu_tx_delay() (reproduced below) for
more details.
This diff has several other effects, including:
* the commonly-tuned global variable zfs_vdev_max_pending has been removed;
use per-class zfs_vdev_*_max_active values or zfs_vdev_max_active instead.
* the size of each txg (meaning the amount of dirty data written, and thus the
time it takes to write out) is now controlled differently. There is no longer
an explicit time goal; the primary determinant is amount of dirty data.
Systems that are under light or medium load will now often see that a txg is
always syncing, but the impact to performance (e.g. read latency) is minimal.
Tune zfs_dirty_data_max and zfs_dirty_data_sync to control this.
* zio_taskq_batch_pct = 75 -- Only use 75% of all CPUs for compression,
checksum, etc. This improves latency by not allowing these CPU-intensive tasks
to consume all CPU (on machines with at least 4 CPU's; the percentage is
rounded up).
--matt
APPENDIX: problems with the current i/o scheduler
The current ZFS i/o scheduler (vdev_queue.c) is deadline based. The problem
with this is that if there are always i/os pending, then certain classes of
i/os can see very long delays.
For example, if there are always synchronous reads outstanding, then no async
writes will be serviced until they become "past due". One symptom of this
situation is that each pass of the txg sync takes at least several seconds
(typically 3 seconds).
If many i/os become "past due" (their deadline is in the past), then we must
service all of these overdue i/os before any new i/os. This happens when we
enqueue a batch of async writes for the txg sync, with deadlines 2.5 seconds in
the future. If we can't complete all the i/os in 2.5 seconds (e.g. because
there were always reads pending), then these i/os will become past due. Now we
must service all the "async" writes (which could be hundreds of megabytes)
before we service any reads, introducing considerable latency to synchronous
i/os (reads or ZIL writes).
Notes on porting to ZFS on Linux:
- zio_t gained new members io_physdone and io_phys_children. Because
object caches in the Linux port call the constructor only once at
allocation time, objects may contain residual data when retrieved
from the cache. Therefore zio_create() was updated to zero out the two
new fields.
- vdev_mirror_pending() relied on the depth of the per-vdev pending queue
(vq->vq_pending_tree) to select the least-busy leaf vdev to read from.
This tree has been replaced by vq->vq_active_tree which is now used
for the same purpose.
- vdev_queue_init() used the value of zfs_vdev_max_pending to determine
the number of vdev I/O buffers to pre-allocate. That global no longer
exists, so we instead use the sum of the *_max_active values for each of
the five I/O classes described above.
- The Illumos implementation of dmu_tx_delay() delays a transaction by
sleeping in condition variable embedded in the thread
(curthread->t_delay_cv). We do not have an equivalent CV to use in
Linux, so this change replaced the delay logic with a wrapper called
zfs_sleep_until(). This wrapper could be adopted upstream and in other
downstream ports to abstract away operating system-specific delay logic.
- These tunables are added as module parameters, and descriptions added
to the zfs-module-parameters.5 man page.
spa_asize_inflation
zfs_deadman_synctime_ms
zfs_vdev_max_active
zfs_vdev_async_write_active_min_dirty_percent
zfs_vdev_async_write_active_max_dirty_percent
zfs_vdev_async_read_max_active
zfs_vdev_async_read_min_active
zfs_vdev_async_write_max_active
zfs_vdev_async_write_min_active
zfs_vdev_scrub_max_active
zfs_vdev_scrub_min_active
zfs_vdev_sync_read_max_active
zfs_vdev_sync_read_min_active
zfs_vdev_sync_write_max_active
zfs_vdev_sync_write_min_active
zfs_dirty_data_max_percent
zfs_delay_min_dirty_percent
zfs_dirty_data_max_max_percent
zfs_dirty_data_max
zfs_dirty_data_max_max
zfs_dirty_data_sync
zfs_delay_scale
The latter four have type unsigned long, whereas they are uint64_t in
Illumos. This accommodates Linux's module_param() supported types, but
means they may overflow on 32-bit architectures.
The values zfs_dirty_data_max and zfs_dirty_data_max_max are the most
likely to overflow on 32-bit systems, since they express physical RAM
sizes in bytes. In fact, Illumos initializes zfs_dirty_data_max_max to
2^32 which does overflow. To resolve that, this port instead initializes
it in arc_init() to 25% of physical RAM, and adds the tunable
zfs_dirty_data_max_max_percent to override that percentage. While this
solution doesn't completely avoid the overflow issue, it should be a
reasonable default for most systems, and the minority of affected
systems can work around the issue by overriding the defaults.
- Fixed reversed logic in comment above zfs_delay_scale declaration.
- Clarified comments in vdev_queue.c regarding when per-queue minimums take
effect.
- Replaced dmu_tx_write_limit in the dmu_tx kstat file
with dmu_tx_dirty_delay and dmu_tx_dirty_over_max. The first counts
how many times a transaction has been delayed because the pool dirty
data has exceeded zfs_delay_min_dirty_percent. The latter counts how
many times the pool dirty data has exceeded zfs_dirty_data_max (which
we expect to never happen).
- The original patch would have regressed the bug fixed in
zfsonlinux/zfs@c418410, which prevented users from setting the
zfs_vdev_aggregation_limit tuning larger than SPA_MAXBLOCKSIZE.
A similar fix is added to vdev_queue_aggregate().
- In vdev_queue_io_to_issue(), dynamically allocate 'zio_t search' on the
heap instead of the stack. In Linux we can't afford such large
structures on the stack.
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Reviewed by: Ned Bass <bass6@llnl.gov>
Reviewed by: Brendan Gregg <brendan.gregg@joyent.com>
Approved by: Robert Mustacchi <rm@joyent.com>
References:
http://www.illumos.org/issues/4045
illumos/illumos-gate@69962b5647e4a8b9b14998733b765925381b727e
Ported-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1913
2013-08-29 03:01:20 +00:00
|
|
|
See the section "ZFS I/O SCHEDULER".
|
|
|
|
.sp
|
|
|
|
Default value: \fB10\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_sync_write_min_active\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Minimum synchronous write I/Os active to each device.
|
|
|
|
See the section "ZFS I/O SCHEDULER".
|
|
|
|
.sp
|
|
|
|
Default value: \fB10\fR.
|
|
|
|
.RE
|
|
|
|
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_disable_dup_eviction\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Disable duplicate buffer eviction
|
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes and \fB0\fR for no (default).
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_expire_snapshot\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Seconds to expire .zfs/snapshot
|
|
|
|
.sp
|
|
|
|
Default value: \fB300\fR.
|
|
|
|
.RE
|
|
|
|
|
2015-08-28 21:54:32 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_admin_snapshot\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Allow the creation, removal, or renaming of entries in the .zfs/snapshot
|
|
|
|
directory to cause the creation, destruction, or renaming of snapshots.
|
|
|
|
When enabled this functionality works both locally and over NFS exports
|
|
|
|
which have the 'no_root_squash' option set. This functionality is disabled
|
|
|
|
by default.
|
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes and \fB0\fR for no (default).
|
|
|
|
.RE
|
|
|
|
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_flags\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2014-12-23 00:54:43 +00:00
|
|
|
Set additional debugging flags. The following flags may be bitwise-or'd
|
|
|
|
together.
|
|
|
|
.sp
|
|
|
|
.TS
|
|
|
|
box;
|
|
|
|
rB lB
|
|
|
|
lB lB
|
|
|
|
r l.
|
|
|
|
Value Symbolic Name
|
|
|
|
Description
|
|
|
|
_
|
|
|
|
1 ZFS_DEBUG_DPRINTF
|
|
|
|
Enable dprintf entries in the debug log.
|
|
|
|
_
|
|
|
|
2 ZFS_DEBUG_DBUF_VERIFY *
|
|
|
|
Enable extra dbuf verifications.
|
|
|
|
_
|
|
|
|
4 ZFS_DEBUG_DNODE_VERIFY *
|
|
|
|
Enable extra dnode verifications.
|
|
|
|
_
|
|
|
|
8 ZFS_DEBUG_SNAPNAMES
|
|
|
|
Enable snapshot name verification.
|
|
|
|
_
|
|
|
|
16 ZFS_DEBUG_MODIFY
|
|
|
|
Check for illegally modified ARC buffers.
|
|
|
|
_
|
|
|
|
32 ZFS_DEBUG_SPA
|
|
|
|
Enable spa_dbgmsg entries in the debug log.
|
|
|
|
_
|
|
|
|
64 ZFS_DEBUG_ZIO_FREE
|
|
|
|
Enable verification of block frees.
|
|
|
|
_
|
|
|
|
128 ZFS_DEBUG_HISTOGRAM_VERIFY
|
|
|
|
Enable extra spacemap histogram verifications.
|
|
|
|
.TE
|
|
|
|
.sp
|
|
|
|
* Requires debug build.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
2014-12-23 00:54:43 +00:00
|
|
|
Default value: \fB0\fR.
|
2013-11-16 06:52:54 +00:00
|
|
|
.RE
|
|
|
|
|
2014-06-05 21:20:08 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_free_leak_on_eio\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
If destroy encounters an EIO while reading metadata (e.g. indirect
|
|
|
|
blocks), space referenced by the missing metadata can not be freed.
|
|
|
|
Normally this causes the background destroy to become "stalled", as
|
|
|
|
it is unable to make forward progress. While in this stalled state,
|
|
|
|
all remaining space to free from the error-encountering filesystem is
|
|
|
|
"temporarily leaked". Set this flag to cause it to ignore the EIO,
|
|
|
|
permanently leak the space from indirect blocks that can not be read,
|
|
|
|
and continue to free everything else that it can.
|
|
|
|
|
|
|
|
The default, "stalling" behavior is useful if the storage partially
|
|
|
|
fails (i.e. some but not all i/os fail), and then later recovers. In
|
|
|
|
this case, we will be able to continue pool operations while it is
|
|
|
|
partially failed, and when it recovers, we can continue to free the
|
|
|
|
space, with no leaks. However, note that this case is actually
|
|
|
|
fairly rare.
|
|
|
|
|
|
|
|
Typically pools either (a) fail completely (but perhaps temporarily,
|
|
|
|
e.g. a top-level vdev going offline), or (b) have localized,
|
|
|
|
permanent errors (e.g. disk returns the wrong data due to bit flip or
|
|
|
|
firmware bug). In case (a), this setting does not matter because the
|
|
|
|
pool will be suspended and the sync thread will not be able to make
|
|
|
|
forward progress regardless. In case (b), because the error is
|
|
|
|
permanent, the best we can do is leak the minimum amount of space,
|
|
|
|
which is what setting this flag will do. Therefore, it is reasonable
|
|
|
|
for this flag to normally be set, but we chose the more conservative
|
|
|
|
approach of not setting it, so that there is no possibility of
|
|
|
|
leaking space in the "partial temporary" failure case.
|
|
|
|
.sp
|
|
|
|
Default value: \fB0\fR.
|
|
|
|
.RE
|
|
|
|
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_free_min_time_ms\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
During a \fRzfs destroy\fB operation using \fRfeature@async_destroy\fB a minimum
|
|
|
|
of this much time will be spent working on freeing blocks per txg.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB1,000\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_immediate_write_sz\fR (long)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Largest data block to write to zil. Larger blocks will be treated as if the
|
|
|
|
dataset being written to had the property setting \fRlogbias=throughput\fB.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB32,768\fR.
|
|
|
|
.RE
|
|
|
|
|
2014-11-03 20:15:08 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_max_recordsize\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
We currently support block sizes from 512 bytes to 16MB. The benefits of
|
|
|
|
larger blocks, and thus larger IO, need to be weighed against the cost of
|
|
|
|
COWing a giant block to modify one byte. Additionally, very large blocks
|
|
|
|
can have an impact on i/o latency, and also potentially on the memory
|
|
|
|
allocator. Therefore, we do not allow the recordsize to be set larger than
|
|
|
|
zfs_max_recordsize (default 1MB). Larger blocks can be created by changing
|
|
|
|
this tunable, and pools with larger blocks can always be imported and used,
|
|
|
|
regardless of this setting.
|
|
|
|
.sp
|
|
|
|
Default value: \fB1,048,576\fR.
|
|
|
|
.RE
|
|
|
|
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_mdcomp_disable\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Disable meta data compression
|
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes and \fB0\fR for no (default).
|
|
|
|
.RE
|
|
|
|
|
2014-07-19 20:19:24 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_metaslab_fragmentation_threshold\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Allow metaslabs to keep their active state as long as their fragmentation
|
|
|
|
percentage is less than or equal to this value. An active metaslab that
|
|
|
|
exceeds this threshold will no longer keep its active status allowing
|
|
|
|
better metaslabs to be selected.
|
|
|
|
.sp
|
|
|
|
Default value: \fB70\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_mg_fragmentation_threshold\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Metaslab groups are considered eligible for allocations if their
|
2015-12-30 17:44:46 +00:00
|
|
|
fragmentation metric (measured as a percentage) is less than or equal to
|
2014-07-19 20:19:24 +00:00
|
|
|
this value. If a metaslab group exceeds this threshold then it will be
|
|
|
|
skipped unless all metaslab groups within the metaslab class have also
|
|
|
|
crossed this threshold.
|
|
|
|
.sp
|
|
|
|
Default value: \fB85\fR.
|
|
|
|
.RE
|
|
|
|
|
2014-07-10 03:36:03 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_mg_noalloc_threshold\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Defines a threshold at which metaslab groups should be eligible for
|
|
|
|
allocations. The value is expressed as a percentage of free space
|
|
|
|
beyond which a metaslab group is always eligible for allocations.
|
|
|
|
If a metaslab group's free space is less than or equal to the
|
2015-12-17 01:45:15 +00:00
|
|
|
threshold, the allocator will avoid allocating to that group
|
2014-07-10 03:36:03 +00:00
|
|
|
unless all groups in the pool have reached the threshold. Once all
|
|
|
|
groups have reached the threshold, all groups are allowed to accept
|
|
|
|
allocations. The default value of 0 disables the feature and causes
|
|
|
|
all metaslab groups to be eligible for allocations.
|
|
|
|
|
|
|
|
This parameter allows to deal with pools having heavily imbalanced
|
|
|
|
vdevs such as would be the case when a new vdev has been added.
|
|
|
|
Setting the threshold to a non-zero percentage will stop allocations
|
|
|
|
from being made to vdevs that aren't filled to the specified percentage
|
|
|
|
and allow lesser filled vdevs to acquire more allocations than they
|
|
|
|
otherwise would under the old \fBzfs_mg_alloc_failures\fR facility.
|
|
|
|
.sp
|
|
|
|
Default value: \fB0\fR.
|
|
|
|
.RE
|
|
|
|
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_no_scrub_io\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Set for no scrub I/O. This results in scrubs not actually scrubbing data and
|
|
|
|
simply doing a metadata crawl of the pool instead.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes and \fB0\fR for no (default).
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_no_scrub_prefetch\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Set to disable block prefetching for scrubs.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes and \fB0\fR for no (default).
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_nocacheflush\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Disable cache flush operations on disks when writing. Beware, this may cause
|
|
|
|
corruption if disks re-order writes.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes and \fB0\fR for no (default).
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_nopwrite_enabled\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Enable NOP writes
|
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes (default) and \fB0\fR to disable.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
2015-03-27 04:31:52 +00:00
|
|
|
\fBzfs_pd_bytes_max\fR (int)
|
2013-11-16 06:52:54 +00:00
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
The number of bytes which should be prefetched during a pool traversal
|
|
|
|
(eg: \fRzfs send\fB or other data crawling operations)
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
2015-03-31 18:51:37 +00:00
|
|
|
Default value: \fB52,428,800\fR.
|
2013-11-16 06:52:54 +00:00
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_prefetch_disable\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-26 21:10:31 +00:00
|
|
|
This tunable disables predictive prefetch. Note that it leaves "prescient"
|
|
|
|
prefetch (e.g. prefetch for zfs send) intact. Unlike predictive prefetch,
|
|
|
|
prescient prefetch never issues i/os that end up not being needed, so it
|
|
|
|
can't hurt performance.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes and \fB0\fR for no (default).
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_read_chunk_size\fR (long)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Bytes to read per chunk
|
|
|
|
.sp
|
|
|
|
Default value: \fB1,048,576\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_read_history\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Historic statistics for the last N reads will be available in
|
|
|
|
\fR/proc/spl/kstat/zfs/POOLNAME/reads\fB
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
2015-12-30 17:44:46 +00:00
|
|
|
Default value: \fB0\fR (no data is kept).
|
2013-11-16 06:52:54 +00:00
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_read_history_hits\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Include cache hits in read history
|
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes and \fB0\fR for no (default).
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_recover\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Set to attempt to recover from fatal errors. This should only be used as a
|
|
|
|
last resort, as it typically results in leaked space, or worse.
|
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes and \fB0\fR for no (default).
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_resilver_delay\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2014-06-04 12:23:31 +00:00
|
|
|
Number of ticks to delay prior to issuing a resilver I/O operation when
|
|
|
|
a non-resilver or non-scrub I/O operation has occurred within the past
|
|
|
|
\fBzfs_scan_idle\fR ticks.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB2\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_resilver_min_time_ms\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Resilvers are processed by the sync thread. While resilvering it will spend
|
|
|
|
at least this much time working on a resilver between txg flushes.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB3,000\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_scan_idle\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2014-06-04 12:23:31 +00:00
|
|
|
Idle window in clock ticks. During a scrub or a resilver, if
|
|
|
|
a non-scrub or non-resilver I/O operation has occurred during this
|
|
|
|
window, the next scrub or resilver operation is delayed by, respectively
|
|
|
|
\fBzfs_scrub_delay\fR or \fBzfs_resilver_delay\fR ticks.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB50\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_scan_min_time_ms\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Scrubs are processed by the sync thread. While scrubbing it will spend
|
|
|
|
at least this much time working on a scrub between txg flushes.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB1,000\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_scrub_delay\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2014-06-04 12:23:31 +00:00
|
|
|
Number of ticks to delay prior to issuing a scrub I/O operation when
|
|
|
|
a non-scrub or non-resilver I/O operation has occurred within the past
|
|
|
|
\fBzfs_scan_idle\fR ticks.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB4\fR.
|
|
|
|
.RE
|
|
|
|
|
2013-12-17 21:53:52 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_send_corrupt_data\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Allow sending of corrupt data (ignore read/checksum errors when sending data)
|
2013-12-17 21:53:52 +00:00
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes and \fB0\fR for no (default).
|
|
|
|
.RE
|
|
|
|
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_sync_pass_deferred_free\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Flushing of data to disk is done in passes. Defer frees starting in this pass
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB2\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_sync_pass_dont_compress\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Don't compress starting in this pass
|
|
|
|
.sp
|
|
|
|
Default value: \fB5\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_sync_pass_rewrite\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Rewrite new block pointers starting in this pass
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB2\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_top_maxinflight\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Max concurrent I/Os per top-level vdev (mirrors or raidz arrays) allowed during
|
|
|
|
scrub or resilver operations.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB32\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_txg_history\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Historic statistics for the last N txgs will be available in
|
|
|
|
\fR/proc/spl/kstat/zfs/POOLNAME/txgs\fB
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB0\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_txg_timeout\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Flush dirty data to disk at least every N seconds (maximum txg duration)
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB5\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_aggregation_limit\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Max vdev I/O aggregation size
|
|
|
|
.sp
|
|
|
|
Default value: \fB131,072\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_cache_bshift\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Shift size to inflate reads too
|
|
|
|
.sp
|
2015-12-30 17:44:46 +00:00
|
|
|
Default value: \fB16\fR (effectively 65536).
|
2013-11-16 06:52:54 +00:00
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_cache_max\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Inflate reads small than this value to meet the \fBzfs_vdev_cache_bshift\fR
|
|
|
|
size.
|
|
|
|
.sp
|
|
|
|
Default value: \fB16384\fR.
|
2013-11-16 06:52:54 +00:00
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_cache_size\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Total size of the per-disk cache in bytes.
|
|
|
|
.sp
|
|
|
|
Currently this feature is disabled as it has been found to not be helpful
|
|
|
|
for performance and in some cases harmful.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB0\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
FreeBSD r256956: Improve ZFS N-way mirror read performance by using load and locality information.
The existing algorithm selects a preferred leaf vdev based on offset of the zio
request modulo the number of members in the mirror. It assumes the devices are
of equal performance and that spreading the requests randomly over both drives
will be sufficient to saturate them. In practice this results in the leaf vdevs
being under utilized.
The new algorithm takes into the following additional factors:
* Load of the vdevs (number outstanding I/O requests)
* The locality of last queued I/O vs the new I/O request.
Within the locality calculation additional knowledge about the underlying vdev
is considered such as; is the device backing the vdev a rotating media device.
This results in performance increases across the board as well as significant
increases for predominantly streaming loads and for configurations which don't
have evenly performing devices.
The following are results from a setup with 3 Way Mirror with 2 x HD's and
1 x SSD from a basic test running multiple parrallel dd's.
With pre-fetch disabled (vfs.zfs.prefetch_disable=1):
== Stripe Balanced (default) ==
Read 15360MB using bs: 1048576, readers: 3, took 161 seconds @ 95 MB/s
== Load Balanced (zfslinux) ==
Read 15360MB using bs: 1048576, readers: 3, took 297 seconds @ 51 MB/s
== Load Balanced (locality freebsd) ==
Read 15360MB using bs: 1048576, readers: 3, took 54 seconds @ 284 MB/s
With pre-fetch enabled (vfs.zfs.prefetch_disable=0):
== Stripe Balanced (default) ==
Read 15360MB using bs: 1048576, readers: 3, took 91 seconds @ 168 MB/s
== Load Balanced (zfslinux) ==
Read 15360MB using bs: 1048576, readers: 3, took 108 seconds @ 142 MB/s
== Load Balanced (locality freebsd) ==
Read 15360MB using bs: 1048576, readers: 3, took 48 seconds @ 320 MB/s
In addition to the performance changes the code was also restructured, with
the help of Justin Gibbs, to provide a more logical flow which also ensures
vdevs loads are only calculated from the set of valid candidates.
The following additional sysctls where added to allow the administrator
to tune the behaviour of the load algorithm:
* vfs.zfs.vdev.mirror.rotating_inc
* vfs.zfs.vdev.mirror.rotating_seek_inc
* vfs.zfs.vdev.mirror.rotating_seek_offset
* vfs.zfs.vdev.mirror.non_rotating_inc
* vfs.zfs.vdev.mirror.non_rotating_seek_inc
These changes where based on work started by the zfsonlinux developers:
https://github.com/zfsonlinux/zfs/pull/1487
Reviewed by: gibbs, mav, will
MFC after: 2 weeks
Sponsored by: Multiplay
References:
https://github.com/freebsd/freebsd@5c7a6f5d
https://github.com/freebsd/freebsd@31b7f68d
https://github.com/freebsd/freebsd@e186f564
Performance Testing:
https://github.com/zfsonlinux/zfs/pull/4334#issuecomment-189057141
Porting notes:
- The tunables were adjusted to have ZoL-style names.
- The code was modified to use ZoL's vd_nonrot.
- Fixes were done to make cstyle.pl happy
- Merge conflicts were handled manually
- freebsd/freebsd@e186f564bc946f82c76e0b34c2f0370ed9aea022 by my
collegue Andriy Gapon has been included. It applied perfectly, but
added a cstyle regression.
- This replaces 556011dbec2d10579819078559a77630fc559112 entirely.
- A typo "IO'a" has been corrected to say "IO's"
- Descriptions of new tunables were added to man/man5/zfs-module-parameters.5.
Ported-by: Richard Yao <ryao@gentoo.org>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #4334
2016-02-13 01:47:22 +00:00
|
|
|
\fBzfs_vdev_mirror_rotating_inc\fR (int)
|
2013-11-16 06:52:54 +00:00
|
|
|
.ad
|
|
|
|
.RS 12n
|
FreeBSD r256956: Improve ZFS N-way mirror read performance by using load and locality information.
The existing algorithm selects a preferred leaf vdev based on offset of the zio
request modulo the number of members in the mirror. It assumes the devices are
of equal performance and that spreading the requests randomly over both drives
will be sufficient to saturate them. In practice this results in the leaf vdevs
being under utilized.
The new algorithm takes into the following additional factors:
* Load of the vdevs (number outstanding I/O requests)
* The locality of last queued I/O vs the new I/O request.
Within the locality calculation additional knowledge about the underlying vdev
is considered such as; is the device backing the vdev a rotating media device.
This results in performance increases across the board as well as significant
increases for predominantly streaming loads and for configurations which don't
have evenly performing devices.
The following are results from a setup with 3 Way Mirror with 2 x HD's and
1 x SSD from a basic test running multiple parrallel dd's.
With pre-fetch disabled (vfs.zfs.prefetch_disable=1):
== Stripe Balanced (default) ==
Read 15360MB using bs: 1048576, readers: 3, took 161 seconds @ 95 MB/s
== Load Balanced (zfslinux) ==
Read 15360MB using bs: 1048576, readers: 3, took 297 seconds @ 51 MB/s
== Load Balanced (locality freebsd) ==
Read 15360MB using bs: 1048576, readers: 3, took 54 seconds @ 284 MB/s
With pre-fetch enabled (vfs.zfs.prefetch_disable=0):
== Stripe Balanced (default) ==
Read 15360MB using bs: 1048576, readers: 3, took 91 seconds @ 168 MB/s
== Load Balanced (zfslinux) ==
Read 15360MB using bs: 1048576, readers: 3, took 108 seconds @ 142 MB/s
== Load Balanced (locality freebsd) ==
Read 15360MB using bs: 1048576, readers: 3, took 48 seconds @ 320 MB/s
In addition to the performance changes the code was also restructured, with
the help of Justin Gibbs, to provide a more logical flow which also ensures
vdevs loads are only calculated from the set of valid candidates.
The following additional sysctls where added to allow the administrator
to tune the behaviour of the load algorithm:
* vfs.zfs.vdev.mirror.rotating_inc
* vfs.zfs.vdev.mirror.rotating_seek_inc
* vfs.zfs.vdev.mirror.rotating_seek_offset
* vfs.zfs.vdev.mirror.non_rotating_inc
* vfs.zfs.vdev.mirror.non_rotating_seek_inc
These changes where based on work started by the zfsonlinux developers:
https://github.com/zfsonlinux/zfs/pull/1487
Reviewed by: gibbs, mav, will
MFC after: 2 weeks
Sponsored by: Multiplay
References:
https://github.com/freebsd/freebsd@5c7a6f5d
https://github.com/freebsd/freebsd@31b7f68d
https://github.com/freebsd/freebsd@e186f564
Performance Testing:
https://github.com/zfsonlinux/zfs/pull/4334#issuecomment-189057141
Porting notes:
- The tunables were adjusted to have ZoL-style names.
- The code was modified to use ZoL's vd_nonrot.
- Fixes were done to make cstyle.pl happy
- Merge conflicts were handled manually
- freebsd/freebsd@e186f564bc946f82c76e0b34c2f0370ed9aea022 by my
collegue Andriy Gapon has been included. It applied perfectly, but
added a cstyle regression.
- This replaces 556011dbec2d10579819078559a77630fc559112 entirely.
- A typo "IO'a" has been corrected to say "IO's"
- Descriptions of new tunables were added to man/man5/zfs-module-parameters.5.
Ported-by: Richard Yao <ryao@gentoo.org>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #4334
2016-02-13 01:47:22 +00:00
|
|
|
A number by which the balancing algorithm increments the load calculation for
|
|
|
|
the purpose of selecting the least busy mirror member when an I/O immediately
|
|
|
|
follows its predecessor on rotational vdevs for the purpose of making decisions
|
|
|
|
based on load.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
FreeBSD r256956: Improve ZFS N-way mirror read performance by using load and locality information.
The existing algorithm selects a preferred leaf vdev based on offset of the zio
request modulo the number of members in the mirror. It assumes the devices are
of equal performance and that spreading the requests randomly over both drives
will be sufficient to saturate them. In practice this results in the leaf vdevs
being under utilized.
The new algorithm takes into the following additional factors:
* Load of the vdevs (number outstanding I/O requests)
* The locality of last queued I/O vs the new I/O request.
Within the locality calculation additional knowledge about the underlying vdev
is considered such as; is the device backing the vdev a rotating media device.
This results in performance increases across the board as well as significant
increases for predominantly streaming loads and for configurations which don't
have evenly performing devices.
The following are results from a setup with 3 Way Mirror with 2 x HD's and
1 x SSD from a basic test running multiple parrallel dd's.
With pre-fetch disabled (vfs.zfs.prefetch_disable=1):
== Stripe Balanced (default) ==
Read 15360MB using bs: 1048576, readers: 3, took 161 seconds @ 95 MB/s
== Load Balanced (zfslinux) ==
Read 15360MB using bs: 1048576, readers: 3, took 297 seconds @ 51 MB/s
== Load Balanced (locality freebsd) ==
Read 15360MB using bs: 1048576, readers: 3, took 54 seconds @ 284 MB/s
With pre-fetch enabled (vfs.zfs.prefetch_disable=0):
== Stripe Balanced (default) ==
Read 15360MB using bs: 1048576, readers: 3, took 91 seconds @ 168 MB/s
== Load Balanced (zfslinux) ==
Read 15360MB using bs: 1048576, readers: 3, took 108 seconds @ 142 MB/s
== Load Balanced (locality freebsd) ==
Read 15360MB using bs: 1048576, readers: 3, took 48 seconds @ 320 MB/s
In addition to the performance changes the code was also restructured, with
the help of Justin Gibbs, to provide a more logical flow which also ensures
vdevs loads are only calculated from the set of valid candidates.
The following additional sysctls where added to allow the administrator
to tune the behaviour of the load algorithm:
* vfs.zfs.vdev.mirror.rotating_inc
* vfs.zfs.vdev.mirror.rotating_seek_inc
* vfs.zfs.vdev.mirror.rotating_seek_offset
* vfs.zfs.vdev.mirror.non_rotating_inc
* vfs.zfs.vdev.mirror.non_rotating_seek_inc
These changes where based on work started by the zfsonlinux developers:
https://github.com/zfsonlinux/zfs/pull/1487
Reviewed by: gibbs, mav, will
MFC after: 2 weeks
Sponsored by: Multiplay
References:
https://github.com/freebsd/freebsd@5c7a6f5d
https://github.com/freebsd/freebsd@31b7f68d
https://github.com/freebsd/freebsd@e186f564
Performance Testing:
https://github.com/zfsonlinux/zfs/pull/4334#issuecomment-189057141
Porting notes:
- The tunables were adjusted to have ZoL-style names.
- The code was modified to use ZoL's vd_nonrot.
- Fixes were done to make cstyle.pl happy
- Merge conflicts were handled manually
- freebsd/freebsd@e186f564bc946f82c76e0b34c2f0370ed9aea022 by my
collegue Andriy Gapon has been included. It applied perfectly, but
added a cstyle regression.
- This replaces 556011dbec2d10579819078559a77630fc559112 entirely.
- A typo "IO'a" has been corrected to say "IO's"
- Descriptions of new tunables were added to man/man5/zfs-module-parameters.5.
Ported-by: Richard Yao <ryao@gentoo.org>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #4334
2016-02-13 01:47:22 +00:00
|
|
|
Default value: \fB0\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_mirror_rotating_seek_inc\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
A number by which the balancing algorithm increments the load calculation for
|
|
|
|
the purpose of selecting the least busy mirror member when an I/O lacks
|
|
|
|
locality as defined by the zfs_vdev_mirror_rotating_seek_offset. I/Os within
|
|
|
|
this that are not immediately following the previous I/O are incremented by
|
|
|
|
half.
|
|
|
|
.sp
|
|
|
|
Default value: \fB5\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_mirror_rotating_seek_offset\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
The maximum distance for the last queued I/O in which the balancing algorithm
|
|
|
|
considers an I/O to have locality.
|
|
|
|
See the section "ZFS I/O SCHEDULER".
|
|
|
|
.sp
|
|
|
|
Default value: \fB1048576\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_mirror_non_rotating_inc\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
A number by which the balancing algorithm increments the load calculation for
|
|
|
|
the purpose of selecting the least busy mirror member on non-rotational vdevs
|
|
|
|
when I/Os do not immediately follow one another.
|
|
|
|
.sp
|
|
|
|
Default value: \fB0\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_mirror_non_rotating_seek_inc\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
A number by which the balancing algorithm increments the load calculation for
|
|
|
|
the purpose of selecting the least busy mirror member when an I/O lacks
|
|
|
|
locality as defined by the zfs_vdev_mirror_rotating_seek_offset. I/Os within
|
|
|
|
this that are not immediately following the previous I/O are incremented by
|
|
|
|
half.
|
|
|
|
.sp
|
|
|
|
Default value: \fB1\fR.
|
2013-11-16 06:52:54 +00:00
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_read_gap_limit\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Aggregate read I/O operations if the gap on-disk between them is within this
|
|
|
|
threshold.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB32,768\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_scheduler\fR (charp)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Set the Linux I/O scheduler on whole disk vdevs to this scheduler
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fBnoop\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_write_gap_limit\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Aggregate write I/O over gap
|
|
|
|
.sp
|
|
|
|
Default value: \fB4,096\fR.
|
|
|
|
.RE
|
|
|
|
|
SIMD implementation of vdev_raidz generate and reconstruct routines
This is a new implementation of RAIDZ1/2/3 routines using x86_64
scalar, SSE, and AVX2 instruction sets. Included are 3 parity
generation routines (P, PQ, and PQR) and 7 reconstruction routines,
for all RAIDZ level. On module load, a quick benchmark of supported
routines will select the fastest for each operation and they will
be used at runtime. Original implementation is still present and
can be selected via module parameter.
Patch contains:
- specialized gen/rec routines for all RAIDZ levels,
- new scalar raidz implementation (unrolled),
- two x86_64 SIMD implementations (SSE and AVX2 instructions sets),
- fastest routines selected on module load (benchmark).
- cmd/raidz_test - verify and benchmark all implementations
- added raidz_test to the ZFS Test Suite
New zfs module parameters:
- zfs_vdev_raidz_impl (str): selects the implementation to use. On
module load, the parameter will only accept first 3 options, and
the other implementations can be set once module is finished
loading. Possible values for this option are:
"fastest" - use the fastest math available
"original" - use the original raidz code
"scalar" - new scalar impl
"sse" - new SSE impl if available
"avx2" - new AVX2 impl if available
See contents of `/sys/module/zfs/parameters/zfs_vdev_raidz_impl` to
get the list of supported values. If an implementation is not supported
on the system, it will not be shown. Currently selected option is
enclosed in `[]`.
Signed-off-by: Gvozden Neskovic <neskovic@gmail.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #4328
2016-04-25 08:04:31 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_vdev_raidz_impl\fR (string)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2016-07-17 17:41:11 +00:00
|
|
|
Parameter for selecting raidz parity implementation to use.
|
SIMD implementation of vdev_raidz generate and reconstruct routines
This is a new implementation of RAIDZ1/2/3 routines using x86_64
scalar, SSE, and AVX2 instruction sets. Included are 3 parity
generation routines (P, PQ, and PQR) and 7 reconstruction routines,
for all RAIDZ level. On module load, a quick benchmark of supported
routines will select the fastest for each operation and they will
be used at runtime. Original implementation is still present and
can be selected via module parameter.
Patch contains:
- specialized gen/rec routines for all RAIDZ levels,
- new scalar raidz implementation (unrolled),
- two x86_64 SIMD implementations (SSE and AVX2 instructions sets),
- fastest routines selected on module load (benchmark).
- cmd/raidz_test - verify and benchmark all implementations
- added raidz_test to the ZFS Test Suite
New zfs module parameters:
- zfs_vdev_raidz_impl (str): selects the implementation to use. On
module load, the parameter will only accept first 3 options, and
the other implementations can be set once module is finished
loading. Possible values for this option are:
"fastest" - use the fastest math available
"original" - use the original raidz code
"scalar" - new scalar impl
"sse" - new SSE impl if available
"avx2" - new AVX2 impl if available
See contents of `/sys/module/zfs/parameters/zfs_vdev_raidz_impl` to
get the list of supported values. If an implementation is not supported
on the system, it will not be shown. Currently selected option is
enclosed in `[]`.
Signed-off-by: Gvozden Neskovic <neskovic@gmail.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #4328
2016-04-25 08:04:31 +00:00
|
|
|
|
|
|
|
Options marked (always) below may be selected on module load as they are
|
|
|
|
supported on all systems.
|
|
|
|
The remaining options may only be set after the module is loaded, as they
|
|
|
|
are available only if the implementations are compiled in and supported
|
|
|
|
on the running system.
|
|
|
|
|
|
|
|
Once the module is loaded, the content of
|
|
|
|
/sys/module/zfs/parameters/zfs_vdev_raidz_impl will show available options
|
|
|
|
with the currently selected one enclosed in [].
|
|
|
|
Possible options are:
|
|
|
|
fastest - (always) implementation selected using built-in benchmark
|
|
|
|
original - (always) original raidz implementation
|
|
|
|
scalar - (always) scalar raidz implementation
|
2016-06-28 17:49:53 +00:00
|
|
|
sse2 - implementation using SSE2 instruction set (64bit x86 only)
|
|
|
|
ssse3 - implementation using SSSE3 instruction set (64bit x86 only)
|
SIMD implementation of vdev_raidz generate and reconstruct routines
This is a new implementation of RAIDZ1/2/3 routines using x86_64
scalar, SSE, and AVX2 instruction sets. Included are 3 parity
generation routines (P, PQ, and PQR) and 7 reconstruction routines,
for all RAIDZ level. On module load, a quick benchmark of supported
routines will select the fastest for each operation and they will
be used at runtime. Original implementation is still present and
can be selected via module parameter.
Patch contains:
- specialized gen/rec routines for all RAIDZ levels,
- new scalar raidz implementation (unrolled),
- two x86_64 SIMD implementations (SSE and AVX2 instructions sets),
- fastest routines selected on module load (benchmark).
- cmd/raidz_test - verify and benchmark all implementations
- added raidz_test to the ZFS Test Suite
New zfs module parameters:
- zfs_vdev_raidz_impl (str): selects the implementation to use. On
module load, the parameter will only accept first 3 options, and
the other implementations can be set once module is finished
loading. Possible values for this option are:
"fastest" - use the fastest math available
"original" - use the original raidz code
"scalar" - new scalar impl
"sse" - new SSE impl if available
"avx2" - new AVX2 impl if available
See contents of `/sys/module/zfs/parameters/zfs_vdev_raidz_impl` to
get the list of supported values. If an implementation is not supported
on the system, it will not be shown. Currently selected option is
enclosed in `[]`.
Signed-off-by: Gvozden Neskovic <neskovic@gmail.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #4328
2016-04-25 08:04:31 +00:00
|
|
|
avx2 - implementation using AVX2 instruction set (64bit x86 only)
|
|
|
|
.sp
|
|
|
|
Default value: \fBfastest\fR.
|
|
|
|
.RE
|
|
|
|
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_zevent_cols\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
When zevents are logged to the console use this as the word wrap width.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB80\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_zevent_console\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Log events to the console
|
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes and \fB0\fR for no (default).
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzfs_zevent_len_max\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Max event queue length. A value of 0 will result in a calculated value which
|
|
|
|
increases with the number of CPUs in the system (minimum 64 events). Events
|
|
|
|
in the queue can be viewed with the \fBzpool events\fR command.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB0\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzil_replay_disable\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Disable intent logging replay. Can be disabled for recovery from corrupted
|
|
|
|
ZIL
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes and \fB0\fR for no (default).
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzil_slog_limit\fR (ulong)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Max commit bytes to separate log device
|
|
|
|
.sp
|
|
|
|
Default value: \fB1,048,576\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzio_delay_max\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
A zevent will be logged if a ZIO operation takes more than N milliseconds to
|
SIMD implementation of vdev_raidz generate and reconstruct routines
This is a new implementation of RAIDZ1/2/3 routines using x86_64
scalar, SSE, and AVX2 instruction sets. Included are 3 parity
generation routines (P, PQ, and PQR) and 7 reconstruction routines,
for all RAIDZ level. On module load, a quick benchmark of supported
routines will select the fastest for each operation and they will
be used at runtime. Original implementation is still present and
can be selected via module parameter.
Patch contains:
- specialized gen/rec routines for all RAIDZ levels,
- new scalar raidz implementation (unrolled),
- two x86_64 SIMD implementations (SSE and AVX2 instructions sets),
- fastest routines selected on module load (benchmark).
- cmd/raidz_test - verify and benchmark all implementations
- added raidz_test to the ZFS Test Suite
New zfs module parameters:
- zfs_vdev_raidz_impl (str): selects the implementation to use. On
module load, the parameter will only accept first 3 options, and
the other implementations can be set once module is finished
loading. Possible values for this option are:
"fastest" - use the fastest math available
"original" - use the original raidz code
"scalar" - new scalar impl
"sse" - new SSE impl if available
"avx2" - new AVX2 impl if available
See contents of `/sys/module/zfs/parameters/zfs_vdev_raidz_impl` to
get the list of supported values. If an implementation is not supported
on the system, it will not be shown. Currently selected option is
enclosed in `[]`.
Signed-off-by: Gvozden Neskovic <neskovic@gmail.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #4328
2016-04-25 08:04:31 +00:00
|
|
|
complete. Note that this is only a logging facility, not a timeout on
|
2015-12-30 17:44:46 +00:00
|
|
|
operations.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB30,000\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzio_requeue_io_start_cut_in_line\fR (int)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Prioritize requeued I/O
|
|
|
|
.sp
|
|
|
|
Default value: \fB0\fR.
|
|
|
|
.RE
|
|
|
|
|
2015-12-16 19:22:32 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzio_taskq_batch_pct\fR (uint)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
Percentage of online CPUs (or CPU cores, etc) which will run a worker thread
|
|
|
|
for IO. These workers are responsible for IO work such as compression and
|
|
|
|
checksum calculations. Fractional number of CPUs will be rounded down.
|
|
|
|
.sp
|
|
|
|
The default value of 75 was chosen to avoid using all CPUs which can result in
|
|
|
|
latency issues and inconsistent application performance, especially when high
|
|
|
|
compression is enabled.
|
|
|
|
.sp
|
|
|
|
Default value: \fB75\fR.
|
|
|
|
.RE
|
|
|
|
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzvol_inhibit_dev\fR (uint)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Do not create zvol device nodes. This may slightly improve startup time on
|
|
|
|
systems with a very large number of zvols.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Use \fB1\fR for yes and \fB0\fR for no (default).
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzvol_major\fR (uint)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Major number for zvol block devices
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB230\fR.
|
|
|
|
.RE
|
|
|
|
|
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzvol_max_discard_blocks\fR (ulong)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
2015-12-30 17:44:46 +00:00
|
|
|
Discard (aka TRIM) operations done on zvols will be done in batches of this
|
|
|
|
many blocks, where block size is determined by the \fBvolblocksize\fR property
|
|
|
|
of a zvol.
|
2013-11-16 06:52:54 +00:00
|
|
|
.sp
|
|
|
|
Default value: \fB16,384\fR.
|
|
|
|
.RE
|
|
|
|
|
2015-08-18 20:51:20 +00:00
|
|
|
.sp
|
|
|
|
.ne 2
|
|
|
|
.na
|
|
|
|
\fBzvol_prefetch_bytes\fR (uint)
|
|
|
|
.ad
|
|
|
|
.RS 12n
|
|
|
|
When adding a zvol to the system prefetch \fBzvol_prefetch_bytes\fR
|
|
|
|
from the start and end of the volume. Prefetching these regions
|
|
|
|
of the volume is desirable because they are likely to be accessed
|
|
|
|
immediately by \fBblkid(8)\fR or by the kernel scanning for a partition
|
|
|
|
table.
|
|
|
|
.sp
|
|
|
|
Default value: \fB131,072\fR.
|
|
|
|
.RE
|
|
|
|
|
Illumos #4045 write throttle & i/o scheduler performance work
4045 zfs write throttle & i/o scheduler performance work
1. The ZFS i/o scheduler (vdev_queue.c) now divides i/os into 5 classes: sync
read, sync write, async read, async write, and scrub/resilver. The scheduler
issues a number of concurrent i/os from each class to the device. Once a class
has been selected, an i/o is selected from this class using either an elevator
algorithem (async, scrub classes) or FIFO (sync classes). The number of
concurrent async write i/os is tuned dynamically based on i/o load, to achieve
good sync i/o latency when there is not a high load of writes, and good write
throughput when there is. See the block comment in vdev_queue.c (reproduced
below) for more details.
2. The write throttle (dsl_pool_tempreserve_space() and
txg_constrain_throughput()) is rewritten to produce much more consistent delays
when under constant load. The new write throttle is based on the amount of
dirty data, rather than guesses about future performance of the system. When
there is a lot of dirty data, each transaction (e.g. write() syscall) will be
delayed by the same small amount. This eliminates the "brick wall of wait"
that the old write throttle could hit, causing all transactions to wait several
seconds until the next txg opens. One of the keys to the new write throttle is
decrementing the amount of dirty data as i/o completes, rather than at the end
of spa_sync(). Note that the write throttle is only applied once the i/o
scheduler is issuing the maximum number of outstanding async writes. See the
block comments in dsl_pool.c and above dmu_tx_delay() (reproduced below) for
more details.
This diff has several other effects, including:
* the commonly-tuned global variable zfs_vdev_max_pending has been removed;
use per-class zfs_vdev_*_max_active values or zfs_vdev_max_active instead.
* the size of each txg (meaning the amount of dirty data written, and thus the
time it takes to write out) is now controlled differently. There is no longer
an explicit time goal; the primary determinant is amount of dirty data.
Systems that are under light or medium load will now often see that a txg is
always syncing, but the impact to performance (e.g. read latency) is minimal.
Tune zfs_dirty_data_max and zfs_dirty_data_sync to control this.
* zio_taskq_batch_pct = 75 -- Only use 75% of all CPUs for compression,
checksum, etc. This improves latency by not allowing these CPU-intensive tasks
to consume all CPU (on machines with at least 4 CPU's; the percentage is
rounded up).
--matt
APPENDIX: problems with the current i/o scheduler
The current ZFS i/o scheduler (vdev_queue.c) is deadline based. The problem
with this is that if there are always i/os pending, then certain classes of
i/os can see very long delays.
For example, if there are always synchronous reads outstanding, then no async
writes will be serviced until they become "past due". One symptom of this
situation is that each pass of the txg sync takes at least several seconds
(typically 3 seconds).
If many i/os become "past due" (their deadline is in the past), then we must
service all of these overdue i/os before any new i/os. This happens when we
enqueue a batch of async writes for the txg sync, with deadlines 2.5 seconds in
the future. If we can't complete all the i/os in 2.5 seconds (e.g. because
there were always reads pending), then these i/os will become past due. Now we
must service all the "async" writes (which could be hundreds of megabytes)
before we service any reads, introducing considerable latency to synchronous
i/os (reads or ZIL writes).
Notes on porting to ZFS on Linux:
- zio_t gained new members io_physdone and io_phys_children. Because
object caches in the Linux port call the constructor only once at
allocation time, objects may contain residual data when retrieved
from the cache. Therefore zio_create() was updated to zero out the two
new fields.
- vdev_mirror_pending() relied on the depth of the per-vdev pending queue
(vq->vq_pending_tree) to select the least-busy leaf vdev to read from.
This tree has been replaced by vq->vq_active_tree which is now used
for the same purpose.
- vdev_queue_init() used the value of zfs_vdev_max_pending to determine
the number of vdev I/O buffers to pre-allocate. That global no longer
exists, so we instead use the sum of the *_max_active values for each of
the five I/O classes described above.
- The Illumos implementation of dmu_tx_delay() delays a transaction by
sleeping in condition variable embedded in the thread
(curthread->t_delay_cv). We do not have an equivalent CV to use in
Linux, so this change replaced the delay logic with a wrapper called
zfs_sleep_until(). This wrapper could be adopted upstream and in other
downstream ports to abstract away operating system-specific delay logic.
- These tunables are added as module parameters, and descriptions added
to the zfs-module-parameters.5 man page.
spa_asize_inflation
zfs_deadman_synctime_ms
zfs_vdev_max_active
zfs_vdev_async_write_active_min_dirty_percent
zfs_vdev_async_write_active_max_dirty_percent
zfs_vdev_async_read_max_active
zfs_vdev_async_read_min_active
zfs_vdev_async_write_max_active
zfs_vdev_async_write_min_active
zfs_vdev_scrub_max_active
zfs_vdev_scrub_min_active
zfs_vdev_sync_read_max_active
zfs_vdev_sync_read_min_active
zfs_vdev_sync_write_max_active
zfs_vdev_sync_write_min_active
zfs_dirty_data_max_percent
zfs_delay_min_dirty_percent
zfs_dirty_data_max_max_percent
zfs_dirty_data_max
zfs_dirty_data_max_max
zfs_dirty_data_sync
zfs_delay_scale
The latter four have type unsigned long, whereas they are uint64_t in
Illumos. This accommodates Linux's module_param() supported types, but
means they may overflow on 32-bit architectures.
The values zfs_dirty_data_max and zfs_dirty_data_max_max are the most
likely to overflow on 32-bit systems, since they express physical RAM
sizes in bytes. In fact, Illumos initializes zfs_dirty_data_max_max to
2^32 which does overflow. To resolve that, this port instead initializes
it in arc_init() to 25% of physical RAM, and adds the tunable
zfs_dirty_data_max_max_percent to override that percentage. While this
solution doesn't completely avoid the overflow issue, it should be a
reasonable default for most systems, and the minority of affected
systems can work around the issue by overriding the defaults.
- Fixed reversed logic in comment above zfs_delay_scale declaration.
- Clarified comments in vdev_queue.c regarding when per-queue minimums take
effect.
- Replaced dmu_tx_write_limit in the dmu_tx kstat file
with dmu_tx_dirty_delay and dmu_tx_dirty_over_max. The first counts
how many times a transaction has been delayed because the pool dirty
data has exceeded zfs_delay_min_dirty_percent. The latter counts how
many times the pool dirty data has exceeded zfs_dirty_data_max (which
we expect to never happen).
- The original patch would have regressed the bug fixed in
zfsonlinux/zfs@c418410, which prevented users from setting the
zfs_vdev_aggregation_limit tuning larger than SPA_MAXBLOCKSIZE.
A similar fix is added to vdev_queue_aggregate().
- In vdev_queue_io_to_issue(), dynamically allocate 'zio_t search' on the
heap instead of the stack. In Linux we can't afford such large
structures on the stack.
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Reviewed by: Ned Bass <bass6@llnl.gov>
Reviewed by: Brendan Gregg <brendan.gregg@joyent.com>
Approved by: Robert Mustacchi <rm@joyent.com>
References:
http://www.illumos.org/issues/4045
illumos/illumos-gate@69962b5647e4a8b9b14998733b765925381b727e
Ported-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1913
2013-08-29 03:01:20 +00:00
|
|
|
.SH ZFS I/O SCHEDULER
|
|
|
|
ZFS issues I/O operations to leaf vdevs to satisfy and complete I/Os.
|
|
|
|
The I/O scheduler determines when and in what order those operations are
|
|
|
|
issued. The I/O scheduler divides operations into five I/O classes
|
|
|
|
prioritized in the following order: sync read, sync write, async read,
|
|
|
|
async write, and scrub/resilver. Each queue defines the minimum and
|
|
|
|
maximum number of concurrent operations that may be issued to the
|
|
|
|
device. In addition, the device has an aggregate maximum,
|
|
|
|
\fBzfs_vdev_max_active\fR. Note that the sum of the per-queue minimums
|
|
|
|
must not exceed the aggregate maximum. If the sum of the per-queue
|
|
|
|
maximums exceeds the aggregate maximum, then the number of active I/Os
|
|
|
|
may reach \fBzfs_vdev_max_active\fR, in which case no further I/Os will
|
|
|
|
be issued regardless of whether all per-queue minimums have been met.
|
|
|
|
.sp
|
|
|
|
For many physical devices, throughput increases with the number of
|
|
|
|
concurrent operations, but latency typically suffers. Further, physical
|
|
|
|
devices typically have a limit at which more concurrent operations have no
|
|
|
|
effect on throughput or can actually cause it to decrease.
|
|
|
|
.sp
|
|
|
|
The scheduler selects the next operation to issue by first looking for an
|
|
|
|
I/O class whose minimum has not been satisfied. Once all are satisfied and
|
|
|
|
the aggregate maximum has not been hit, the scheduler looks for classes
|
|
|
|
whose maximum has not been satisfied. Iteration through the I/O classes is
|
|
|
|
done in the order specified above. No further operations are issued if the
|
|
|
|
aggregate maximum number of concurrent operations has been hit or if there
|
|
|
|
are no operations queued for an I/O class that has not hit its maximum.
|
|
|
|
Every time an I/O is queued or an operation completes, the I/O scheduler
|
|
|
|
looks for new operations to issue.
|
|
|
|
.sp
|
|
|
|
In general, smaller max_active's will lead to lower latency of synchronous
|
|
|
|
operations. Larger max_active's may lead to higher overall throughput,
|
|
|
|
depending on underlying storage.
|
|
|
|
.sp
|
|
|
|
The ratio of the queues' max_actives determines the balance of performance
|
|
|
|
between reads, writes, and scrubs. E.g., increasing
|
|
|
|
\fBzfs_vdev_scrub_max_active\fR will cause the scrub or resilver to complete
|
|
|
|
more quickly, but reads and writes to have higher latency and lower throughput.
|
|
|
|
.sp
|
|
|
|
All I/O classes have a fixed maximum number of outstanding operations
|
|
|
|
except for the async write class. Asynchronous writes represent the data
|
|
|
|
that is committed to stable storage during the syncing stage for
|
|
|
|
transaction groups. Transaction groups enter the syncing state
|
|
|
|
periodically so the number of queued async writes will quickly burst up
|
|
|
|
and then bleed down to zero. Rather than servicing them as quickly as
|
|
|
|
possible, the I/O scheduler changes the maximum number of active async
|
|
|
|
write I/Os according to the amount of dirty data in the pool. Since
|
|
|
|
both throughput and latency typically increase with the number of
|
|
|
|
concurrent operations issued to physical devices, reducing the
|
|
|
|
burstiness in the number of concurrent operations also stabilizes the
|
|
|
|
response time of operations from other -- and in particular synchronous
|
|
|
|
-- queues. In broad strokes, the I/O scheduler will issue more
|
|
|
|
concurrent operations from the async write queue as there's more dirty
|
|
|
|
data in the pool.
|
|
|
|
.sp
|
|
|
|
Async Writes
|
|
|
|
.sp
|
|
|
|
The number of concurrent operations issued for the async write I/O class
|
|
|
|
follows a piece-wise linear function defined by a few adjustable points.
|
|
|
|
.nf
|
|
|
|
|
|
|
|
| o---------| <-- zfs_vdev_async_write_max_active
|
|
|
|
^ | /^ |
|
|
|
|
| | / | |
|
|
|
|
active | / | |
|
|
|
|
I/O | / | |
|
|
|
|
count | / | |
|
|
|
|
| / | |
|
|
|
|
|-------o | | <-- zfs_vdev_async_write_min_active
|
|
|
|
0|_______^______|_________|
|
|
|
|
0% | | 100% of zfs_dirty_data_max
|
|
|
|
| |
|
|
|
|
| `-- zfs_vdev_async_write_active_max_dirty_percent
|
|
|
|
`--------- zfs_vdev_async_write_active_min_dirty_percent
|
|
|
|
|
|
|
|
.fi
|
|
|
|
Until the amount of dirty data exceeds a minimum percentage of the dirty
|
|
|
|
data allowed in the pool, the I/O scheduler will limit the number of
|
|
|
|
concurrent operations to the minimum. As that threshold is crossed, the
|
|
|
|
number of concurrent operations issued increases linearly to the maximum at
|
|
|
|
the specified maximum percentage of the dirty data allowed in the pool.
|
|
|
|
.sp
|
|
|
|
Ideally, the amount of dirty data on a busy pool will stay in the sloped
|
|
|
|
part of the function between \fBzfs_vdev_async_write_active_min_dirty_percent\fR
|
|
|
|
and \fBzfs_vdev_async_write_active_max_dirty_percent\fR. If it exceeds the
|
|
|
|
maximum percentage, this indicates that the rate of incoming data is
|
|
|
|
greater than the rate that the backend storage can handle. In this case, we
|
|
|
|
must further throttle incoming writes, as described in the next section.
|
|
|
|
|
|
|
|
.SH ZFS TRANSACTION DELAY
|
|
|
|
We delay transactions when we've determined that the backend storage
|
|
|
|
isn't able to accommodate the rate of incoming writes.
|
|
|
|
.sp
|
|
|
|
If there is already a transaction waiting, we delay relative to when
|
|
|
|
that transaction will finish waiting. This way the calculated delay time
|
|
|
|
is independent of the number of threads concurrently executing
|
|
|
|
transactions.
|
|
|
|
.sp
|
|
|
|
If we are the only waiter, wait relative to when the transaction
|
|
|
|
started, rather than the current time. This credits the transaction for
|
|
|
|
"time already served", e.g. reading indirect blocks.
|
|
|
|
.sp
|
|
|
|
The minimum time for a transaction to take is calculated as:
|
|
|
|
.nf
|
|
|
|
min_time = zfs_delay_scale * (dirty - min) / (max - dirty)
|
|
|
|
min_time is then capped at 100 milliseconds.
|
|
|
|
.fi
|
|
|
|
.sp
|
|
|
|
The delay has two degrees of freedom that can be adjusted via tunables. The
|
|
|
|
percentage of dirty data at which we start to delay is defined by
|
|
|
|
\fBzfs_delay_min_dirty_percent\fR. This should typically be at or above
|
|
|
|
\fBzfs_vdev_async_write_active_max_dirty_percent\fR so that we only start to
|
|
|
|
delay after writing at full speed has failed to keep up with the incoming write
|
|
|
|
rate. The scale of the curve is defined by \fBzfs_delay_scale\fR. Roughly speaking,
|
|
|
|
this variable determines the amount of delay at the midpoint of the curve.
|
|
|
|
.sp
|
|
|
|
.nf
|
|
|
|
delay
|
|
|
|
10ms +-------------------------------------------------------------*+
|
|
|
|
| *|
|
|
|
|
9ms + *+
|
|
|
|
| *|
|
|
|
|
8ms + *+
|
|
|
|
| * |
|
|
|
|
7ms + * +
|
|
|
|
| * |
|
|
|
|
6ms + * +
|
|
|
|
| * |
|
|
|
|
5ms + * +
|
|
|
|
| * |
|
|
|
|
4ms + * +
|
|
|
|
| * |
|
|
|
|
3ms + * +
|
|
|
|
| * |
|
|
|
|
2ms + (midpoint) * +
|
|
|
|
| | ** |
|
|
|
|
1ms + v *** +
|
|
|
|
| zfs_delay_scale ----------> ******** |
|
|
|
|
0 +-------------------------------------*********----------------+
|
|
|
|
0% <- zfs_dirty_data_max -> 100%
|
|
|
|
.fi
|
|
|
|
.sp
|
|
|
|
Note that since the delay is added to the outstanding time remaining on the
|
|
|
|
most recent transaction, the delay is effectively the inverse of IOPS.
|
|
|
|
Here the midpoint of 500us translates to 2000 IOPS. The shape of the curve
|
|
|
|
was chosen such that small changes in the amount of accumulated dirty data
|
|
|
|
in the first 3/4 of the curve yield relatively small differences in the
|
|
|
|
amount of delay.
|
|
|
|
.sp
|
|
|
|
The effects can be easier to understand when the amount of delay is
|
|
|
|
represented on a log scale:
|
|
|
|
.sp
|
|
|
|
.nf
|
|
|
|
delay
|
|
|
|
100ms +-------------------------------------------------------------++
|
|
|
|
+ +
|
|
|
|
| |
|
|
|
|
+ *+
|
|
|
|
10ms + *+
|
|
|
|
+ ** +
|
|
|
|
| (midpoint) ** |
|
|
|
|
+ | ** +
|
|
|
|
1ms + v **** +
|
|
|
|
+ zfs_delay_scale ----------> ***** +
|
|
|
|
| **** |
|
|
|
|
+ **** +
|
|
|
|
100us + ** +
|
|
|
|
+ * +
|
|
|
|
| * |
|
|
|
|
+ * +
|
|
|
|
10us + * +
|
|
|
|
+ +
|
|
|
|
| |
|
|
|
|
+ +
|
|
|
|
+--------------------------------------------------------------+
|
|
|
|
0% <- zfs_dirty_data_max -> 100%
|
|
|
|
.fi
|
|
|
|
.sp
|
|
|
|
Note here that only as the amount of dirty data approaches its limit does
|
|
|
|
the delay start to increase rapidly. The goal of a properly tuned system
|
|
|
|
should be to keep the amount of dirty data out of that range by first
|
|
|
|
ensuring that the appropriate limits are set for the I/O scheduler to reach
|
|
|
|
optimal throughput on the backend storage, and then by changing the value
|
|
|
|
of \fBzfs_delay_scale\fR to increase the steepness of the curve.
|