Commits on Mar 12, 2020

1. deprecate deduplicated send streams …

   Dedup send can only deduplicate over the set of blocks in the send
   command being invoked, and it does not take advantage of the dedup table
   to do so. This is a very common misconception among not only users, but
   developers, and makes the feature seem more useful than it is. As a
   result, many users are using the feature but not getting any benefit
   from it.
   
   Dedup send requires a nontrivial expenditure of memory and CPU to
   operate, especially if the dataset(s) being sent is (are) not already
   using a dedup-strength checksum.
   
   Dedup send adds developer burden. It expands the test matrix when
   developing new features, causing bugs in released code, and delaying
   development efforts by forcing more testing to be done.
   
   As a result, we are deprecating the use of `zfs send -D` and receiving
   of such streams.  This change adds a warning to the man page, and also
   prints the warning whenever dedup send or receive are used.
   
   In a future release, we plan to:
   1. remove the kernel code for generating deduplicated streams
   2. make `zfs send -D` generate regular, non-deduplicated streams
   3. remove the kernel code for receiving deduplicated streams
   4. make `zfs receive` of deduplicated streams process them in userland
      to "re-duplicate" them, so that they can still be received.
   
   Closes openzfs#7887
   Signed-off-by: Matthew Ahrens <mahrens@delphix.com>

   

   ahrens committed Mar 12, 2020
   Configuration menu

   • View commit details
   • Copy full SHA for 3a81a56
   • Browse repository at this point

   Copy the full SHA

   3a81a56 View commit details

   Browse the repository at this point in the history