diff options
author | Brian Behlendorf <[email protected]> | 2019-05-07 15:18:44 -0700 |
---|---|---|
committer | GitHub <[email protected]> | 2019-05-07 15:18:44 -0700 |
commit | caf9dd209fdcfccabc2f32b3f23c5386ccfb896c (patch) | |
tree | 8df4542698b146a103602702113a55afba053e27 /man | |
parent | 9c53e51616c99592973ebf94b4fd54a5f8c8756d (diff) |
Fix send/recv lost spill block
When receiving a DRR_OBJECT record the receive_object() function
needs to determine how to handle a spill block associated with the
object. It may need to be removed or kept depending on how the
object was modified at the source.
This determination is currently accomplished using a heuristic which
takes in to account the DRR_OBJECT record and the existing object
properties. This is a problem because there isn't quite enough
information available to do the right thing under all circumstances.
For example, when only the block size changes the spill block is
removed when it should be kept.
What's needed to resolve this is an additional flag in the DRR_OBJECT
which indicates if the object being received references a spill block.
The DRR_OBJECT_SPILL flag was added for this purpose. When set then
the object references a spill block and it must be kept. Either
it is update to date, or it will be replaced by a subsequent DRR_SPILL
record. Conversely, if the object being received doesn't reference
a spill block then any existing spill block should always be removed.
Since previous versions of ZFS do not understand this new flag
additional DRR_SPILL records will be inserted in to the stream.
This has the advantage of being fully backward compatible. Existing
ZFS systems receiving this stream will recreate the spill block if
it was incorrectly removed. Updated ZFS versions will correctly
ignore the additional spill blocks which can be identified by
checking for the DRR_SPILL_UNMODIFIED flag.
The small downside to this approach is that is may increase the size
of the stream and of the received snapshot on previous versions of
ZFS. Additionally, when receiving streams generated by previous
unpatched versions of ZFS spill blocks may still be lost.
OpenZFS-issue: https://www.illumos.org/issues/9952
FreeBSD-issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233277
Reviewed-by: Paul Dagnelie <[email protected]>
Reviewed-by: Matt Ahrens <[email protected]>
Reviewed-by: Tom Caputi <[email protected]>
Signed-off-by: Brian Behlendorf <[email protected]>
Closes #8668
Diffstat (limited to 'man')
-rw-r--r-- | man/man5/zfs-module-parameters.5 | 16 |
1 files changed, 15 insertions, 1 deletions
diff --git a/man/man5/zfs-module-parameters.5 b/man/man5/zfs-module-parameters.5 index ad6cd4e94..5c49670f1 100644 --- a/man/man5/zfs-module-parameters.5 +++ b/man/man5/zfs-module-parameters.5 @@ -2340,6 +2340,21 @@ Use \fB1\fR for yes and \fB0\fR for no (default). .sp .ne 2 .na +\fBzfs_send_unmodified_spill_blocks\fR (int) +.ad +.RS 12n +Include unmodified spill blocks in the send stream. Under certain circumstances +previous versions of ZFS could incorrectly remove the spill block from an +existing object. Including unmodified copies of the spill blocks creates a +backwards compatible stream which will recreate a spill block if it was +incorrectly removed. +.sp +Use \fB1\fR for yes (default) and \fB0\fR for no. +.RE + +.sp +.ne 2 +.na \fBzfs_send_queue_length\fR (int) .ad .RS 12n @@ -2355,7 +2370,6 @@ Default value: \fB16,777,216\fR. \fBzfs_recv_queue_length\fR (int) .ad .RS 12n -.sp The maximum number of bytes allowed in the \fBzfs receive\fR queue. This value must be at least twice the maximum block size in use. .sp |