diff --git a/man/man8/zfs-receive.8 b/man/man8/zfs-receive.8
index 982e3b9616fc..36ed2050683a 100644
--- a/man/man8/zfs-receive.8
+++ b/man/man8/zfs-receive.8
@@ -1,385 +1,385 @@
 .\"
 .\" CDDL HEADER START
 .\"
 .\" 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]
 .\"
 .\" CDDL HEADER END
 .\"
 .\"
 .\" Copyright (c) 2009 Sun Microsystems, Inc. All Rights Reserved.
 .\" Copyright 2011 Joshua M. Clulow <josh@sysmgr.org>
 .\" Copyright (c) 2011, 2019 by Delphix. All rights reserved.
 .\" Copyright (c) 2013 by Saso Kiselkov. All rights reserved.
 .\" Copyright (c) 2014, Joyent, Inc. All rights reserved.
 .\" Copyright (c) 2014 by Adam Stevko. All rights reserved.
 .\" Copyright (c) 2014 Integros [integros.com]
 .\" Copyright 2019 Richard Laager. All rights reserved.
 .\" Copyright 2018 Nexenta Systems, Inc.
 .\" Copyright 2019 Joyent, Inc.
 .\"
 .Dd February 16, 2020
 .Dt ZFS-RECEIVE 8
 .Os
 .Sh NAME
 .Nm zfs-receive
 .Nd Creates a snapshot whose contents are as specified in the stream provided on standard input.
 .Sh SYNOPSIS
 .Nm zfs
 .Cm receive
 .Op Fl FhMnsuv
 .Op Fl o Sy origin Ns = Ns Ar snapshot
 .Op Fl o Ar property Ns = Ns Ar value
 .Op Fl x Ar property
 .Ar filesystem Ns | Ns Ar volume Ns | Ns Ar snapshot
 .Nm zfs
 .Cm receive
 .Op Fl FhMnsuv
 .Op Fl d Ns | Ns Fl e
 .Op Fl o Sy origin Ns = Ns Ar snapshot
 .Op Fl o Ar property Ns = Ns Ar value
 .Op Fl x Ar property
 .Ar filesystem
 .Nm zfs
 .Cm receive
 .Fl A
 .Ar filesystem Ns | Ns Ar volume
 .Sh DESCRIPTION
 .Bl -tag -width ""
 .It Xo
 .Nm zfs
 .Cm receive
 .Op Fl FhMnsuv
 .Op Fl o Sy origin Ns = Ns Ar snapshot
 .Op Fl o Ar property Ns = Ns Ar value
 .Op Fl x Ar property
 .Ar filesystem Ns | Ns Ar volume Ns | Ns Ar snapshot
 .Xc
 .It Xo
 .Nm zfs
 .Cm receive
 .Op Fl FhMnsuv
 .Op Fl d Ns | Ns Fl e
 .Op Fl o Sy origin Ns = Ns Ar snapshot
 .Op Fl o Ar property Ns = Ns Ar value
 .Op Fl x Ar property
 .Ar filesystem
 .Xc
 Creates a snapshot whose contents are as specified in the stream provided on
 standard input.
 If a full stream is received, then a new file system is created as well.
 Streams are created using the
 .Nm zfs Cm send
 subcommand, which by default creates a full stream.
 .Nm zfs Cm recv
 can be used as an alias for
 .Nm zfs Cm receive.
 .Pp
 If an incremental stream is received, then the destination file system must
 already exist, and its most recent snapshot must match the incremental stream's
 source.
 For
 .Sy zvols ,
 the destination device link is destroyed and recreated, which means the
 .Sy zvol
 cannot be accessed during the
 .Cm receive
 operation.
 .Pp
 When a snapshot replication package stream that is generated by using the
 .Nm zfs Cm send Fl R
 command is received, any snapshots that do not exist on the sending location are
 destroyed by using the
 .Nm zfs Cm destroy Fl d
 command.
 .Pp
 The ability to send and receive deduplicated send streams has been removed.
 However, a deduplicated send stream created with older software can be converted
 to a regular (non-deduplicated) stream by using the
 .Nm zstream Cm redup
 command.
 .Pp
 If
 .Fl o Em property Ns = Ns Ar value
 or
 .Fl x Em property
 is specified, it applies to the effective value of the property throughout
 the entire subtree of replicated datasets. Effective property values will be
 set (
 .Fl o
 ) or inherited (
 .Fl x
 ) on the topmost in the replicated subtree. In descendant datasets, if the
 property is set by the send stream, it will be overridden by forcing the
 property to be inherited from the top‐most file system. Received properties
 are retained in spite of being overridden and may be restored with
 .Nm zfs Cm inherit Fl S .
 Specifying
 .Fl o Sy origin Ns = Ns Em snapshot
 is a special case because, even if
 .Sy origin
 is a read-only property and cannot be set, it's allowed to receive the send
 stream as a clone of the given snapshot.
 .Pp
 Raw encrypted send streams (created with
 .Nm zfs Cm send Fl w
 ) may only be received as is, and cannot be re-encrypted, decrypted, or
 recompressed by the receive process. Unencrypted streams can be received as
 encrypted datasets, either through inheritance or by specifying encryption
 parameters with the
 .Fl o
 options. Note that the
 .Sy keylocation
 property cannot be overridden to
 .Sy prompt
 during a receive. This is because the receive process itself is already using
 stdin for the send stream. Instead, the property can be overridden after the
 receive completes.
 .Pp
 The added security provided by raw sends adds some restrictions to the send
 and receive process. ZFS will not allow a mix of raw receives and non-raw
 receives. Specifically, any raw incremental receives that are attempted after
 a non-raw receive will fail. Non-raw receives do not have this restriction and,
 therefore, are always possible. Because of this, it is best practice to always
 use either raw sends for their security benefits or non-raw sends for their
 flexibility when working with encrypted datasets, but not a combination.
 .Pp
 The reason for this restriction stems from the inherent restrictions of the
 AEAD ciphers that ZFS uses to encrypt data. When using ZFS native encryption,
 each block of data is encrypted against a randomly generated number known as
 the "initialization vector" (IV), which is stored in the filesystem metadata.
 This number is required by the encryption algorithms whenever the data is to
 be decrypted. Together, all of the IVs provided for all of the blocks in a
 given snapshot are collectively called an "IV set". When ZFS performs a raw
 send, the IV set is transferred from the source to the destination in the send
 stream. When ZFS performs a non-raw send, the data is decrypted by the source
 system and re-encrypted by the destination system, creating a snapshot with
 effectively the same data, but a different IV set. In order for decryption to
 work after a raw send, ZFS must ensure that the IV set used on both the source
 and destination side match. When an incremental raw receive is performed on
 top of an existing snapshot, ZFS will check to confirm that the "from"
 snapshot on both the source and destination were using the same IV set,
 ensuring the new IV set is consistent.
 .Pp
 The name of the snapshot
 .Pq and file system, if a full stream is received
 that this subcommand creates depends on the argument type and the use of the
 .Fl d
 or
 .Fl e
 options.
 .Pp
 If the argument is a snapshot name, the specified
 .Ar snapshot
 is created.
 If the argument is a file system or volume name, a snapshot with the same name
 as the sent snapshot is created within the specified
 .Ar filesystem
 or
 .Ar volume .
 If neither of the
 .Fl d
 or
 .Fl e
 options are specified, the provided target snapshot name is used exactly as
 provided.
 .Pp
 The
 .Fl d
 and
 .Fl e
 options cause the file system name of the target snapshot to be determined by
 appending a portion of the sent snapshot's name to the specified target
 .Ar filesystem .
 If the
 .Fl d
 option is specified, all but the first element of the sent snapshot's file
 system path
 .Pq usually the pool name
 is used and any required intermediate file systems within the specified one are
 created.
 If the
 .Fl e
 option is specified, then only the last element of the sent snapshot's file
 system name
 .Pq i.e. the name of the source file system itself
 is used as the target file system name.
 .Bl -tag -width "-F"
 .It Fl F
 Force a rollback of the file system to the most recent snapshot before
 performing the receive operation.
 If receiving an incremental replication stream
 .Po for example, one generated by
 .Nm zfs Cm send Fl R Op Fl i Ns | Ns Fl I
 .Pc ,
 destroy snapshots and file systems that do not exist on the sending side.
 .It Fl d
 Discard the first element of the sent snapshot's file system name, using the
 remaining elements to determine the name of the target file system for the new
 snapshot as described in the paragraph above.
 .It Fl e
 Discard all but the last element of the sent snapshot's file system name, using
 that element to determine the name of the target file system for the new
 snapshot as described in the paragraph above.
 .It Fl h
 Skip the receive of holds.  There is no effect if holds are not sent.
 .It Fl M
 Force an unmount of the file system while receiving a snapshot.
 This option is not supported on Linux.
 .It Fl n
 Do not actually receive the stream.
 This can be useful in conjunction with the
 .Fl v
 option to verify the name the receive operation would use.
 .It Fl o Sy origin Ns = Ns Ar snapshot
 Forces the stream to be received as a clone of the given snapshot.
 If the stream is a full send stream, this will create the filesystem
 described by the stream as a clone of the specified snapshot.
 Which snapshot was specified will not affect the success or failure of the
 receive, as long as the snapshot does exist.
 If the stream is an incremental send stream, all the normal verification will be
 performed.
 .It Fl o Em property Ns = Ns Ar value
 Sets the specified property as if the command
 .Nm zfs Cm set Em property Ns = Ns Ar value
 was invoked immediately before the receive. When receiving a stream from
 .Nm zfs Cm send Fl R ,
 causes the property to be inherited by all descendant datasets, as through
 .Nm zfs Cm inherit Em property
 was run on any descendant datasets that have this property set on the
 sending system.
 .Pp
-If the send stream was sent with 
+If the send stream was sent with
 .Fl c
-then overriding the 
-.Sy compression 
-property will have no affect on received data but the  
+then overriding the
 .Sy compression
-property will be set. To have the data recompressed on receive remove the 
-.Fl c 
-flag from the send stream.  
+property will have no affect on received data but the
+.Sy compression
+property will be set. To have the data recompressed on receive remove the
+.Fl c
+flag from the send stream.
 .Pp
 Any editable property can be set at receive time. Set-once properties bound
 to the received data, such as
 .Sy normalization
 and
 .Sy casesensitivity ,
 cannot be set at receive time even when the datasets are newly created by
 .Nm zfs Cm receive .
 Additionally both settable properties
 .Sy version
 and
 .Sy volsize
 cannot be set at receive time.
 .Pp
 The
 .Fl o
 option may be specified multiple times, for different properties. An error
 results if the same property is specified in multiple
 .Fl o
 or
 .Fl x
 options.
 .Pp
 The
 .Fl o
 option may also be used to override encryption properties upon initial
 receive. This allows unencrypted streams to be received as encrypted datasets.
 To cause the received dataset (or root dataset of a recursive stream) to be
 received as an encryption root, specify encryption properties in the same
 manner as is required for
 .Nm zfs
 .Cm create .
 For instance:
 .Bd -literal
 # zfs send tank/test@snap1 | zfs recv -o encryption=on -o keyformat=passphrase -o keylocation=file:///path/to/keyfile
 .Ed
 .Pp
 Note that
 .Op Fl o Ar keylocation Ns = Ns Ar prompt
 may not be specified here, since stdin is already being utilized for the send
 stream. Once the receive has completed, you can use
 .Nm zfs
 .Cm set
 to change this setting after the fact. Similarly, you can receive a dataset as
 an encrypted child by specifying
 .Op Fl x Ar encryption
 to force the property to be inherited. Overriding encryption properties (except
 for
 .Sy keylocation Ns )
 is not possible with raw send streams.
 .It Fl s
 If the receive is interrupted, save the partially received state, rather
 than deleting it.
 Interruption may be due to premature termination of the stream
 .Po e.g. due to network failure or failure of the remote system
 if the stream is being read over a network connection
 .Pc ,
 a checksum error in the stream, termination of the
 .Nm zfs Cm receive
 process, or unclean shutdown of the system.
 .Pp
 The receive can be resumed with a stream generated by
 .Nm zfs Cm send Fl t Ar token ,
 where the
 .Ar token
 is the value of the
 .Sy receive_resume_token
 property of the filesystem or volume which is received into.
 .Pp
 To use this flag, the storage pool must have the
 .Sy extensible_dataset
 feature enabled.
 See
 .Xr zpool-features 5
 for details on ZFS feature flags.
 .It Fl u
 File system that is associated with the received stream is not mounted.
 .It Fl v
 Print verbose information about the stream and the time required to perform the
 receive operation.
 .It Fl x Em property
 Ensures that the effective value of the specified property after the
 receive is unaffected by the value of that property in the send stream (if any),
 as if the property had been excluded from the send stream.
 .Pp
 If the specified property is not present in the send stream, this option does
 nothing.
 .Pp
 If a received property needs to be overridden, the effective value will be
 set or inherited, depending on whether the property is inheritable or not.
 .Pp
 In the case of an incremental update,
 .Fl x
 leaves any existing local setting or explicit inheritance unchanged.
 .Pp
 All
 .Fl o
 restrictions (e.g. set-once) apply equally to
 .Fl x .
 .El
 .It Xo
 .Nm zfs
 .Cm receive
 .Fl A
 .Ar filesystem Ns | Ns Ar volume
 .Xc
 Abort an interrupted
 .Nm zfs Cm receive Fl s ,
 deleting its saved partially received state.
 .El
 .Sh SEE ALSO
 .Xr zfs-send 8
 .Xr zstream 8
diff --git a/man/man8/zfs-send.8 b/man/man8/zfs-send.8
index 91c1484c73f6..4156db4f6b47 100644
--- a/man/man8/zfs-send.8
+++ b/man/man8/zfs-send.8
@@ -1,614 +1,614 @@
 .\"
 .\" CDDL HEADER START
 .\"
 .\" 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]
 .\"
 .\" CDDL HEADER END
 .\"
 .\"
 .\" Copyright (c) 2009 Sun Microsystems, Inc. All Rights Reserved.
 .\" Copyright 2011 Joshua M. Clulow <josh@sysmgr.org>
 .\" Copyright (c) 2011, 2019 by Delphix. All rights reserved.
 .\" Copyright (c) 2013 by Saso Kiselkov. All rights reserved.
 .\" Copyright (c) 2014, Joyent, Inc. All rights reserved.
 .\" Copyright (c) 2014 by Adam Stevko. All rights reserved.
 .\" Copyright (c) 2014 Integros [integros.com]
 .\" Copyright 2019 Richard Laager. All rights reserved.
 .\" Copyright 2018 Nexenta Systems, Inc.
 .\" Copyright 2019 Joyent, Inc.
 .\"
 .Dd June 30, 2019
 .Dt ZFS-SEND 8
 .Os
 .Sh NAME
 .Nm zfs-send
 .Nd Generate a send stream, which may be of a filesystem, and may be incremental from a bookmark.
 .Sh SYNOPSIS
 .Nm zfs
 .Cm send
 .Op Fl DLPRbcehnpvw
 .Op Oo Fl I Ns | Ns Fl i Oc Ar snapshot
 .Ar snapshot
 .Nm zfs
 .Cm send
 .Op Fl DLPRcenpvw
 .Op Fl i Ar snapshot Ns | Ns Ar bookmark
 .Ar filesystem Ns | Ns Ar volume Ns | Ns Ar snapshot
 .Nm zfs
 .Cm send
 .Fl -redact Ar redaction_bookmark
 .Op Fl DLPcenpv
 .br
 .Op Fl i Ar snapshot Ns | Ns Ar bookmark
 .Ar snapshot
 .Nm zfs
 .Cm send
 .Op Fl Penv
 .Fl t
 .Ar receive_resume_token
 .Nm zfs
 .Cm send
 .Op Fl Pnv
 .Fl S Ar filesystem
 .Nm zfs
 .Cm redact
 .Ar snapshot redaction_bookmark
 .Ar redaction_snapshot Ns ...
 .Sh DESCRIPTION
 .Bl -tag -width ""
 .It Xo
 .Nm zfs
 .Cm send
 .Op Fl DLPRbcehnpvw
 .Op Oo Fl I Ns | Ns Fl i Oc Ar snapshot
 .Ar snapshot
 .Xc
 Creates a stream representation of the second
 .Ar snapshot ,
 which is written to standard output.
 The output can be redirected to a file or to a different system
 .Po for example, using
 .Xr ssh 1
 .Pc .
 By default, a full stream is generated.
 .Bl -tag -width "-D"
 .It Fl D, -dedup
 Deduplicated send is no longer supported.
 This flag is accepted for backwards compatibility, but a regular,
 non-deduplicated stream will be generated.
 .It Fl I Ar snapshot
 Generate a stream package that sends all intermediary snapshots from the first
 snapshot to the second snapshot.
 For example,
 .Fl I Em @a Em fs@d
 is similar to
 .Fl i Em @a Em fs@b Ns \&; Fl i Em @b Em fs@c Ns \&; Fl i Em @c Em fs@d .
 The incremental source may be specified as with the
 .Fl i
 option.
 .It Fl L, -large-block
 Generate a stream which may contain blocks larger than 128KB.
 This flag has no effect if the
 .Sy large_blocks
 pool feature is disabled, or if the
 .Sy recordsize
 property of this filesystem has never been set above 128KB.
 The receiving system must have the
 .Sy large_blocks
 pool feature enabled as well.
 See
 .Xr zpool-features 5
 for details on ZFS feature flags and the
 .Sy large_blocks
 feature.
 .It Fl P, -parsable
 Print machine-parsable verbose information about the stream package generated.
 .It Fl R, -replicate
 Generate a replication stream package, which will replicate the specified
 file system, and all descendent file systems, up to the named snapshot.
 When received, all properties, snapshots, descendent file systems, and clones
 are preserved.
 .Pp
 If the
 .Fl i
 or
 .Fl I
 flags are used in conjunction with the
 .Fl R
 flag, an incremental replication stream is generated.
 The current values of properties, and current snapshot and file system names are
 set when the stream is received.
 If the
 .Fl F
 flag is specified when this stream is received, snapshots and file systems that
 do not exist on the sending side are destroyed. If the
 .Fl R
 flag is used to send encrypted datasets, then
 .Fl w
 must also be specified.
 .It Fl e, -embed
 Generate a more compact stream by using
 .Sy WRITE_EMBEDDED
 records for blocks which are stored more compactly on disk by the
 .Sy embedded_data
 pool feature.
 This flag has no effect if the
 .Sy embedded_data
 feature is disabled.
 The receiving system must have the
 .Sy embedded_data
 feature enabled.
 If the
 .Sy lz4_compress
 feature is active on the sending system, then the receiving system must have
 that feature enabled as well. Datasets that are sent with this flag may not be
 received as an encrypted dataset, since encrypted datasets cannot use the
 .Sy embedded_data
 feature.
 See
 .Xr zpool-features 5
 for details on ZFS feature flags and the
 .Sy embedded_data
 feature.
 .It Fl b, -backup
 Sends only received property values whether or not they are overridden by local
 settings, but only if the dataset has ever been received. Use this option when
 you want
 .Nm zfs Cm receive
 to restore received properties backed up on the sent dataset and to avoid
 sending local settings that may have nothing to do with the source dataset,
 but only with how the data is backed up.
 .It Fl c, -compressed
 Generate a more compact stream by using compressed WRITE records for blocks
 which are compressed on disk and in memory
 .Po see the
 .Sy compression
 property for details
 .Pc .
 If the
 .Sy lz4_compress
 feature is active on the sending system, then the receiving system must have
 that feature enabled as well.
 If the
 .Sy large_blocks
 feature is enabled on the sending system but the
 .Fl L
 option is not supplied in conjunction with
 .Fl c ,
 then the data will be decompressed before sending so it can be split into
-smaller block sizes. Streams sent with 
+smaller block sizes. Streams sent with
 .Fl c
 will not have their data recompressed on the receiver side using
 .Fl o compress=value.
 The data will stay compressed as it was from the sender. The new compression
-property will be set for future data. 
+property will be set for future data.
 .It Fl w, -raw
 For encrypted datasets, send data exactly as it exists on disk. This allows
 backups to be taken even if encryption keys are not currently loaded. The
 backup may then be received on an untrusted machine since that machine will
 not have the encryption keys to read the protected data or alter it without
 being detected. Upon being received, the dataset will have the same encryption
 keys as it did on the send side, although the
 .Sy keylocation
 property will be defaulted to
 .Sy prompt
 if not otherwise provided. For unencrypted datasets, this flag will be
 equivalent to
 .Fl Lec .
 Note that if you do not use this flag for sending encrypted datasets, data will
 be sent unencrypted and may be re-encrypted with a different encryption key on
 the receiving system, which will disable the ability to do a raw send to that
 system for incrementals.
 .It Fl h, -holds
 Generate a stream package that includes any snapshot holds (created with the
 .Sy zfs hold
 command), and indicating to
 .Sy zfs receive
 that the holds be applied to the dataset on the receiving system.
 .It Fl i Ar snapshot
 Generate an incremental stream from the first
 .Ar snapshot
 .Pq the incremental source
 to the second
 .Ar snapshot
 .Pq the incremental target .
 The incremental source can be specified as the last component of the snapshot
 name
 .Po the
 .Sy @
 character and following
 .Pc
 and it is assumed to be from the same file system as the incremental target.
 .Pp
 If the destination is a clone, the source may be the origin snapshot, which must
 be fully specified
 .Po for example,
 .Em pool/fs@origin ,
 not just
 .Em @origin
 .Pc .
 .It Fl n, -dryrun
 Do a dry-run
 .Pq Qq No-op
 send.
 Do not generate any actual send data.
 This is useful in conjunction with the
 .Fl v
 or
 .Fl P
 flags to determine what data will be sent.
 In this case, the verbose output will be written to standard output
 .Po contrast with a non-dry-run, where the stream is written to standard output
 and the verbose output goes to standard error
 .Pc .
 .It Fl p, -props
 Include the dataset's properties in the stream.
 This flag is implicit when
 .Fl R
 is specified.
 The receiving system must also support this feature. Sends of encrypted datasets
 must use
 .Fl w
 when using this flag.
 .It Fl v, -verbose
 Print verbose information about the stream package generated.
 This information includes a per-second report of how much data has been sent.
 .Pp
 The format of the stream is committed.
 You will be able to receive your streams on future versions of ZFS.
 .El
 .It Xo
 .Nm zfs
 .Cm send
 .Op Fl DLPRcenpvw
 .Op Fl i Ar snapshot Ns | Ns Ar bookmark
 .Ar filesystem Ns | Ns Ar volume Ns | Ns Ar snapshot
 .Xc
 Generate a send stream, which may be of a filesystem, and may be incremental
 from a bookmark.
 If the destination is a filesystem or volume, the pool must be read-only, or the
 filesystem must not be mounted.
 When the stream generated from a filesystem or volume is received, the default
 snapshot name will be
 .Qq --head-- .
 .Bl -tag -width "-L"
 .It Fl L, -large-block
 Generate a stream which may contain blocks larger than 128KB.
 This flag has no effect if the
 .Sy large_blocks
 pool feature is disabled, or if the
 .Sy recordsize
 property of this filesystem has never been set above 128KB.
 The receiving system must have the
 .Sy large_blocks
 pool feature enabled as well.
 See
 .Xr zpool-features 5
 for details on ZFS feature flags and the
 .Sy large_blocks
 feature.
 .It Fl P, -parsable
 Print machine-parsable verbose information about the stream package generated.
 .It Fl c, -compressed
 Generate a more compact stream by using compressed WRITE records for blocks
 which are compressed on disk and in memory
 .Po see the
 .Sy compression
 property for details
 .Pc .
 If the
 .Sy lz4_compress
 feature is active on the sending system, then the receiving system must have
 that feature enabled as well.
 If the
 .Sy large_blocks
 feature is enabled on the sending system but the
 .Fl L
 option is not supplied in conjunction with
 .Fl c ,
 then the data will be decompressed before sending so it can be split into
 smaller block sizes.
 .It Fl w, -raw
 For encrypted datasets, send data exactly as it exists on disk. This allows
 backups to be taken even if encryption keys are not currently loaded. The
 backup may then be received on an untrusted machine since that machine will
 not have the encryption keys to read the protected data or alter it without
 being detected. Upon being received, the dataset will have the same encryption
 keys as it did on the send side, although the
 .Sy keylocation
 property will be defaulted to
 .Sy prompt
 if not otherwise provided. For unencrypted datasets, this flag will be
 equivalent to
 .Fl Lec .
 Note that if you do not use this flag for sending encrypted datasets, data will
 be sent unencrypted and may be re-encrypted with a different encryption key on
 the receiving system, which will disable the ability to do a raw send to that
 system for incrementals.
 .It Fl e, -embed
 Generate a more compact stream by using
 .Sy WRITE_EMBEDDED
 records for blocks which are stored more compactly on disk by the
 .Sy embedded_data
 pool feature.
 This flag has no effect if the
 .Sy embedded_data
 feature is disabled.
 The receiving system must have the
 .Sy embedded_data
 feature enabled.
 If the
 .Sy lz4_compress
 feature is active on the sending system, then the receiving system must have
 that feature enabled as well. Datasets that are sent with this flag may not be
 received as an encrypted dataset, since encrypted datasets cannot use the
 .Sy embedded_data
 feature.
 See
 .Xr zpool-features 5
 for details on ZFS feature flags and the
 .Sy embedded_data
 feature.
 .It Fl i Ar snapshot Ns | Ns Ar bookmark
 Generate an incremental send stream.
 The incremental source must be an earlier snapshot in the destination's history.
 It will commonly be an earlier snapshot in the destination's file system, in
 which case it can be specified as the last component of the name
 .Po the
 .Sy #
 or
 .Sy @
 character and following
 .Pc .
 .Pp
 If the incremental target is a clone, the incremental source can be the origin
 snapshot, or an earlier snapshot in the origin's filesystem, or the origin's
 origin, etc.
 .It Fl n, -dryrun
 Do a dry-run
 .Pq Qq No-op
 send.
 Do not generate any actual send data.
 This is useful in conjunction with the
 .Fl v
 or
 .Fl P
 flags to determine what data will be sent.
 In this case, the verbose output will be written to standard output
 .Po contrast with a non-dry-run, where the stream is written to standard output
 and the verbose output goes to standard error
 .Pc .
 .It Fl v, -verbose
 Print verbose information about the stream package generated.
 This information includes a per-second report of how much data has been sent.
 .El
 .It Xo
 .Nm zfs
 .Cm send
 .Fl -redact Ar redaction_bookmark
 .Op Fl DLPcenpv
 .br
 .Op Fl i Ar snapshot Ns | Ns Ar bookmark
 .Ar snapshot
 .Xc
 Generate a redacted send stream.
 This send stream contains all blocks from the snapshot being sent that aren't
 included in the redaction list contained in the bookmark specified by the
 .Fl -redact
 (or
 .Fl -d
 ) flag.
 The resulting send stream is said to be redacted with respect to the snapshots
 the bookmark specified by the
 .Fl -redact No flag was created with.
 The bookmark must have been created by running
 .Sy zfs redact
 on the snapshot being sent.
 .sp
 This feature can be used to allow clones of a filesystem to be made available on
 a remote system, in the case where their parent need not (or needs to not) be
 usable.
 For example, if a filesystem contains sensitive data, and it has clones where
 that sensitive data has been secured or replaced with dummy data, redacted sends
 can be used to replicate the secured data without replicating the original
 sensitive data, while still sharing all possible blocks.
 A snapshot that has been redacted with respect to a set of snapshots will
 contain all blocks referenced by at least one snapshot in the set, but will
 contain none of the blocks referenced by none of the snapshots in the set.
 In other words, if all snapshots in the set have modified a given block in the
 parent, that block will not be sent; but if one or more snapshots have not
 modified a block in the parent, they will still reference the parent's block, so
 that block will be sent.
 Note that only user data will be redacted.
 .sp
 When the redacted send stream is received, we will generate a redacted
 snapshot.
 Due to the nature of redaction, a redacted dataset can only be used in the
 following ways:
 .sp
 1. To receive, as a clone, an incremental send from the original snapshot to one
 of the snapshots it was redacted with respect to.
 In this case, the stream will produce a valid dataset when received because all
 blocks that were redacted in the parent are guaranteed to be present in the
 child's send stream.
 This use case will produce a normal snapshot, which can be used just like other
 snapshots.
 .sp
 2. To receive an incremental send from the original snapshot to something
 redacted with respect to a subset of the set of snapshots the initial snapshot
 was redacted with respect to.
 In this case, each block that was redacted in the original is still redacted
 (redacting with respect to additional snapshots causes less data to be redacted
 (because the snapshots define what is permitted, and everything else is
 redacted)).
 This use case will produce a new redacted snapshot.
 .sp
 3. To receive an incremental send from a redaction bookmark of the original
 snapshot that was created when redacting with respect to a subset of the set of
 snapshots the initial snapshot was created with respect to
 anything else.
 A send stream from such a redaction bookmark will contain all of the blocks
 necessary to fill in any redacted data, should it be needed, because the sending
 system is aware of what blocks were originally redacted.
 This will either produce a normal snapshot or a redacted one, depending on
 whether the new send stream is redacted.
 .sp
 4. To receive an incremental send from a redacted version of the initial
 snapshot that is redacted with respect to a subject of the set of snapshots the
 initial snapshot was created with respect to.
 A send stream from a compatible redacted dataset will contain all of the blocks
 necessary to fill in any redacted data.
 This will either produce a normal snapshot or a redacted one, depending on
 whether the new send stream is redacted.
 .sp
 5. To receive a full send as a clone of the redacted snapshot.
 Since the stream is a full send, it definitionally contains all the data needed
 to create a new dataset.
 This use case will either produce a normal snapshot or a redacted one, depending
 on whether the full send stream was redacted.
 .sp
 These restrictions are detected and enforced by \fBzfs receive\fR; a
 redacted send stream will contain the list of snapshots that the stream is
 redacted with respect to.
 These are stored with the redacted snapshot, and are used to detect and
 correctly handle the cases above.  Note that for technical reasons, raw sends
 and redacted sends cannot be combined at this time.
 .It Xo
 .Nm zfs
 .Cm send
 .Op Fl Penv
 .Fl t
 .Ar receive_resume_token
 .Xc
 Creates a send stream which resumes an interrupted receive.
 The
 .Ar receive_resume_token
 is the value of this property on the filesystem or volume that was being
 received into.
 See the documentation for
 .Sy zfs receive -s
 for more details.
 .It Xo
 .Nm zfs
 .Cm send
 .Op Fl Pnv
 .Op Fl i Ar snapshot Ns | Ns Ar bookmark
 .Fl S
 .Ar filesystem
 .Xc
 Generate a send stream from a dataset that has been partially received.
 .Bl -tag -width "-L"
 .It Fl S, -saved
 This flag requires that the specified filesystem previously received a resumable
 send that did not finish and was interrupted. In such scenarios this flag
 enables the user to send this partially received state. Using this flag will
 always use the last fully received snapshot as the incremental source if it
 exists.
 .El
 .It Xo
 .Nm zfs
 .Cm redact
 .Ar snapshot redaction_bookmark
 .Ar redaction_snapshot Ns ...
 .Xc
 Generate a new redaction bookmark.
 In addition to the typical bookmark information, a redaction bookmark contains
 the list of redacted blocks and the list of redaction snapshots specified.
 The redacted blocks are blocks in the snapshot which are not referenced by any
 of the redaction snapshots.
 These blocks are found by iterating over the metadata in each redaction snapshot
 to determine what has been changed since the target snapshot.
 Redaction is designed to support redacted zfs sends; see the entry for
 .Sy zfs send
 for more information on the purpose of this operation.
 If a redact operation fails partway through (due to an error or a system
 failure), the redaction can be resumed by rerunning the same command.
 .El
 .Ss Redaction
 ZFS has support for a limited version of data subsetting, in the form of
 redaction. Using the
 .Sy zfs redact
 command, a
 .Sy redaction bookmark
 can be created that stores a list of blocks containing sensitive information. When
 provided to
 .Sy zfs
 .Sy send ,
 this causes a
 .Sy redacted send
 to occur. Redacted sends omit the blocks containing sensitive information,
 replacing them with REDACT records. When these send streams are received, a
 .Sy redacted dataset
 is created. A redacted dataset cannot be mounted by default, since it is
 incomplete. It can be used to receive other send streams. In this way datasets
 can be used for data backup and replication, with all the benefits that zfs send
 and receive have to offer, while protecting sensitive information from being
 stored on less-trusted machines or services.
 .Pp
 For the purposes of redaction, there are two steps to the process. A redact
 step, and a send/receive step. First, a redaction bookmark is created. This is
 done by providing the
 .Sy zfs redact
 command with a parent snapshot, a bookmark to be created, and a number of
 redaction snapshots. These redaction snapshots must be descendants of the
 parent snapshot, and they should modify data that is considered sensitive in
 some way. Any blocks of data modified by all of the redaction snapshots will
 be listed in the redaction bookmark, because it represents the truly sensitive
 information. When it comes to the send step, the send process will not send
 the blocks listed in the redaction bookmark, instead replacing them with
 REDACT records. When received on the target system, this will create a
 redacted dataset, missing the data that corresponds to the blocks in the
 redaction bookmark on the sending system. The incremental send streams from
 the original parent to the redaction snapshots can then also be received on
 the target system, and this will produce a complete snapshot that can be used
 normally. Incrementals from one snapshot on the parent filesystem and another
 can also be done by sending from the redaction bookmark, rather than the
 snapshots themselves.
 .Pp
 In order to make the purpose of the feature more clear, an example is
 provided. Consider a zfs filesystem containing four files. These files
 represent information for an online shopping service. One file contains a list
 of usernames and passwords, another contains purchase histories, a third
 contains click tracking data, and a fourth contains user preferences.  The
 owner of this data wants to make it available for their development teams to
 test against, and their market research teams to do analysis on.  The
 development teams need information about user preferences and the click
 tracking data, while the market research teams need information about purchase
 histories and user preferences. Neither needs access to the usernames and
 passwords. However, because all of this data is stored in one ZFS filesystem,
 it must all be sent and received together. In addition, the owner of the data
 wants to take advantage of features like compression, checksumming, and
 snapshots, so they do want to continue to use ZFS to store and transmit their
 data.  Redaction can help them do so. First, they would make two clones of a
 snapshot of the data on the source. In one clone, they create the setup they
 want their market research team to see; they delete the usernames and
 passwords file, and overwrite the click tracking data with dummy
 information. In another, they create the setup they want the development teams
 to see, by replacing the passwords with fake information and replacing the
 purchase histories with randomly generated ones.  They would then create a
 redaction bookmark on the parent snapshot, using snapshots on the two clones
 as redaction snapshots. The parent can then be sent, redacted, to the target
 server where the research and development teams have access. Finally,
 incremental sends from the parent snapshot to each of the clones can be send
 to and received on the target server; these snapshots are identical to the
 ones on the source, and are ready to be used, while the parent snapshot on the
 target contains none of the username and password data present on the source,
 because it was removed by the redacted send operation.
 .Sh SEE ALSO
 .Xr zfs-bookmark 8 ,
 .Xr zfs-receive 8 ,
 .Xr zfs-redact 8 ,
 .Xr zfs-snapshot 8