'zfs send' man page sync'ed with Illumos

* Move -R option up one position in the list to match
  the Illumos documentation.

* Move -D option up one position and refreshed it to
  match the Illumos documentation.

* Move -p option up one position and refreshed it to
  match the Illumos documentation.

* Add the -n, -P  documentation found in zfs receive
  in to zfs send where to belongs.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1187
This commit is contained in:
Steven Burgess 2012-12-28 16:53:18 -05:00 committed by Brian Behlendorf
parent 17836f0956
commit 9566fb1a7b

View File

@ -144,7 +144,7 @@ zfs \- configures ZFS file systems
.LP
.nf
\fBzfs\fR \fBsend\fR [\fB-DnPpRrv\fR] [\fB-\fR[\fBiI\fR] \fIsnapshot\fR] \fIsnapshot\fR
\fBzfs\fR \fBsend\fR [\fB-DnPpRv\fR] [\fB-\fR[\fBiI\fR] \fIsnapshot\fR] \fIsnapshot\fR
.fi
.LP
@ -2322,7 +2322,7 @@ Unshare the specified filesystem. The command can also be given a path to a \fBZ
.ne 2
.mk
.na
\fBzfs send\fR [\fB-DnPpRrv\fR] [\fB-\fR[\fBiI\fR] \fIsnapshot\fR] \fIsnapshot\fR
\fBzfs send\fR [\fB-DnPpRv\fR] [\fB-\fR[\fBiI\fR] \fIsnapshot\fR] \fIsnapshot\fR
.ad
.sp .6
.RS 4n
@ -2351,18 +2351,6 @@ If the destination is a clone, the source may be the origin snapshot, which must
Generate a stream package that sends all intermediary snapshots from the first snapshot to the second snapshot. For example, \fB-I @a fs@d\fR is similar to \fB-i @a fs@b; -i @b fs@c; -i @c fs@d\fR. The incremental source snapshot may be specified as with the \fB-i\fR option.
.RE
.sp
.ne 2
.mk
.na
\fB\fB-v\fR\fR
.ad
.sp .6
.RS 4n
Print verbose information about the stream package generated. This information
includes a per-second report of how much data has been sent.
.RE
.sp
.ne 2
.mk
@ -2384,9 +2372,7 @@ If the \fB-i\fR or \fB-I\fR flags are used in conjunction with the \fB-R\fR flag
.ad
.sp .6
.RS 4n
This option will cause dedup processing to be performed on the data being written to a send stream. Dedup processing is optional because it isn't always appropriate (some kinds of data have very little duplication) and it has significant costs: the checksumming required to detect duplicate blocks is CPU-intensive and the data that must be maintained while the stream is being processed can occupy a very large amount of memory.
.sp
Duplicate blocks are detected by calculating a cryptographically strong checksum on each data block. Blocks that have the same checksum are presumed to be identical. The checksum type used at this time is SHA256. However, the stream format contains a field which identifies the checksum type, permitting other checksums to be used in the future.
Generate a deduplicated stream. Blocks which would have been sent multiple times in the send stream will only be sent once. The receiving system must also support this feature to recieve a deduplicated stream. This flag can be used regardless of the dataset's dedup property, but performance will be much better if the filesystem uses a dedup-capable checksum (eg. sha256).
.RE
.sp
@ -2397,7 +2383,41 @@ Duplicate blocks are detected by calculating a cryptographically strong checksum
.ad
.sp .6
.RS 4n
Include properties in the send stream without the -R option.
Include the dataset's properties in the stream. This flag is implicit when -R is specified. The receiving system must also support this feature.
.RE
.sp
.ne 2
.na
\fB\fB-n\fR\fR
.ad
.sp .6
.RS 4n
Do a dry-run ("No-op") send. Do not generate any actual send data. This is
useful in conjunction with the \fB-v\fR or \fB-P\fR flags to determine what
data will be sent.
.RE
.sp
.ne 2
.na
\fB\fB-P\fR\fR
.ad
.sp .6
.RS 4n
Print machine-parsable verbose information about the stream package generated.
.RE
.sp
.ne 2
.mk
.na
\fB\fB-v\fR\fR
.ad
.sp .6
.RS 4n
Print verbose information about the stream package generated. This information
includes a per-second report of how much data has been sent.
.RE
The format of the stream is committed. You will be able to receive your streams on future versions of \fBZFS\fR.