| blob | c56b31e2d7152b7c1ac8762313060015519f83b9 |
1 '\" te
2 .\" Copyright (c) 2012, 2018 by Delphix. All rights reserved.
3 .\" Copyright (c) 2013 by Saso Kiselkov. All rights reserved.
4 .\" Copyright (c) 2014, Joyent, Inc. All rights reserved.
5 .\" The contents of this file are subject to the terms of the Common Development
6 .\" and Distribution License (the "License"). You may not use this file except
7 .\" in compliance with the License. You can obtain a copy of the license at
8 .\" usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.
9 .\"
10 .\" See the License for the specific language governing permissions and
11 .\" limitations under the License. When distributing Covered Code, include this
12 .\" CDDL HEADER in each file and include the License file at
13 .\" usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this
14 .\" CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your
15 .\" own identifying information:
16 .\" Portions Copyright [yyyy] [name of copyright owner]
17 .\" Copyright (c) 2019, Klara Inc.
18 .\" Copyright (c) 2019, Allan Jude
19 .\" Copyright (c) 2021, Colm Buckley <colm@tuatha.org>
20 .TH ZPOOL-FEATURES 5 "Aug 24, 2020" OpenZFS
21 .SH NAME
22 zpool\-features \- ZFS pool feature descriptions
23 .SH DESCRIPTION
24 .sp
25 .LP
26 ZFS pool on\-disk format versions are specified via "features" which replace
27 the old on\-disk format numbers (the last supported on\-disk format number is
28 28). To enable a feature on a pool use the \fBupgrade\fR subcommand of the
29 zpool(8) command, or set the \fBfeature@\fR\fIfeature_name\fR property
30 to \fBenabled\fR. Please also see the \fB"Compatibility feature sets"\fR
31 section for information on how sets of features may be enabled together.
32 .sp
33 .LP
34 The pool format does not affect file system version compatibility or the ability
35 to send file systems between pools.
36 .sp
37 .LP
38 Since most features can be enabled independently of each other the on\-disk
39 format of the pool is specified by the set of all features marked as
40 \fBactive\fR on the pool. If the pool was created by another software version
41 this set may include unsupported features.
42 .SS "Identifying features"
43 .sp
44 .LP
45 Every feature has a GUID of the form \fIcom.example:feature_name\fR. The
46 reversed DNS name ensures that the feature's GUID is unique across all ZFS
47 implementations. When unsupported features are encountered on a pool they will
48 be identified by their GUIDs. Refer to the documentation for the ZFS
49 implementation that created the pool for information about those features.
50 .sp
51 .LP
52 Each supported feature also has a short name. By convention a feature's short
53 name is the portion of its GUID which follows the ':' (e.g.
54 \fIcom.example:feature_name\fR would have the short name \fIfeature_name\fR),
55 however a feature's short name may differ across ZFS implementations if
56 following the convention would result in name conflicts.
57 .SS "Feature states"
58 .sp
59 .LP
60 Features can be in one of three states:
61 .sp
62 .ne 2
63 .na
64 \fBactive\fR
65 .ad
66 .RS 12n
67 This feature's on\-disk format changes are in effect on the pool. Support for
68 this feature is required to import the pool in read\-write mode. If this
69 feature is not read-only compatible, support is also required to import the pool
70 in read\-only mode (see "Read\-only compatibility").
71 .RE
73 .sp
74 .ne 2
75 .na
76 \fBenabled\fR
77 .ad
78 .RS 12n
79 An administrator has marked this feature as enabled on the pool, but the
80 feature's on\-disk format changes have not been made yet. The pool can still be
81 imported by software that does not support this feature, but changes may be made
82 to the on\-disk format at any time which will move the feature to the
83 \fBactive\fR state. Some features may support returning to the \fBenabled\fR
84 state after becoming \fBactive\fR. See feature\-specific documentation for
85 details.
86 .RE
88 .sp
89 .ne 2
90 .na
91 \fBdisabled\fR
92 .ad
93 .RS 12n
94 This feature's on\-disk format changes have not been made and will not be made
95 unless an administrator moves the feature to the \fBenabled\fR state. Features
96 cannot be disabled once they have been enabled.
97 .RE
99 .sp
100 .LP
101 The state of supported features is exposed through pool properties of the form
102 \fIfeature@short_name\fR.
103 .SS "Read\-only compatibility"
104 .sp
105 .LP
106 Some features may make on\-disk format changes that do not interfere with other
107 software's ability to read from the pool. These features are referred to as
108 "read\-only compatible". If all unsupported features on a pool are read\-only
109 compatible, the pool can be imported in read\-only mode by setting the
110 \fBreadonly\fR property during import (see zpool(8) for details on
111 importing pools).
112 .SS "Unsupported features"
113 .sp
114 .LP
115 For each unsupported feature enabled on an imported pool a pool property
116 named \fIunsupported@feature_name\fR will indicate why the import was allowed
117 despite the unsupported feature. Possible values for this property are:
119 .sp
120 .ne 2
121 .na
122 \fBinactive\fR
123 .ad
124 .RS 12n
125 The feature is in the \fBenabled\fR state and therefore the pool's on\-disk
126 format is still compatible with software that does not support this feature.
127 .RE
129 .sp
130 .ne 2
131 .na
132 \fBreadonly\fR
133 .ad
134 .RS 12n
135 The feature is read\-only compatible and the pool has been imported in
136 read\-only mode.
137 .RE
139 .SS "Feature dependencies"
140 .sp
141 .LP
142 Some features depend on other features being enabled in order to function
143 properly. Enabling a feature will automatically enable any features it
144 depends on.
146 .SS "Compatibility feature sets"
147 .sp
148 .LP
149 It is sometimes necessary for a pool to maintain compatibility with a
150 specific on\-disk format, by enabling and disabling particular features. The
151 \fBcompatibility\fR feature facilitates this by allowing feature sets to
152 be read from text files. When set to \fBoff\fR (the default); compatibility
153 feature sets are disabled (ie: all features are enabled); when set to
154 \fBlegacy\fR; no features are enabled. When set to a comma\-separated list
155 of filenames (each filename may either be an absolute path, or relative to
156 \fB/etc/zfs/compatibility.d\fR or \fB/usr/share/zfs/compatibility.d\fR)
157 the lists of requested features are read from those files, separated by
158 whitespace and/or commas. Only features present in all files are enabled.
159 .LP
160 Simple sanity checks are applied to the files; they must be between 1 and
161 16,384 bytes in size, and must end with a newline character.
162 .LP
163 The requested features are applied when a pool is created using
164 \fBzpool create \-o compatibility=...\fR and controls which features are
165 enabled when using \fBzpool upgrade\fR. \fBzpool status\fR
166 will not show a warning about disabled features which are not part
167 of the requested feature set.
168 .LP
169 By convention, compatibility files in \fB/usr/share/zfs/compatibility.d\fR
170 are provided by the distribution package, and include feature sets
171 supported by important versions of popular distribtions, and feature
172 sets commonly supported at the start of each year. Compatibility files
173 in \fB/etc/zfs/compatibility.d\fR, if present, will take precedence over
174 files with the same name in \fB/usr/share/zfs/compatibility.d\fR.
175 .LP
176 Compatibility files may include comments; any text from \fB#\fR to the end
177 of the line is ignored.
178 .LP
179 \fBExample:\fR
180 .EX
181 # \fBcat /usr/share/zfs/compatibility.d/grub2\fR
182 # Features which are supported by GRUB2
183 async_destroy
184 bookmarks
185 embedded_data
186 empty_bpobj
187 enabled_txg
188 extensible_dataset
189 filesystem_limits
190 hole_birth
191 large_blocks
192 lz4_compress
193 spacemap_histogram
195 # \fBzpool create \-o compatibility=grub2 bootpool vdev\fR
196 .EE
197 .LP
198 See \fBzpool\-create(8)\fR and \fBzpool\-upgrade(8)\fR for more information
199 on how these commands are affected by feature sets.
200 .SH FEATURES
201 .sp
202 .LP
203 The following features are supported on this system:
205 .sp
206 .ne 2
207 .na
208 \fBallocation_classes\fR
209 .ad
210 .RS 4n
211 .TS
212 l l .
213 GUID org.zfsonlinux:allocation_classes
214 READ\-ONLY COMPATIBLE yes
215 DEPENDENCIES none
216 .TE
218 This feature enables support for separate allocation classes.
220 This feature becomes \fBactive\fR when a dedicated allocation class vdev
221 (dedup or special) is created with the \fBzpool create\fR or \fBzpool add\fR
222 subcommands. With device removal, it can be returned to the \fBenabled\fR
223 state if all the dedicated allocation class vdevs are removed.
224 .RE
226 .sp
227 .ne 2
228 .na
229 \fBasync_destroy\fR
230 .ad
231 .RS 4n
232 .TS
233 l l .
234 GUID com.delphix:async_destroy
235 READ\-ONLY COMPATIBLE yes
236 DEPENDENCIES none
237 .TE
239 Destroying a file system requires traversing all of its data in order to
240 return its used space to the pool. Without \fBasync_destroy\fR the file system
241 is not fully removed until all space has been reclaimed. If the destroy
242 operation is interrupted by a reboot or power outage the next attempt to open
243 the pool will need to complete the destroy operation synchronously.
245 When \fBasync_destroy\fR is enabled the file system's data will be reclaimed
246 by a background process, allowing the destroy operation to complete without
247 traversing the entire file system. The background process is able to resume
248 interrupted destroys after the pool has been opened, eliminating the need
249 to finish interrupted destroys as part of the open operation. The amount
250 of space remaining to be reclaimed by the background process is available
251 through the \fBfreeing\fR property.
253 This feature is only \fBactive\fR while \fBfreeing\fR is non\-zero.
254 .RE
256 .sp
257 .ne 2
258 .na
259 \fBbookmarks\fR
260 .ad
261 .RS 4n
262 .TS
263 l l .
264 GUID com.delphix:bookmarks
265 READ\-ONLY COMPATIBLE yes
266 DEPENDENCIES extensible_dataset
267 .TE
269 This feature enables use of the \fBzfs bookmark\fR subcommand.
271 This feature is \fBactive\fR while any bookmarks exist in the pool.
272 All bookmarks in the pool can be listed by running
273 \fBzfs list -t bookmark -r \fIpoolname\fR\fR.
274 .RE
276 .sp
277 .ne 2
278 .na
279 \fBbookmark_v2\fR
280 .ad
281 .RS 4n
282 .TS
283 l l .
284 GUID com.datto:bookmark_v2
285 READ\-ONLY COMPATIBLE no
286 DEPENDENCIES bookmark, extensible_dataset
287 .TE
289 This feature enables the creation and management of larger bookmarks which are
290 needed for other features in ZFS.
292 This feature becomes \fBactive\fR when a v2 bookmark is created and will be
293 returned to the \fBenabled\fR state when all v2 bookmarks are destroyed.
294 .RE
296 .sp
297 .ne 2
298 .na
299 \fBbookmark_written\fR
300 .ad
301 .RS 4n
302 .TS
303 l l .
304 GUID com.delphix:bookmark_written
305 READ\-ONLY COMPATIBLE no
306 DEPENDENCIES bookmark, extensible_dataset, bookmark_v2
307 .TE
309 This feature enables additional bookmark accounting fields, enabling the
310 written#<bookmark> property (space written since a bookmark) and estimates of
311 send stream sizes for incrementals from bookmarks.
313 This feature becomes \fBactive\fR when a bookmark is created and will be
314 returned to the \fBenabled\fR state when all bookmarks with these fields are destroyed.
315 .RE
317 .sp
318 .ne 2
319 .na
320 \fBdevice_rebuild\fR
321 .ad
322 .RS 4n
323 .TS
324 l l .
325 GUID org.openzfs:device_rebuild
326 READ\-ONLY COMPATIBLE yes
327 DEPENDENCIES none
328 .TE
330 This feature enables the ability for the \fBzpool attach\fR and \fBzpool
331 replace\fR subcommands to perform sequential reconstruction (instead of
332 healing reconstruction) when resilvering.
334 Sequential reconstruction resilvers a device in LBA order without immediately
335 verifying the checksums. Once complete a scrub is started which then verifies
336 the checksums. This approach allows full redundancy to be restored to the pool
337 in the minimum amount of time. This two phase approach will take longer than a
338 healing resilver when the time to verify the checksums is included. However,
339 unless there is additional pool damage no checksum errors should be reported
340 by the scrub. This feature is incompatible with raidz configurations.
342 This feature becomes \fBactive\fR while a sequential resilver is in progress,
343 and returns to \fBenabled\fR when the resilver completes.
344 .RE
346 .sp
347 .ne 2
348 .na
349 \fBdevice_removal\fR
350 .ad
351 .RS 4n
352 .TS
353 l l .
354 GUID com.delphix:device_removal
355 READ\-ONLY COMPATIBLE no
356 DEPENDENCIES none
357 .TE
359 This feature enables the \fBzpool remove\fR subcommand to remove top-level
360 vdevs, evacuating them to reduce the total size of the pool.
362 This feature becomes \fBactive\fR when the \fBzpool remove\fR subcommand is used
363 on a top-level vdev, and will never return to being \fBenabled\fR.
364 .RE
366 .sp
367 .ne 2
368 .na
369 \fBdraid\fR
370 .ad
371 .RS 4n
372 .TS
373 l l .
374 GUID org.openzfs:draid
375 READ\-ONLY COMPATIBLE no
376 DEPENDENCIES none
377 .TE
379 This feature enables use of the \fBdraid\fR vdev type. dRAID is a variant
380 of raidz which provides integrated distributed hot spares that allow faster
381 resilvering while retaining the benefits of raidz. Data, parity, and spare
382 space are organized in redundancy groups and distributed evenly over all of
383 the devices.
385 This feature becomes \fBactive\fR when creating a pool which uses the
386 \fBdraid\fR vdev type, or when adding a new \fBdraid\fR vdev to an
387 existing pool.
388 .RE
390 .sp
391 .ne 2
392 .na
393 \fBedonr\fR
394 .ad
395 .RS 4n
396 .TS
397 l l .
398 GUID org.illumos:edonr
399 READ\-ONLY COMPATIBLE no
400 DEPENDENCIES extensible_dataset
401 .TE
403 This feature enables the use of the Edon-R hash algorithm for checksum,
404 including for nopwrite (if compression is also enabled, an overwrite of
405 a block whose checksum matches the data being written will be ignored).
406 In an abundance of caution, Edon-R requires verification when used with
407 dedup: \fBzfs set dedup=edonr,verify\fR. See \fBzfs\fR(8).
409 Edon-R is a very high-performance hash algorithm that was part
410 of the NIST SHA-3 competition. It provides extremely high hash
411 performance (over 350% faster than SHA-256), but was not selected
412 because of its unsuitability as a general purpose secure hash algorithm.
413 This implementation utilizes the new salted checksumming functionality
414 in ZFS, which means that the checksum is pre-seeded with a secret
415 256-bit random key (stored on the pool) before being fed the data block
416 to be checksummed. Thus the produced checksums are unique to a given
417 pool.
419 When the \fBedonr\fR feature is set to \fBenabled\fR, the administrator
420 can turn on the \fBedonr\fR checksum on any dataset using the
421 \fBzfs set checksum=edonr\fR. See zfs(8). This feature becomes
422 \fBactive\fR once a \fBchecksum\fR property has been set to \fBedonr\fR,
423 and will return to being \fBenabled\fR once all filesystems that have
424 ever had their checksum set to \fBedonr\fR are destroyed.
426 FreeBSD does not support the \fBedonr\fR feature.
427 .RE
429 .sp
430 .ne 2
431 .na
432 \fBembedded_data\fR
433 .ad
434 .RS 4n
435 .TS
436 l l .
437 GUID com.delphix:embedded_data
438 READ\-ONLY COMPATIBLE no
439 DEPENDENCIES none
440 .TE
442 This feature improves the performance and compression ratio of
443 highly-compressible blocks. Blocks whose contents can compress to 112 bytes
444 or smaller can take advantage of this feature.
446 When this feature is enabled, the contents of highly-compressible blocks are
447 stored in the block "pointer" itself (a misnomer in this case, as it contains
448 the compressed data, rather than a pointer to its location on disk). Thus
449 the space of the block (one sector, typically 512 bytes or 4KB) is saved,
450 and no additional i/o is needed to read and write the data block.
452 This feature becomes \fBactive\fR as soon as it is enabled and will
453 never return to being \fBenabled\fR.
454 .RE
456 .sp
457 .ne 2
458 .na
459 \fBempty_bpobj\fR
460 .ad
461 .RS 4n
462 .TS
463 l l .
464 GUID com.delphix:empty_bpobj
465 READ\-ONLY COMPATIBLE yes
466 DEPENDENCIES none
467 .TE
469 This feature increases the performance of creating and using a large
470 number of snapshots of a single filesystem or volume, and also reduces
471 the disk space required.
473 When there are many snapshots, each snapshot uses many Block Pointer
474 Objects (bpobj's) to track blocks associated with that snapshot.
475 However, in common use cases, most of these bpobj's are empty. This
476 feature allows us to create each bpobj on-demand, thus eliminating the
477 empty bpobjs.
479 This feature is \fBactive\fR while there are any filesystems, volumes,
480 or snapshots which were created after enabling this feature.
481 .RE
483 .sp
484 .ne 2
485 .na
486 \fBenabled_txg\fR
487 .ad
488 .RS 4n
489 .TS
490 l l .
491 GUID com.delphix:enabled_txg
492 READ\-ONLY COMPATIBLE yes
493 DEPENDENCIES none
494 .TE
496 Once this feature is enabled ZFS records the transaction group number
497 in which new features are enabled. This has no user-visible impact,
498 but other features may depend on this feature.
500 This feature becomes \fBactive\fR as soon as it is enabled and will
501 never return to being \fBenabled\fB.
502 .RE
504 .sp
505 .ne 2
506 .na
507 \fBencryption\fR
508 .ad
509 .RS 4n
510 .TS
511 l l .
512 GUID com.datto:encryption
513 READ\-ONLY COMPATIBLE no
514 DEPENDENCIES bookmark_v2, extensible_dataset
515 .TE
517 This feature enables the creation and management of natively encrypted datasets.
519 This feature becomes \fBactive\fR when an encrypted dataset is created and will
520 be returned to the \fBenabled\fR state when all datasets that use this feature
521 are destroyed.
522 .RE
524 .sp
525 .ne 2
526 .na
527 \fBextensible_dataset\fR
528 .ad
529 .RS 4n
530 .TS
531 l l .
532 GUID com.delphix:extensible_dataset
533 READ\-ONLY COMPATIBLE no
534 DEPENDENCIES none
535 .TE
537 This feature allows more flexible use of internal ZFS data structures,
538 and exists for other features to depend on.
540 This feature will be \fBactive\fR when the first dependent feature uses it,
541 and will be returned to the \fBenabled\fR state when all datasets that use
542 this feature are destroyed.
543 .RE
545 .sp
546 .ne 2
547 .na
548 \fBfilesystem_limits\fR
549 .ad
550 .RS 4n
551 .TS
552 l l .
553 GUID com.joyent:filesystem_limits
554 READ\-ONLY COMPATIBLE yes
555 DEPENDENCIES extensible_dataset
556 .TE
558 This feature enables filesystem and snapshot limits. These limits can be used
559 to control how many filesystems and/or snapshots can be created at the point in
560 the tree on which the limits are set.
562 This feature is \fBactive\fR once either of the limit properties has been
563 set on a dataset. Once activated the feature is never deactivated.
564 .RE
566 .sp
567 .ne 2
568 .na
569 \fBhole_birth\fR
570 .ad
571 .RS 4n
572 .TS
573 l l .
574 GUID com.delphix:hole_birth
575 READ\-ONLY COMPATIBLE no
576 DEPENDENCIES enabled_txg
577 .TE
579 This feature has/had bugs, the result of which is that, if you do a
580 \fBzfs send -i\fR (or \fB-R\fR, since it uses \fB-i\fR) from an affected
581 dataset, the receiver will not see any checksum or other errors, but the
582 resulting destination snapshot will not match the source. Its use by
583 \fBzfs send -i\fR has been disabled by default. See the
584 \fBsend_holes_without_birth_time\fR module parameter in
585 zfs-module-parameters(5).
587 This feature improves performance of incremental sends (\fBzfs send -i\fR)
588 and receives for objects with many holes. The most common case of
589 hole-filled objects is zvols.
591 An incremental send stream from snapshot \fBA\fR to snapshot \fBB\fR
592 contains information about every block that changed between \fBA\fR and
593 \fBB\fR. Blocks which did not change between those snapshots can be
594 identified and omitted from the stream using a piece of metadata called
595 the 'block birth time', but birth times are not recorded for holes (blocks
596 filled only with zeroes). Since holes created after \fBA\fR cannot be
597 distinguished from holes created before \fBA\fR, information about every
598 hole in the entire filesystem or zvol is included in the send stream.
600 For workloads where holes are rare this is not a problem. However, when
601 incrementally replicating filesystems or zvols with many holes (for
602 example a zvol formatted with another filesystem) a lot of time will
603 be spent sending and receiving unnecessary information about holes that
604 already exist on the receiving side.
606 Once the \fBhole_birth\fR feature has been enabled the block birth times
607 of all new holes will be recorded. Incremental sends between snapshots
608 created after this feature is enabled will use this new metadata to avoid
609 sending information about holes that already exist on the receiving side.
611 This feature becomes \fBactive\fR as soon as it is enabled and will
612 never return to being \fBenabled\fB.
613 .RE
615 .sp
616 .ne 2
617 .na
618 \fBlarge_blocks\fR
619 .ad
620 .RS 4n
621 .TS
622 l l .
623 GUID org.open-zfs:large_blocks
624 READ\-ONLY COMPATIBLE no
625 DEPENDENCIES extensible_dataset
626 .TE
628 The \fBlarge_block\fR feature allows the record size on a dataset to be
629 set larger than 128KB.
631 This feature becomes \fBactive\fR once a dataset contains a file with
632 a block size larger than 128KB, and will return to being \fBenabled\fR once all
633 filesystems that have ever had their recordsize larger than 128KB are destroyed.
634 .RE
636 .sp
637 .ne 2
638 .na
639 \fBlarge_dnode\fR
640 .ad
641 .RS 4n
642 .TS
643 l l .
644 GUID org.zfsonlinux:large_dnode
645 READ\-ONLY COMPATIBLE no
646 DEPENDENCIES extensible_dataset
647 .TE
649 The \fBlarge_dnode\fR feature allows the size of dnodes in a dataset to be
650 set larger than 512B.
652 This feature becomes \fBactive\fR once a dataset contains an object with
653 a dnode larger than 512B, which occurs as a result of setting the
654 \fBdnodesize\fR dataset property to a value other than \fBlegacy\fR. The
655 feature will return to being \fBenabled\fR once all filesystems that
656 have ever contained a dnode larger than 512B are destroyed. Large dnodes
657 allow more data to be stored in the bonus buffer, thus potentially
658 improving performance by avoiding the use of spill blocks.
659 .RE
661 .sp
662 .ne 2
663 .na
664 \fB\fBlivelist\fR\fR
665 .ad
666 .RS 4n
667 .TS
668 l l .
669 GUID com.delphix:livelist
670 READ\-ONLY COMPATIBLE yes
671 DEPENDENCIES none
672 .TE
673 This feature allows clones to be deleted faster than the traditional method
674 when a large number of random/sparse writes have been made to the clone.
675 All blocks allocated and freed after a clone is created are tracked by the
676 the clone's livelist which is referenced during the deletion of the clone.
677 The feature is activated when a clone is created and remains active until all
678 clones have been destroyed.
679 .RE
681 .sp
682 .ne 2
683 .na
684 \fBlog_spacemap\fR
685 .ad
686 .RS 4n
687 .TS
688 l l .
689 GUID com.delphix:log_spacemap
690 READ\-ONLY COMPATIBLE yes
691 DEPENDENCIES com.delphix:spacemap_v2
692 .TE
694 This feature improves performance for heavily-fragmented pools,
695 especially when workloads are heavy in random-writes. It does so by
696 logging all the metaslab changes on a single spacemap every TXG
697 instead of scattering multiple writes to all the metaslab spacemaps.
699 This feature becomes \fBactive\fR as soon as it is enabled and will never
700 return to being \fBenabled\fR.
701 .RE
703 .sp
704 .ne 2
705 .na
706 \fBlz4_compress\fR
707 .ad
708 .RS 4n
709 .TS
710 l l .
711 GUID org.illumos:lz4_compress
712 READ\-ONLY COMPATIBLE no
713 DEPENDENCIES none
714 .TE
716 \fBlz4\fR is a high-performance real-time compression algorithm that
717 features significantly faster compression and decompression as well as a
718 higher compression ratio than the older \fBlzjb\fR compression.
719 Typically, \fBlz4\fR compression is approximately 50% faster on
720 compressible data and 200% faster on incompressible data than
721 \fBlzjb\fR. It is also approximately 80% faster on decompression, while
722 giving approximately 10% better compression ratio.
724 When the \fBlz4_compress\fR feature is set to \fBenabled\fR, the
725 administrator can turn on \fBlz4\fR compression on any dataset on the
726 pool using the zfs(8) command. Please note that doing so will
727 immediately activate the \fBlz4_compress\fR feature on the underlying
728 pool using the zfs(8) command. Also, all newly written metadata
729 will be compressed with \fBlz4\fR algorithm. Since this feature is not
730 read-only compatible, this operation will render the pool unimportable
731 on systems without support for the \fBlz4_compress\fR feature.
733 Booting off of \fBlz4\fR-compressed root pools is supported.
735 This feature becomes \fBactive\fR as soon as it is enabled and will
736 never return to being \fBenabled\fB.
737 .RE
739 .sp
740 .ne 2
741 .na
742 \fBmulti_vdev_crash_dump\fR
743 .ad
744 .RS 4n
745 .TS
746 l l .
747 GUID com.joyent:multi_vdev_crash_dump
748 READ\-ONLY COMPATIBLE no
749 DEPENDENCIES none
750 .TE
752 This feature allows a dump device to be configured with a pool comprised
753 of multiple vdevs. Those vdevs may be arranged in any mirrored or raidz
754 configuration.
756 When the \fBmulti_vdev_crash_dump\fR feature is set to \fBenabled\fR,
757 the administrator can use the \fBdumpadm\fR(1M) command to configure a
758 dump device on a pool comprised of multiple vdevs.
760 Under FreeBSD and Linux this feature is registered for compatibility but not
761 used. New pools created under FreeBSD and Linux will have the feature
762 \fBenabled\fR but will never transition to \fB\fBactive\fR. This functionality
763 is not required in order to support crash dumps under FreeBSD and Linux.
764 Existing pools where this feature is \fB\fBactive\fR can be imported.
765 .RE
767 .sp
768 .ne 2
769 .na
770 \fBobsolete_counts\fR
771 .ad
772 .RS 4n
773 .TS
774 l l .
775 GUID com.delphix:obsolete_counts
776 READ\-ONLY COMPATIBLE yes
777 DEPENDENCIES device_removal
778 .TE
780 This feature is an enhancement of device_removal, which will over time
781 reduce the memory used to track removed devices. When indirect blocks
782 are freed or remapped, we note that their part of the indirect mapping
783 is "obsolete", i.e. no longer needed.
785 This feature becomes \fBactive\fR when the \fBzpool remove\fR subcommand is
786 used on a top-level vdev, and will never return to being \fBenabled\fR.
787 .RE
789 .sp
790 .ne 2
791 .na
792 \fBproject_quota\fR
793 .ad
794 .RS 4n
795 .TS
796 l l .
797 GUID org.zfsonlinux:project_quota
798 READ\-ONLY COMPATIBLE yes
799 DEPENDENCIES extensible_dataset
800 .TE
802 This feature allows administrators to account the spaces and objects usage
803 information against the project identifier (ID).
805 The project ID is new object-based attribute. When upgrading an existing
806 filesystem, object without project ID attribute will be assigned a zero
807 project ID. After this feature is enabled, newly created object will inherit
808 its parent directory's project ID if the parent inherit flag is set (via
809 \fBchattr +/-P\fR or \fBzfs project [-s|-C]\fR). Otherwise, the new object's
810 project ID will be set as zero. An object's project ID can be changed at
811 anytime by the owner (or privileged user) via \fBchattr -p $prjid\fR or
812 \fBzfs project -p $prjid\fR.
814 This feature will become \fBactive\fR as soon as it is enabled and will never
815 return to being \fBdisabled\fR. Each filesystem will be upgraded automatically
816 when remounted or when new file is created under that filesystem. The upgrade
817 can also be triggered on filesystems via `zfs set version=current <pool/fs>`.
818 The upgrade process runs in the background and may take a while to complete
819 for the filesystems containing a large number of files.
820 .RE
822 .sp
823 .ne 2
824 .na
825 \fB\fBredaction_bookmarks\fR\fR
826 .ad
827 .RS 4n
828 .TS
829 l l .
830 GUID com.delphix:redaction_bookmarks
831 READ\-ONLY COMPATIBLE no
832 DEPENDENCIES bookmarks, extensible_dataset
833 .TE
835 This feature enables the use of the redacted zfs send. Redacted \fBzfs send\fR
836 creates redaction bookmarks, which store the list of blocks redacted by the
837 send that created them. For more information about redacted send,
838 see \fBzfs\fR(8).
840 .RE
842 .sp
843 .ne 2
844 .na
845 \fB\fBredacted_datasets\fR\fR
846 .ad
847 .RS 4n
848 .TS
849 l l .
850 GUID com.delphix:redacted_datasets
851 READ\-ONLY COMPATIBLE no
852 DEPENDENCIES extensible_dataset
853 .TE
855 This feature enables the receiving of redacted zfs send streams. Redacted zfs
856 send streams create redacted datasets when received. These datasets are
857 missing some of their blocks, and so cannot be safely mounted, and their
858 contents cannot be safely read. For more information about redacted receive,
859 see \fBzfs\fR(8).
860 .RE
862 .sp
863 .ne 2
864 .na
865 \fBresilver_defer\fR
866 .ad
867 .RS 4n
868 .TS
869 l l .
870 GUID com.datto:resilver_defer
871 READ\-ONLY COMPATIBLE yes
872 DEPENDENCIES none
873 .TE
875 This feature allows zfs to postpone new resilvers if an existing one is already
876 in progress. Without this feature, any new resilvers will cause the currently
877 running one to be immediately restarted from the beginning.
879 This feature becomes \fBactive\fR once a resilver has been deferred, and
880 returns to being \fBenabled\fR when the deferred resilver begins.
881 .RE
883 .sp
884 .ne 2
885 .na
886 \fBsha512\fR
887 .ad
888 .RS 4n
889 .TS
890 l l .
891 GUID org.illumos:sha512
892 READ\-ONLY COMPATIBLE no
893 DEPENDENCIES extensible_dataset
894 .TE
896 This feature enables the use of the SHA-512/256 truncated hash algorithm
897 (FIPS 180-4) for checksum and dedup. The native 64-bit arithmetic of
898 SHA-512 provides an approximate 50% performance boost over SHA-256 on
899 64-bit hardware and is thus a good minimum-change replacement candidate
900 for systems where hash performance is important, but these systems
901 cannot for whatever reason utilize the faster \fBskein\fR and
902 \fBedonr\fR algorithms.
904 When the \fBsha512\fR feature is set to \fBenabled\fR, the administrator
905 can turn on the \fBsha512\fR checksum on any dataset using
906 \fBzfs set checksum=sha512\fR. See zfs(8). This feature becomes
907 \fBactive\fR once a \fBchecksum\fR property has been set to \fBsha512\fR,
908 and will return to being \fBenabled\fR once all filesystems that have
909 ever had their checksum set to \fBsha512\fR are destroyed.
910 .RE
912 .sp
913 .ne 2
914 .na
915 \fBskein\fR
916 .ad
917 .RS 4n
918 .TS
919 l l .
920 GUID org.illumos:skein
921 READ\-ONLY COMPATIBLE no
922 DEPENDENCIES extensible_dataset
923 .TE
925 This feature enables the use of the Skein hash algorithm for checksum
926 and dedup. Skein is a high-performance secure hash algorithm that was a
927 finalist in the NIST SHA-3 competition. It provides a very high security
928 margin and high performance on 64-bit hardware (80% faster than
929 SHA-256). This implementation also utilizes the new salted checksumming
930 functionality in ZFS, which means that the checksum is pre-seeded with a
931 secret 256-bit random key (stored on the pool) before being fed the data
932 block to be checksummed. Thus the produced checksums are unique to a
933 given pool, preventing hash collision attacks on systems with dedup.
935 When the \fBskein\fR feature is set to \fBenabled\fR, the administrator
936 can turn on the \fBskein\fR checksum on any dataset using
937 \fBzfs set checksum=skein\fR. See zfs(8). This feature becomes
938 \fBactive\fR once a \fBchecksum\fR property has been set to \fBskein\fR,
939 and will return to being \fBenabled\fR once all filesystems that have
940 ever had their checksum set to \fBskein\fR are destroyed.
941 .RE
943 .sp
944 .ne 2
945 .na
946 \fBspacemap_histogram\fR
947 .ad
948 .RS 4n
949 .TS
950 l l .
951 GUID com.delphix:spacemap_histogram
952 READ\-ONLY COMPATIBLE yes
953 DEPENDENCIES none
954 .TE
956 This features allows ZFS to maintain more information about how free space
957 is organized within the pool. If this feature is \fBenabled\fR, ZFS will
958 set this feature to \fBactive\fR when a new space map object is created or
959 an existing space map is upgraded to the new format. Once the feature is
960 \fBactive\fR, it will remain in that state until the pool is destroyed.
961 .RE
963 .sp
964 .ne 2
965 .na
966 \fBspacemap_v2\fR
967 .ad
968 .RS 4n
969 .TS
970 l l .
971 GUID com.delphix:spacemap_v2
972 READ\-ONLY COMPATIBLE yes
973 DEPENDENCIES none
974 .TE
976 This feature enables the use of the new space map encoding which
977 consists of two words (instead of one) whenever it is advantageous.
978 The new encoding allows space maps to represent large regions of
979 space more efficiently on-disk while also increasing their maximum
980 addressable offset.
982 This feature becomes \fBactive\fR once it is \fBenabled\fR, and never
983 returns back to being \fBenabled\fR.
984 .RE
986 .sp
987 .ne 2
988 .na
989 \fBuserobj_accounting\fR
990 .ad
991 .RS 4n
992 .TS
993 l l .
994 GUID org.zfsonlinux:userobj_accounting
995 READ\-ONLY COMPATIBLE yes
996 DEPENDENCIES extensible_dataset
997 .TE
999 This feature allows administrators to account the object usage information
1000 by user and group.
1002 This feature becomes \fBactive\fR as soon as it is enabled and will never
1003 return to being \fBenabled\fR. Each filesystem will be upgraded automatically
1004 when remounted, or when new files are created under that filesystem.
1005 The upgrade can also be started manually on filesystems by running
1006 `zfs set version=current <pool/fs>`. The upgrade process runs in the background
1007 and may take a while to complete for filesystems containing a large number of
1008 files.
1009 .RE
1011 .sp
1012 .ne 2
1013 .na
1014 \fBzpool_checkpoint\fR
1015 .ad
1016 .RS 4n
1017 .TS
1018 l l .
1019 GUID com.delphix:zpool_checkpoint
1020 READ\-ONLY COMPATIBLE yes
1021 DEPENDENCIES none
1022 .TE
1024 This feature enables the \fBzpool checkpoint\fR subcommand that can
1025 checkpoint the state of the pool at the time it was issued and later
1026 rewind back to it or discard it.
1028 This feature becomes \fBactive\fR when the \fBzpool checkpoint\fR subcommand
1029 is used to checkpoint the pool.
1030 The feature will only return back to being \fBenabled\fR when the pool
1031 is rewound or the checkpoint has been discarded.
1032 .RE
1034 .sp
1035 .ne 2
1036 .na
1037 \fBzstd_compress\fR
1038 .ad
1039 .RS 4n
1040 .TS
1041 l l .
1042 GUID org.freebsd:zstd_compress
1043 READ\-ONLY COMPATIBLE no
1044 DEPENDENCIES extensible_dataset
1045 .TE
1047 \fBzstd\fR is a high-performance compression algorithm that features a
1048 combination of high compression ratios and high speed. Compared to \fBgzip\fR,
1049 \fBzstd\fR offers slighty better compression at much higher speeds. Compared
1050 to \fBlz4\fR, \fBzstd\fR offers much better compression while being only
1051 modestly slower. Typically, \fBzstd\fR compression speed ranges from 250 to 500
1052 MB/s per thread and decompression speed is over 1 GB/s per thread.
1054 When the \fBzstd\fR feature is set to \fBenabled\fR, the administrator can turn
1055 on \fBzstd\fR compression of any dataset by running
1056 `zfs set compress=zstd <pool/fs>`.
1058 This feature becomes \fBactive\fR once a \fBcompress\fR property has been set to
1059 \fBzstd\fR, and will return to being \fBenabled\fR once all filesystems that
1060 have ever had their compress property set to \fBzstd\fR are destroyed.
1062 Booting off of \fBzstd\fR-compressed root pools is not yet supported.
1063 .RE
1065 .SH "SEE ALSO"
1066 zpool(8)