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 

1 files changed, 84 insertions, 0 deletions

diff --git a/module/zfs/objlist.c b/module/zfs/objlist.c
new file mode 100644
index 000000000..c80bab2a7
--- /dev/null
+++ b/module/zfs/objlist.c
@@ -0,0 +1,84 @@
+/*
+ * CDDL HEADER START
+ *
+ * This file and its contents are supplied under the terms of the
+ * Common Development and Distribution License ("CDDL"), version 1.0.
+ * You may only use this file in accordance with the terms of version
+ * 1.0 of the CDDL.
+ *
+ * A full copy of the text of the CDDL should have accompanied this
+ * source.  A copy of the CDDL is also available via the Internet at
+ * http://www.illumos.org/license/CDDL.
+ *
+ * CDDL HEADER END
+ */
+/*
+ * Copyright (c) 2018 by Delphix. All rights reserved.
+ */
+
+#include	<sys/objlist.h>
+#include	<sys/zfs_context.h>
+
+objlist_t *
+objlist_create(void)
+{
+	objlist_t *list = kmem_alloc(sizeof (*list), KM_SLEEP);
+	list_create(&list->ol_list, sizeof (objlist_node_t),
+	    offsetof(objlist_node_t, on_node));
+	list->ol_last_lookup = 0;
+	return (list);
+}
+
+void
+objlist_destroy(objlist_t *list)
+{
+	for (objlist_node_t *n = list_remove_head(&list->ol_list);
+	    n != NULL; n = list_remove_head(&list->ol_list)) {
+		kmem_free(n, sizeof (*n));
+	}
+	list_destroy(&list->ol_list);
+	kmem_free(list, sizeof (*list));
+}
+
+/*
+ * This function looks through the objlist to see if the specified object number
+ * is contained in the objlist.  In the process, it will remove all object
+ * numbers in the list that are smaller than the specified object number.  Thus,
+ * any lookup of an object number smaller than a previously looked up object
+ * number will always return false; therefore, all lookups should be done in
+ * ascending order.
+ */
+boolean_t
+objlist_exists(objlist_t *list, uint64_t object)
+{
+	objlist_node_t *node = list_head(&list->ol_list);
+	ASSERT3U(object, >=, list->ol_last_lookup);
+	list->ol_last_lookup = object;
+	while (node != NULL && node->on_object < object) {
+		VERIFY3P(node, ==, list_remove_head(&list->ol_list));
+		kmem_free(node, sizeof (*node));
+		node = list_head(&list->ol_list);
+	}
+	return (node != NULL && node->on_object == object);
+}
+
+/*
+ * The objlist is a list of object numbers stored in ascending order.  However,
+ * the insertion of new object numbers does not seek out the correct location to
+ * store a new object number; instead, it appends it to the list for simplicity.
+ * Thus, any users must take care to only insert new object numbers in ascending
+ * order.
+ */
+void
+objlist_insert(objlist_t *list, uint64_t object)
+{
+	objlist_node_t *node = kmem_zalloc(sizeof (*node), KM_SLEEP);
+	node->on_object = object;
+#ifdef ZFS_DEBUG
+	objlist_node_t *last_object = list_tail(&list->ol_list);
+	uint64_t last_objnum = (last_object != NULL ? last_object->on_object :
+	    0);
+	ASSERT3U(node->on_object, >, last_objnum);
+#endif
+	list_insert_tail(&list->ol_list, node);
+}