+1 from this sysadmin.
On 2019-01-18 15:05, Garrett D'Amore wrote: > +1 from me. Does this need discussion within the OpenZFS group (or has it already had such?) > > Garrett > > FROM: Matthew Ahrens [1] > SENT: Friday, January 18, 2019 11:51 AM > TO: developer [2] > SUBJECT: [developer] proposal: remove dedupditto > > Happy Friday! > > I would like to propose that we remove the "dedupditto" zpool property and associated functionality. In the unlikely case that you know what this is, please read on and let me know what you think! I've opened a ZoL PR: https://github.com/zfsonlinux/zfs/pull/8310 [3]; feel free to comment there or here. > > Background and motivation: > > If dedup is in use, the dedupditto property can be set, causing ZFS to > keep an extra copy of data that is referenced many times (>100x). The > idea was that this data is more important than other data and thus we > want to be really sure that it is not lost if the disk experiences a > small amount of random corruption. > > ZFS (and system administrators) rely on the pool-level redundancy to > protect their data (e.g. mirroring or RAIDZ). Since the user/sysadmin > doesn't have control over what data will be offered extra redundancy by > dedupditto, this extra redundancy is not very useful. The bulk of the > data is still vulnerable to loss based on the pool-level redundancy. > For example, if particle strikes corrupt 0.1% of blocks, you will either > be saved by mirror/raidz, or you will be sad. This is true even if > dedupditto saved another 0.01% of blocks from being corrupted. > > Therefore, the dedupditto functionality is rarely enabled (i.e. the > property is rarely set), and it fulfills its promise of increased > redundancy even more rarely. > > Additionally, this feature does not work as advertised (on existing > releases), because scrub/resilver did not repair the extra (dedupditto) > copy (see #8270 [4]). > > In summary, this seldom-used feature doesn't work, and even if it did it > wouldn't provide useful data protection. It has a non-trivial > maintenance burden (again see #8270 [5]). > > Proposal: > > This change removes the dedupditto functionality. For backwards > compatibility with the existing CLI, "zpool set dedupditto" will still "succeed" (exit code zero), but won't have any effect. For backwards compatibility with existing pools that had dedupditto enabled at some point, the code will still be able to understand dedupditto blocks and free them when appropriate. However, ZFS won't write any new dedupditto > blocks. > > --matt > > / openzfs-developer / see discussions [6] + participants [7] + delivery options [8] Permalink [9] > > / openzfs-developer / see discussions [10] + participants [11] + delivery options [12] Permalink [13] Links: ------ [1] mailto:[email protected] [2] mailto:[email protected] [3] https://github.com/zfsonlinux/zfs/pull/8310 [4] https://github.com/zfsonlinux/zfs/pull/8270 [5] https://github.com/zfsonlinux/zfs/pull/8270 [6] https://openzfs.topicbox.com/groups/developer [7] https://openzfs.topicbox.com/groups/developer/members [8] https://openzfs.topicbox.com/groups/developer/subscription [9] https://openzfs.topicbox.com/groups/developer/Tef0e481b26ec467e-M7efd91fa2d854d6cea9daef8 [10] https://openzfs.topicbox.com/groups/developer [11] https://openzfs.topicbox.com/groups/developer/members [12] https://openzfs.topicbox.com/groups/developer/subscription [13] https://openzfs.topicbox.com/groups/developer/Tef0e481b26ec467e-M1f8582ae5b88b018876ebd5c ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/Tef0e481b26ec467e-M34f59819ace6ace0c45bca7d Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
