diff options
author | Paul Dagnelie <[email protected]> | 2019-06-19 09:48:13 -0700 |
---|---|---|
committer | Brian Behlendorf <[email protected]> | 2019-06-19 09:48:12 -0700 |
commit | 30af21b02569ac192f52ce6e6511015f8a8d5729 (patch) | |
tree | e5f1091c2d3a6e511bbd2414782e490c18e0f59c /module/zfs/refcount.c | |
parent | c1b5801bb5af0055e5f3d263beaa07026103e212 (diff) |
Implement Redacted Send/Receive
Redacted send/receive allows users to send subsets of their data to
a target system. One possible use case for this feature is to not
transmit sensitive information to a data warehousing, test/dev, or
analytics environment. Another is to save space by not replicating
unimportant data within a given dataset, for example in backup tools
like zrepl.
Redacted send/receive is a three-stage process. First, a clone (or
clones) is made of the snapshot to be sent to the target. In this
clone (or clones), all unnecessary or unwanted data is removed or
modified. This clone is then snapshotted to create the "redaction
snapshot" (or snapshots). Second, the new zfs redact command is used
to create a redaction bookmark. The redaction bookmark stores the
list of blocks in a snapshot that were modified by the redaction
snapshot(s). Finally, the redaction bookmark is passed as a parameter
to zfs send. When sending to the snapshot that was redacted, the
redaction bookmark is used to filter out blocks that contain sensitive
or unwanted information, and those blocks are not included in the send
stream. When sending from the redaction bookmark, the blocks it
contains are considered as candidate blocks in addition to those
blocks in the destination snapshot that were modified since the
creation_txg of the redaction bookmark. This step is necessary to
allow the target to rehydrate data in the case where some blocks are
accidentally or unnecessarily modified in the redaction snapshot.
The changes to bookmarks to enable fast space estimation involve
adding deadlists to bookmarks. There is also logic to manage the
life cycles of these deadlists.
The new size estimation process operates in cases where previously
an accurate estimate could not be provided. In those cases, a send
is performed where no data blocks are read, reducing the runtime
significantly and providing a byte-accurate size estimate.
Reviewed-by: Dan Kimmel <[email protected]>
Reviewed-by: Matt Ahrens <[email protected]>
Reviewed-by: Prashanth Sreenivasa <[email protected]>
Reviewed-by: John Kennedy <[email protected]>
Reviewed-by: George Wilson <[email protected]>
Reviewed-by: Chris Williamson <[email protected]>
Reviewed-by: Pavel Zhakarov <[email protected]>
Reviewed-by: Sebastien Roy <[email protected]>
Reviewed-by: Prakash Surya <[email protected]>
Reviewed-by: Brian Behlendorf <[email protected]>
Signed-off-by: Paul Dagnelie <[email protected]>
Closes #7958
Diffstat (limited to 'module/zfs/refcount.c')
-rw-r--r-- | module/zfs/refcount.c | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/module/zfs/refcount.c b/module/zfs/refcount.c index bcaa6d387..89528e6d3 100644 --- a/module/zfs/refcount.c +++ b/module/zfs/refcount.c @@ -86,7 +86,7 @@ zfs_refcount_destroy_many(zfs_refcount_t *rc, uint64_t number) { reference_t *ref; - ASSERT(rc->rc_count == number); + ASSERT3U(rc->rc_count, ==, number); while ((ref = list_head(&rc->rc_list))) { list_remove(&rc->rc_list, ref); kmem_cache_free(reference_cache, ref); @@ -132,7 +132,7 @@ zfs_refcount_add_many(zfs_refcount_t *rc, uint64_t number, void *holder) ref->ref_number = number; } mutex_enter(&rc->rc_mtx); - ASSERT(rc->rc_count >= 0); + ASSERT3U(rc->rc_count, >=, 0); if (rc->rc_tracked) list_insert_head(&rc->rc_list, ref); rc->rc_count += number; @@ -155,7 +155,7 @@ zfs_refcount_remove_many(zfs_refcount_t *rc, uint64_t number, void *holder) int64_t count; mutex_enter(&rc->rc_mtx); - ASSERT(rc->rc_count >= number); + ASSERT3U(rc->rc_count, >=, number); if (!rc->rc_tracked) { rc->rc_count -= number; |