Default zfs_max_recordsize to 16M

Increase the default allowed maximum recordsize from 1M to 16M.
As described in the zfs(4) man page, there are significant costs
which need to be considered before using very large blocks.
However, there are scenarios where they make good sense and
it should no longer be necessary to artificially restrict their
use behind a module option.

Note that for 32-bit platforms we continue to leave this
restriction in place due to the limited virtual address space
available (256-512MB).  On these systems only a handful
of blocks could be cached at any one time severely impacting
performance and potentially stability.

Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: Alexander Motin <[email protected]>
Signed-off-by: Rich Ercolani <[email protected]>
Closes #12830
Closes #13302 

1 files changed, 3 insertions, 3 deletions

diff --git a/man/man4/zfs.4 b/man/man4/zfs.4
index a18917eb1..290ecd22e 100644
--- a/man/man4/zfs.4
+++ b/man/man4/zfs.4
@@ -1469,15 +1469,15 @@ feature uses to estimate incoming log blocks.
 .It Sy zfs_max_logsm_summary_length Ns = Ns Sy 10 Pq ulong
 Maximum number of rows allowed in the summary of the spacemap log.
 .
-.It Sy zfs_max_recordsize Ns = Ns Sy 1048576 Po 1MB Pc Pq int
+.It Sy zfs_max_recordsize Ns = Ns Sy 16777216 Po 16MB Pc Pq int
 We currently support block sizes from
 .Em 512B No to Em 16MB .
 The benefits of larger blocks, and thus larger I/O,
 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 this tunable.
-Larger blocks can be created by changing it,
+Therefore, we formerly forbade creating blocks larger than 1M.
+Larger blocks could be created by changing it,
 and pools with larger blocks can always be imported and used,
 regardless of this setting.
 .