diff options
author | Matthew Ahrens <[email protected]> | 2014-11-03 12:15:08 -0800 |
---|---|---|
committer | Brian Behlendorf <[email protected]> | 2015-05-11 12:23:16 -0700 |
commit | f1512ee61e2f22186ac16481a09d86112b2d6788 (patch) | |
tree | 6098f841f27955f13d4c2a53b2a4826b5f3bacda /man/man5 | |
parent | 3df293404a102398445fc013b67250073db9004e (diff) |
Illumos 5027 - zfs large block support
5027 zfs large block support
Reviewed by: Alek Pinchuk <[email protected]>
Reviewed by: George Wilson <[email protected]>
Reviewed by: Josef 'Jeff' Sipek <[email protected]>
Reviewed by: Richard Elling <[email protected]>
Reviewed by: Saso Kiselkov <[email protected]>
Reviewed by: Brian Behlendorf <[email protected]>
Approved by: Dan McDonald <[email protected]>
References:
https://www.illumos.org/issues/5027
https://github.com/illumos/illumos-gate/commit/b515258
Porting Notes:
* Included in this patch is a tiny ISP2() cleanup in zio_init() from
Illumos 5255.
* Unlike the upstream Illumos commit this patch does not impose an
arbitrary 128K block size limit on volumes. Volumes, like filesystems,
are limited by the zfs_max_recordsize=1M module option.
* By default the maximum record size is limited to 1M by the module
option zfs_max_recordsize. This value may be safely increased up to
16M which is the largest block size supported by the on-disk format.
At the moment, 1M blocks clearly offer a significant performance
improvement but the benefits of going beyond this for the majority
of workloads are less clear.
* The illumos version of this patch increased DMU_MAX_ACCESS to 32M.
This was determined not to be large enough when using 16M blocks
because the zfs_make_xattrdir() function will fail (EFBIG) when
assigning a TX. This was immediately observed under Linux because
all newly created files must have a security xattr created and
that was failing. Therefore, we've set DMU_MAX_ACCESS to 64M.
* On 32-bit platforms a hard limit of 1M is set for blocks due
to the limited virtual address space. We should be able to relax
this one the ABD patches are merged.
Ported-by: Brian Behlendorf <[email protected]>
Closes #354
Diffstat (limited to 'man/man5')
-rw-r--r-- | man/man5/zfs-module-parameters.5 | 18 | ||||
-rw-r--r-- | man/man5/zpool-features.5 | 21 |
2 files changed, 39 insertions, 0 deletions
diff --git a/man/man5/zfs-module-parameters.5 b/man/man5/zfs-module-parameters.5 index 4bbfbf512..359e9f72f 100644 --- a/man/man5/zfs-module-parameters.5 +++ b/man/man5/zfs-module-parameters.5 @@ -948,6 +948,24 @@ Default value: \fB32,768\fR. .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 + +.sp +.ne 2 +.na \fBzfs_mdcomp_disable\fR (int) .ad .RS 12n diff --git a/man/man5/zpool-features.5 b/man/man5/zpool-features.5 index 27034264b..a1dac4292 100644 --- a/man/man5/zpool-features.5 +++ b/man/man5/zpool-features.5 @@ -411,5 +411,26 @@ never return to being \fBenabled\fR. .RE +.sp +.ne 2 +.na +\fB\fBlarge_blocks\fR\fR +.ad +.RS 4n +.TS +l l . +GUID org.open-zfs:large_block +READ\-ONLY COMPATIBLE no +DEPENDENCIES extensible_dataset +.TE + +The \fBlarge_block\fR feature allows the record size on a dataset to be +set larger than 128KB. + +This feature becomes \fBactive\fR once a \fBrecordsize\fR property has been +set larger than 128KB, and will return to being \fBenabled\fR once all +filesystems that have ever had their recordsize larger than 128KB are destroyed. +.RE + .SH "SEE ALSO" \fBzpool\fR(8) |