aboutsummaryrefslogtreecommitdiffstats
path: root/man/man5
diff options
context:
space:
mode:
authorMatthew Ahrens <[email protected]>2014-11-03 12:15:08 -0800
committerBrian Behlendorf <[email protected]>2015-05-11 12:23:16 -0700
commitf1512ee61e2f22186ac16481a09d86112b2d6788 (patch)
tree6098f841f27955f13d4c2a53b2a4826b5f3bacda /man/man5
parent3df293404a102398445fc013b67250073db9004e (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.518
-rw-r--r--man/man5/zpool-features.521
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)