2010-05-29 00:45:14 +04:00
|
|
|
/*
|
|
|
|
* CDDL HEADER START
|
|
|
|
*
|
|
|
|
* The contents of this file are subject to the terms of the
|
|
|
|
* Common Development and Distribution License (the "License").
|
|
|
|
* You may not use this file except in compliance with the License.
|
|
|
|
*
|
|
|
|
* You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
|
2022-07-12 00:16:13 +03:00
|
|
|
* or https://opensource.org/licenses/CDDL-1.0.
|
2010-05-29 00:45:14 +04:00
|
|
|
* See the License for the specific language governing permissions
|
|
|
|
* and limitations under the License.
|
|
|
|
*
|
|
|
|
* When distributing Covered Code, include this CDDL HEADER in each
|
|
|
|
* file and include the License file at usr/src/OPENSOLARIS.LICENSE.
|
|
|
|
* If applicable, add the following below this CDDL HEADER, with the
|
|
|
|
* fields enclosed by brackets "[]" replaced with your own identifying
|
|
|
|
* information: Portions Copyright [yyyy] [name of copyright owner]
|
|
|
|
*
|
|
|
|
* CDDL HEADER END
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Copyright (c) 2009, 2010, Oracle and/or its affiliates. All rights reserved.
|
2016-07-22 18:52:49 +03:00
|
|
|
* Copyright (c) 2012, 2016 by Delphix. All rights reserved.
|
2023-03-10 22:59:53 +03:00
|
|
|
* Copyright (c) 2022 by Pawel Jakub Dawidek
|
2024-07-26 19:16:18 +03:00
|
|
|
* Copyright (c) 2019, 2023, Klara Inc.
|
2010-05-29 00:45:14 +04:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <sys/zfs_context.h>
|
|
|
|
#include <sys/spa.h>
|
|
|
|
#include <sys/spa_impl.h>
|
|
|
|
#include <sys/zio.h>
|
|
|
|
#include <sys/ddt.h>
|
2023-06-30 06:35:18 +03:00
|
|
|
#include <sys/ddt_impl.h>
|
2010-05-29 00:45:14 +04:00
|
|
|
#include <sys/zap.h>
|
|
|
|
#include <sys/dmu_tx.h>
|
|
|
|
#include <sys/arc.h>
|
|
|
|
#include <sys/dsl_pool.h>
|
|
|
|
#include <sys/zio_checksum.h>
|
|
|
|
#include <sys/dsl_scan.h>
|
2016-07-22 18:52:49 +03:00
|
|
|
#include <sys/abd.h>
|
ddt: add FDT feature and support for legacy and new on-disk formats
This is the supporting infrastructure for the upcoming dedup features.
Traditionally, dedup objects live directly in the MOS root. While their
details vary (checksum, type and class), they are all the same "kind" of
thing - a store of dedup entries.
The new features are more varied than that, and are better thought of as
a set of related stores for the overall state of a dedup table.
This adds a new feature flag, SPA_FEATURE_FAST_DEDUP. Enabling this will
cause new DDTs to be created as a ZAP in the MOS root, named
DDT-<checksum>. The is used as the root object for the normal type/class
store objects, but will also be a place for any storage required by new
features.
This commit adds two new fields to ddt_t, for version and flags. These
are intended to describe the structure and features of the overall dedup
table, and are stored as-is in the DDT root. In this commit, flags are
always zero, but the intent is that they can be used to hang optional
logic or state onto for new dedup features. Version is always 1.
For a "legacy" dedup table, where no DDT root directory exists, the
version will be 0.
ddt_configure() is expected to determine the version and flags features
currently in operation based on whether or not the fast_dedup feature is
enabled, and from what's available on disk. In this way, its possible to
support both old and new tables.
This also provides a migration path. A legacy setup can be upgraded to
FDT by creating the DDT root ZAP, moving the existing objects into it,
and setting version and flags appropriately. There's no support for that
here, but it would be straightforward to add later and allows the
possibility that newer features could be applied to existing dedup
tables.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2023-06-20 05:06:13 +03:00
|
|
|
#include <sys/zfeature.h>
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2023-11-28 02:43:36 +03:00
|
|
|
/*
|
|
|
|
* # DDT: Deduplication tables
|
|
|
|
*
|
|
|
|
* The dedup subsystem provides block-level deduplication. When enabled, blocks
|
|
|
|
* to be written will have the dedup (D) bit set, which causes them to be
|
|
|
|
* tracked in a "dedup table", or DDT. If a block has been seen before (exists
|
|
|
|
* in the DDT), instead of being written, it will instead be made to reference
|
|
|
|
* the existing on-disk data, and a refcount bumped in the DDT instead.
|
|
|
|
*
|
|
|
|
* ## Dedup tables and entries
|
|
|
|
*
|
|
|
|
* Conceptually, a DDT is a dictionary or map. Each entry has a "key"
|
|
|
|
* (ddt_key_t) made up a block's checksum and certian properties, and a "value"
|
|
|
|
* (one or more ddt_phys_t) containing valid DVAs for the block's data, birth
|
|
|
|
* time and refcount. Together these are enough to track references to a
|
|
|
|
* specific block, to build a valid block pointer to reference that block (for
|
|
|
|
* freeing, scrubbing, etc), and to fill a new block pointer with the missing
|
|
|
|
* pieces to make it seem like it was written.
|
|
|
|
*
|
|
|
|
* There's a single DDT (ddt_t) for each checksum type, held in spa_ddt[].
|
|
|
|
* Within each DDT, there can be multiple storage "types" (ddt_type_t, on-disk
|
|
|
|
* object data formats, each with their own implementations) and "classes"
|
|
|
|
* (ddt_class_t, instance of a storage type object, for entries with a specific
|
|
|
|
* characteristic). An entry (key) will only ever exist on one of these objects
|
|
|
|
* at any given time, but may be moved from one to another if their type or
|
|
|
|
* class changes.
|
|
|
|
*
|
|
|
|
* The DDT is driven by the write IO pipeline (zio_ddt_write()). When a block
|
|
|
|
* is to be written, before DVAs have been allocated, ddt_lookup() is called to
|
|
|
|
* see if the block has been seen before. If its not found, the write proceeds
|
|
|
|
* as normal, and after it succeeds, a new entry is created. If it is found, we
|
|
|
|
* fill the BP with the DVAs from the entry, increment the refcount and cause
|
|
|
|
* the write IO to return immediately.
|
|
|
|
*
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
* Traditionally, each ddt_phys_t slot in the entry represents a separate dedup
|
|
|
|
* block for the same content/checksum. The slot is selected based on the
|
|
|
|
* zp_copies parameter the block is written with, that is, the number of DVAs
|
|
|
|
* in the block. The "ditto" slot (DDT_PHYS_DITTO) used to be used for
|
|
|
|
* now-removed "dedupditto" feature. These are no longer written, and will be
|
|
|
|
* freed if encountered on old pools.
|
|
|
|
*
|
|
|
|
* If the "fast_dedup" feature is enabled, new dedup tables will be created
|
|
|
|
* with the "flat phys" option. In this mode, there is only one ddt_phys_t
|
|
|
|
* slot. If a write is issued for an entry that exists, but has fewer DVAs,
|
|
|
|
* then only as many new DVAs are allocated and written to make up the
|
|
|
|
* shortfall. The existing entry is then extended (ddt_phys_extend()) with the
|
|
|
|
* new DVAs.
|
2023-11-28 02:43:36 +03:00
|
|
|
*
|
|
|
|
* ## Lifetime of an entry
|
|
|
|
*
|
|
|
|
* A DDT can be enormous, and typically is not held in memory all at once.
|
|
|
|
* Instead, the changes to an entry are tracked in memory, and written down to
|
|
|
|
* disk at the end of each txg.
|
|
|
|
*
|
|
|
|
* A "live" in-memory entry (ddt_entry_t) is a node on the live tree
|
|
|
|
* (ddt_tree). At the start of a txg, ddt_tree is empty. When an entry is
|
|
|
|
* required for IO, ddt_lookup() is called. If an entry already exists on
|
|
|
|
* ddt_tree, it is returned. Otherwise, a new one is created, and the
|
|
|
|
* type/class objects for the DDT are searched for that key. If its found, its
|
|
|
|
* value is copied into the live entry. If not, an empty entry is created.
|
|
|
|
*
|
|
|
|
* The live entry will be modified during the txg, usually by modifying the
|
|
|
|
* refcount, but sometimes by adding or updating DVAs. At the end of the txg
|
|
|
|
* (during spa_sync()), type and class are recalculated for entry (see
|
|
|
|
* ddt_sync_entry()), and the entry is written to the appropriate storage
|
|
|
|
* object and (if necessary), removed from an old one. ddt_tree is cleared and
|
|
|
|
* the next txg can start.
|
|
|
|
*
|
ddt: dedup table quota enforcement
This adds two new pool properties:
- dedup_table_size, the total size of all DDTs on the pool; and
- dedup_table_quota, the maximum possible size of all DDTs in the pool
When set, quota will be enforced by checking when a new entry is about
to be created. If the pool is over its dedup quota, the entry won't be
created, and the corresponding write will be converted to a regular
non-dedup write. Note that existing entries can be updated (ie their
refcounts changed), as that reuses the space rather than requiring more.
dedup_table_quota can be set to 'auto', which will set it based on the
size of the devices backing the "dedup" allocation device. This makes it
possible to limit the DDTs to the size of a dedup vdev only, such that
when the device fills, no new blocks are deduplicated.
Sponsored-by: iXsystems, Inc.
Sponsored-By: Klara Inc.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Signed-off-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Rob Wing <rob.wing@klarasystems.com>
Co-authored-by: Sean Eric Fagan <sean.fagan@klarasystems.com>
Closes #15889
2024-07-25 19:47:36 +03:00
|
|
|
* ## Dedup quota
|
|
|
|
*
|
|
|
|
* A maximum size for all DDTs on the pool can be set with the
|
|
|
|
* dedup_table_quota property. This is determined in ddt_over_quota() and
|
|
|
|
* enforced during ddt_lookup(). If the pool is at or over its quota limit,
|
|
|
|
* ddt_lookup() will only return entries for existing blocks, as updates are
|
|
|
|
* still possible. New entries will not be created; instead, ddt_lookup() will
|
|
|
|
* return NULL. In response, the DDT write stage (zio_ddt_write()) will remove
|
|
|
|
* the D bit on the block and reissue the IO as a regular write. The block will
|
|
|
|
* not be deduplicated.
|
|
|
|
*
|
|
|
|
* Note that this is based on the on-disk size of the dedup store. Reclaiming
|
|
|
|
* this space after deleting entries relies on the ZAP "shrinking" behaviour,
|
|
|
|
* without which, no space would be recovered and the DDT would continue to be
|
|
|
|
* considered "over quota". See zap_shrink_enabled.
|
|
|
|
*
|
2023-11-28 02:43:36 +03:00
|
|
|
* ## Repair IO
|
|
|
|
*
|
|
|
|
* If a read on a dedup block fails, but there are other copies of the block in
|
|
|
|
* the other ddt_phys_t slots, reads will be issued for those instead
|
|
|
|
* (zio_ddt_read_start()). If one of those succeeds, the read is returned to
|
|
|
|
* the caller, and a copy is stashed on the entry's dde_repair_abd.
|
|
|
|
*
|
|
|
|
* During the end-of-txg sync, any entries with a dde_repair_abd get a
|
|
|
|
* "rewrite" write issued for the original block pointer, with the data read
|
|
|
|
* from the alternate block. If the block is actually damaged, this will invoke
|
|
|
|
* the pool's "self-healing" mechanism, and repair the block.
|
|
|
|
*
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
* If the "fast_dedup" feature is enabled, the "flat phys" option will be in
|
|
|
|
* use, so there is only ever one ddt_phys_t slot. The repair process will
|
|
|
|
* still happen in this case, though it is unlikely to succeed as there will
|
|
|
|
* usually be no other equivalent blocks to fall back on (though there might
|
|
|
|
* be, if this was an early version of a dedup'd block that has since been
|
|
|
|
* extended).
|
|
|
|
*
|
|
|
|
* Note that this repair mechanism is in addition to and separate from the
|
|
|
|
* regular OpenZFS scrub and self-healing mechanisms.
|
|
|
|
*
|
2023-11-28 02:43:36 +03:00
|
|
|
* ## Scanning (scrub/resilver)
|
|
|
|
*
|
|
|
|
* If dedup is active, the scrub machinery will walk the dedup table first, and
|
|
|
|
* scrub all blocks with refcnt > 1 first. After that it will move on to the
|
|
|
|
* regular top-down scrub, and exclude the refcnt > 1 blocks when it sees them.
|
|
|
|
* In this way, heavily deduplicated blocks are only scrubbed once. See the
|
|
|
|
* commentary on dsl_scan_ddt() for more details.
|
|
|
|
*
|
|
|
|
* Walking the DDT is done via ddt_walk(). The current position is stored in a
|
|
|
|
* ddt_bookmark_t, which represents a stable position in the storage object.
|
|
|
|
* This bookmark is stored by the scan machinery, and must reference the same
|
|
|
|
* position on the object even if the object changes, the pool is exported, or
|
|
|
|
* OpenZFS is upgraded.
|
|
|
|
*
|
|
|
|
* ## Interaction with block cloning
|
|
|
|
*
|
|
|
|
* If block cloning and dedup are both enabled on a pool, BRT will look for the
|
|
|
|
* dedup bit on an incoming block pointer. If set, it will call into the DDT
|
|
|
|
* (ddt_addref()) to add a reference to the block, instead of adding a
|
|
|
|
* reference to the BRT. See brt_pending_apply().
|
|
|
|
*/
|
|
|
|
|
2024-02-01 03:05:18 +03:00
|
|
|
/*
|
|
|
|
* These are the only checksums valid for dedup. They must match the list
|
|
|
|
* from dedup_table in zfs_prop.c
|
|
|
|
*/
|
|
|
|
#define DDT_CHECKSUM_VALID(c) \
|
|
|
|
(c == ZIO_CHECKSUM_SHA256 || c == ZIO_CHECKSUM_SHA512 || \
|
|
|
|
c == ZIO_CHECKSUM_SKEIN || c == ZIO_CHECKSUM_EDONR || \
|
|
|
|
c == ZIO_CHECKSUM_BLAKE3)
|
|
|
|
|
2013-11-20 01:34:46 +04:00
|
|
|
static kmem_cache_t *ddt_cache;
|
|
|
|
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
static kmem_cache_t *ddt_entry_flat_cache;
|
|
|
|
static kmem_cache_t *ddt_entry_trad_cache;
|
|
|
|
|
|
|
|
#define DDT_ENTRY_FLAT_SIZE (sizeof (ddt_entry_t) + DDT_FLAT_PHYS_SIZE)
|
|
|
|
#define DDT_ENTRY_TRAD_SIZE (sizeof (ddt_entry_t) + DDT_TRAD_PHYS_SIZE)
|
|
|
|
|
|
|
|
#define DDT_ENTRY_SIZE(ddt) \
|
|
|
|
_DDT_PHYS_SWITCH(ddt, DDT_ENTRY_FLAT_SIZE, DDT_ENTRY_TRAD_SIZE)
|
2023-07-03 12:54:40 +03:00
|
|
|
|
2010-08-27 01:24:34 +04:00
|
|
|
/*
|
|
|
|
* Enable/disable prefetching of dedup-ed blocks which are going to be freed.
|
|
|
|
*/
|
2014-08-30 06:13:26 +04:00
|
|
|
int zfs_dedup_prefetch = 0;
|
2010-08-27 01:24:34 +04:00
|
|
|
|
ddt: dedup table quota enforcement
This adds two new pool properties:
- dedup_table_size, the total size of all DDTs on the pool; and
- dedup_table_quota, the maximum possible size of all DDTs in the pool
When set, quota will be enforced by checking when a new entry is about
to be created. If the pool is over its dedup quota, the entry won't be
created, and the corresponding write will be converted to a regular
non-dedup write. Note that existing entries can be updated (ie their
refcounts changed), as that reuses the space rather than requiring more.
dedup_table_quota can be set to 'auto', which will set it based on the
size of the devices backing the "dedup" allocation device. This makes it
possible to limit the DDTs to the size of a dedup vdev only, such that
when the device fills, no new blocks are deduplicated.
Sponsored-by: iXsystems, Inc.
Sponsored-By: Klara Inc.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Signed-off-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Rob Wing <rob.wing@klarasystems.com>
Co-authored-by: Sean Eric Fagan <sean.fagan@klarasystems.com>
Closes #15889
2024-07-25 19:47:36 +03:00
|
|
|
/*
|
|
|
|
* If the dedup class cannot satisfy a DDT allocation, treat as over quota
|
|
|
|
* for this many TXGs.
|
|
|
|
*/
|
|
|
|
uint_t dedup_class_wait_txgs = 5;
|
|
|
|
|
|
|
|
|
2022-02-25 16:26:54 +03:00
|
|
|
static const ddt_ops_t *const ddt_ops[DDT_TYPES] = {
|
2010-05-29 00:45:14 +04:00
|
|
|
&ddt_zap_ops,
|
|
|
|
};
|
|
|
|
|
2022-02-25 16:26:54 +03:00
|
|
|
static const char *const ddt_class_name[DDT_CLASSES] = {
|
2010-05-29 00:45:14 +04:00
|
|
|
"ditto",
|
|
|
|
"duplicate",
|
|
|
|
"unique",
|
|
|
|
};
|
|
|
|
|
ddt: add FDT feature and support for legacy and new on-disk formats
This is the supporting infrastructure for the upcoming dedup features.
Traditionally, dedup objects live directly in the MOS root. While their
details vary (checksum, type and class), they are all the same "kind" of
thing - a store of dedup entries.
The new features are more varied than that, and are better thought of as
a set of related stores for the overall state of a dedup table.
This adds a new feature flag, SPA_FEATURE_FAST_DEDUP. Enabling this will
cause new DDTs to be created as a ZAP in the MOS root, named
DDT-<checksum>. The is used as the root object for the normal type/class
store objects, but will also be a place for any storage required by new
features.
This commit adds two new fields to ddt_t, for version and flags. These
are intended to describe the structure and features of the overall dedup
table, and are stored as-is in the DDT root. In this commit, flags are
always zero, but the intent is that they can be used to hang optional
logic or state onto for new dedup features. Version is always 1.
For a "legacy" dedup table, where no DDT root directory exists, the
version will be 0.
ddt_configure() is expected to determine the version and flags features
currently in operation based on whether or not the fast_dedup feature is
enabled, and from what's available on disk. In this way, its possible to
support both old and new tables.
This also provides a migration path. A legacy setup can be upgraded to
FDT by creating the DDT root ZAP, moving the existing objects into it,
and setting version and flags appropriately. There's no support for that
here, but it would be straightforward to add later and allows the
possibility that newer features could be applied to existing dedup
tables.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2023-06-20 05:06:13 +03:00
|
|
|
/*
|
|
|
|
* DDT feature flags automatically enabled for each on-disk version. Note that
|
|
|
|
* versions >0 cannot exist on disk without SPA_FEATURE_FAST_DEDUP enabled.
|
|
|
|
*/
|
|
|
|
static const uint64_t ddt_version_flags[] = {
|
|
|
|
[DDT_VERSION_LEGACY] = 0,
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
[DDT_VERSION_FDT] = DDT_FLAG_FLAT,
|
ddt: add FDT feature and support for legacy and new on-disk formats
This is the supporting infrastructure for the upcoming dedup features.
Traditionally, dedup objects live directly in the MOS root. While their
details vary (checksum, type and class), they are all the same "kind" of
thing - a store of dedup entries.
The new features are more varied than that, and are better thought of as
a set of related stores for the overall state of a dedup table.
This adds a new feature flag, SPA_FEATURE_FAST_DEDUP. Enabling this will
cause new DDTs to be created as a ZAP in the MOS root, named
DDT-<checksum>. The is used as the root object for the normal type/class
store objects, but will also be a place for any storage required by new
features.
This commit adds two new fields to ddt_t, for version and flags. These
are intended to describe the structure and features of the overall dedup
table, and are stored as-is in the DDT root. In this commit, flags are
always zero, but the intent is that they can be used to hang optional
logic or state onto for new dedup features. Version is always 1.
For a "legacy" dedup table, where no DDT root directory exists, the
version will be 0.
ddt_configure() is expected to determine the version and flags features
currently in operation based on whether or not the fast_dedup feature is
enabled, and from what's available on disk. In this way, its possible to
support both old and new tables.
This also provides a migration path. A legacy setup can be upgraded to
FDT by creating the DDT root ZAP, moving the existing objects into it,
and setting version and flags appropriately. There's no support for that
here, but it would be straightforward to add later and allows the
possibility that newer features could be applied to existing dedup
tables.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2023-06-20 05:06:13 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
/* Dummy version to signal that configure is still necessary */
|
|
|
|
#define DDT_VERSION_UNCONFIGURED (UINT64_MAX)
|
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
static void
|
2023-07-03 05:32:53 +03:00
|
|
|
ddt_object_create(ddt_t *ddt, ddt_type_t type, ddt_class_t class,
|
2010-05-29 00:45:14 +04:00
|
|
|
dmu_tx_t *tx)
|
|
|
|
{
|
|
|
|
spa_t *spa = ddt->ddt_spa;
|
|
|
|
objset_t *os = ddt->ddt_os;
|
|
|
|
uint64_t *objectp = &ddt->ddt_object[type][class];
|
2016-06-16 01:47:05 +03:00
|
|
|
boolean_t prehash = zio_checksum_table[ddt->ddt_checksum].ci_flags &
|
|
|
|
ZCHECKSUM_FLAG_DEDUP;
|
2010-05-29 00:45:14 +04:00
|
|
|
char name[DDT_NAMELEN];
|
|
|
|
|
ddt: add FDT feature and support for legacy and new on-disk formats
This is the supporting infrastructure for the upcoming dedup features.
Traditionally, dedup objects live directly in the MOS root. While their
details vary (checksum, type and class), they are all the same "kind" of
thing - a store of dedup entries.
The new features are more varied than that, and are better thought of as
a set of related stores for the overall state of a dedup table.
This adds a new feature flag, SPA_FEATURE_FAST_DEDUP. Enabling this will
cause new DDTs to be created as a ZAP in the MOS root, named
DDT-<checksum>. The is used as the root object for the normal type/class
store objects, but will also be a place for any storage required by new
features.
This commit adds two new fields to ddt_t, for version and flags. These
are intended to describe the structure and features of the overall dedup
table, and are stored as-is in the DDT root. In this commit, flags are
always zero, but the intent is that they can be used to hang optional
logic or state onto for new dedup features. Version is always 1.
For a "legacy" dedup table, where no DDT root directory exists, the
version will be 0.
ddt_configure() is expected to determine the version and flags features
currently in operation based on whether or not the fast_dedup feature is
enabled, and from what's available on disk. In this way, its possible to
support both old and new tables.
This also provides a migration path. A legacy setup can be upgraded to
FDT by creating the DDT root ZAP, moving the existing objects into it,
and setting version and flags appropriately. There's no support for that
here, but it would be straightforward to add later and allows the
possibility that newer features could be applied to existing dedup
tables.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2023-06-20 05:06:13 +03:00
|
|
|
ASSERT3U(ddt->ddt_dir_object, >, 0);
|
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
ddt_object_name(ddt, type, class, name);
|
|
|
|
|
2024-02-15 11:37:38 +03:00
|
|
|
ASSERT3U(*objectp, ==, 0);
|
|
|
|
VERIFY0(ddt_ops[type]->ddt_op_create(os, objectp, tx, prehash));
|
|
|
|
ASSERT3U(*objectp, !=, 0);
|
2010-05-29 00:45:14 +04:00
|
|
|
|
ddt: add FDT feature and support for legacy and new on-disk formats
This is the supporting infrastructure for the upcoming dedup features.
Traditionally, dedup objects live directly in the MOS root. While their
details vary (checksum, type and class), they are all the same "kind" of
thing - a store of dedup entries.
The new features are more varied than that, and are better thought of as
a set of related stores for the overall state of a dedup table.
This adds a new feature flag, SPA_FEATURE_FAST_DEDUP. Enabling this will
cause new DDTs to be created as a ZAP in the MOS root, named
DDT-<checksum>. The is used as the root object for the normal type/class
store objects, but will also be a place for any storage required by new
features.
This commit adds two new fields to ddt_t, for version and flags. These
are intended to describe the structure and features of the overall dedup
table, and are stored as-is in the DDT root. In this commit, flags are
always zero, but the intent is that they can be used to hang optional
logic or state onto for new dedup features. Version is always 1.
For a "legacy" dedup table, where no DDT root directory exists, the
version will be 0.
ddt_configure() is expected to determine the version and flags features
currently in operation based on whether or not the fast_dedup feature is
enabled, and from what's available on disk. In this way, its possible to
support both old and new tables.
This also provides a migration path. A legacy setup can be upgraded to
FDT by creating the DDT root ZAP, moving the existing objects into it,
and setting version and flags appropriately. There's no support for that
here, but it would be straightforward to add later and allows the
possibility that newer features could be applied to existing dedup
tables.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2023-06-20 05:06:13 +03:00
|
|
|
ASSERT3U(ddt->ddt_version, !=, DDT_VERSION_UNCONFIGURED);
|
|
|
|
|
|
|
|
VERIFY0(zap_add(os, ddt->ddt_dir_object, name, sizeof (uint64_t), 1,
|
|
|
|
objectp, tx));
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2024-02-15 11:37:38 +03:00
|
|
|
VERIFY0(zap_add(os, spa->spa_ddt_stat_object, name,
|
2010-05-29 00:45:14 +04:00
|
|
|
sizeof (uint64_t), sizeof (ddt_histogram_t) / sizeof (uint64_t),
|
2024-02-15 11:37:38 +03:00
|
|
|
&ddt->ddt_histogram[type][class], tx));
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2023-07-03 05:32:53 +03:00
|
|
|
ddt_object_destroy(ddt_t *ddt, ddt_type_t type, ddt_class_t class,
|
2010-05-29 00:45:14 +04:00
|
|
|
dmu_tx_t *tx)
|
|
|
|
{
|
|
|
|
spa_t *spa = ddt->ddt_spa;
|
|
|
|
objset_t *os = ddt->ddt_os;
|
|
|
|
uint64_t *objectp = &ddt->ddt_object[type][class];
|
2012-10-26 21:01:49 +04:00
|
|
|
uint64_t count;
|
2010-05-29 00:45:14 +04:00
|
|
|
char name[DDT_NAMELEN];
|
|
|
|
|
ddt: add FDT feature and support for legacy and new on-disk formats
This is the supporting infrastructure for the upcoming dedup features.
Traditionally, dedup objects live directly in the MOS root. While their
details vary (checksum, type and class), they are all the same "kind" of
thing - a store of dedup entries.
The new features are more varied than that, and are better thought of as
a set of related stores for the overall state of a dedup table.
This adds a new feature flag, SPA_FEATURE_FAST_DEDUP. Enabling this will
cause new DDTs to be created as a ZAP in the MOS root, named
DDT-<checksum>. The is used as the root object for the normal type/class
store objects, but will also be a place for any storage required by new
features.
This commit adds two new fields to ddt_t, for version and flags. These
are intended to describe the structure and features of the overall dedup
table, and are stored as-is in the DDT root. In this commit, flags are
always zero, but the intent is that they can be used to hang optional
logic or state onto for new dedup features. Version is always 1.
For a "legacy" dedup table, where no DDT root directory exists, the
version will be 0.
ddt_configure() is expected to determine the version and flags features
currently in operation based on whether or not the fast_dedup feature is
enabled, and from what's available on disk. In this way, its possible to
support both old and new tables.
This also provides a migration path. A legacy setup can be upgraded to
FDT by creating the DDT root ZAP, moving the existing objects into it,
and setting version and flags appropriately. There's no support for that
here, but it would be straightforward to add later and allows the
possibility that newer features could be applied to existing dedup
tables.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2023-06-20 05:06:13 +03:00
|
|
|
ASSERT3U(ddt->ddt_dir_object, >, 0);
|
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
ddt_object_name(ddt, type, class, name);
|
|
|
|
|
2024-02-15 11:37:38 +03:00
|
|
|
ASSERT3U(*objectp, !=, 0);
|
2010-05-29 00:45:14 +04:00
|
|
|
ASSERT(ddt_histogram_empty(&ddt->ddt_histogram[type][class]));
|
2024-02-15 11:37:38 +03:00
|
|
|
VERIFY0(ddt_object_count(ddt, type, class, &count));
|
|
|
|
VERIFY0(count);
|
ddt: add FDT feature and support for legacy and new on-disk formats
This is the supporting infrastructure for the upcoming dedup features.
Traditionally, dedup objects live directly in the MOS root. While their
details vary (checksum, type and class), they are all the same "kind" of
thing - a store of dedup entries.
The new features are more varied than that, and are better thought of as
a set of related stores for the overall state of a dedup table.
This adds a new feature flag, SPA_FEATURE_FAST_DEDUP. Enabling this will
cause new DDTs to be created as a ZAP in the MOS root, named
DDT-<checksum>. The is used as the root object for the normal type/class
store objects, but will also be a place for any storage required by new
features.
This commit adds two new fields to ddt_t, for version and flags. These
are intended to describe the structure and features of the overall dedup
table, and are stored as-is in the DDT root. In this commit, flags are
always zero, but the intent is that they can be used to hang optional
logic or state onto for new dedup features. Version is always 1.
For a "legacy" dedup table, where no DDT root directory exists, the
version will be 0.
ddt_configure() is expected to determine the version and flags features
currently in operation based on whether or not the fast_dedup feature is
enabled, and from what's available on disk. In this way, its possible to
support both old and new tables.
This also provides a migration path. A legacy setup can be upgraded to
FDT by creating the DDT root ZAP, moving the existing objects into it,
and setting version and flags appropriately. There's no support for that
here, but it would be straightforward to add later and allows the
possibility that newer features could be applied to existing dedup
tables.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2023-06-20 05:06:13 +03:00
|
|
|
VERIFY0(zap_remove(os, ddt->ddt_dir_object, name, tx));
|
2024-02-15 11:37:38 +03:00
|
|
|
VERIFY0(zap_remove(os, spa->spa_ddt_stat_object, name, tx));
|
|
|
|
VERIFY0(ddt_ops[type]->ddt_op_destroy(os, *objectp, tx));
|
2022-02-25 16:26:54 +03:00
|
|
|
memset(&ddt->ddt_object_stats[type][class], 0, sizeof (ddt_object_t));
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
*objectp = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2023-07-03 05:32:53 +03:00
|
|
|
ddt_object_load(ddt_t *ddt, ddt_type_t type, ddt_class_t class)
|
2010-05-29 00:45:14 +04:00
|
|
|
{
|
|
|
|
ddt_object_t *ddo = &ddt->ddt_object_stats[type][class];
|
|
|
|
dmu_object_info_t doi;
|
2012-10-26 21:01:49 +04:00
|
|
|
uint64_t count;
|
2010-05-29 00:45:14 +04:00
|
|
|
char name[DDT_NAMELEN];
|
|
|
|
int error;
|
|
|
|
|
ddt: add FDT feature and support for legacy and new on-disk formats
This is the supporting infrastructure for the upcoming dedup features.
Traditionally, dedup objects live directly in the MOS root. While their
details vary (checksum, type and class), they are all the same "kind" of
thing - a store of dedup entries.
The new features are more varied than that, and are better thought of as
a set of related stores for the overall state of a dedup table.
This adds a new feature flag, SPA_FEATURE_FAST_DEDUP. Enabling this will
cause new DDTs to be created as a ZAP in the MOS root, named
DDT-<checksum>. The is used as the root object for the normal type/class
store objects, but will also be a place for any storage required by new
features.
This commit adds two new fields to ddt_t, for version and flags. These
are intended to describe the structure and features of the overall dedup
table, and are stored as-is in the DDT root. In this commit, flags are
always zero, but the intent is that they can be used to hang optional
logic or state onto for new dedup features. Version is always 1.
For a "legacy" dedup table, where no DDT root directory exists, the
version will be 0.
ddt_configure() is expected to determine the version and flags features
currently in operation based on whether or not the fast_dedup feature is
enabled, and from what's available on disk. In this way, its possible to
support both old and new tables.
This also provides a migration path. A legacy setup can be upgraded to
FDT by creating the DDT root ZAP, moving the existing objects into it,
and setting version and flags appropriately. There's no support for that
here, but it would be straightforward to add later and allows the
possibility that newer features could be applied to existing dedup
tables.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2023-06-20 05:06:13 +03:00
|
|
|
if (ddt->ddt_dir_object == 0) {
|
|
|
|
/*
|
|
|
|
* If we're configured but the containing dir doesn't exist
|
|
|
|
* yet, then this object can't possibly exist either.
|
|
|
|
*/
|
|
|
|
ASSERT3U(ddt->ddt_version, !=, DDT_VERSION_UNCONFIGURED);
|
|
|
|
return (SET_ERROR(ENOENT));
|
|
|
|
}
|
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
ddt_object_name(ddt, type, class, name);
|
|
|
|
|
ddt: add FDT feature and support for legacy and new on-disk formats
This is the supporting infrastructure for the upcoming dedup features.
Traditionally, dedup objects live directly in the MOS root. While their
details vary (checksum, type and class), they are all the same "kind" of
thing - a store of dedup entries.
The new features are more varied than that, and are better thought of as
a set of related stores for the overall state of a dedup table.
This adds a new feature flag, SPA_FEATURE_FAST_DEDUP. Enabling this will
cause new DDTs to be created as a ZAP in the MOS root, named
DDT-<checksum>. The is used as the root object for the normal type/class
store objects, but will also be a place for any storage required by new
features.
This commit adds two new fields to ddt_t, for version and flags. These
are intended to describe the structure and features of the overall dedup
table, and are stored as-is in the DDT root. In this commit, flags are
always zero, but the intent is that they can be used to hang optional
logic or state onto for new dedup features. Version is always 1.
For a "legacy" dedup table, where no DDT root directory exists, the
version will be 0.
ddt_configure() is expected to determine the version and flags features
currently in operation based on whether or not the fast_dedup feature is
enabled, and from what's available on disk. In this way, its possible to
support both old and new tables.
This also provides a migration path. A legacy setup can be upgraded to
FDT by creating the DDT root ZAP, moving the existing objects into it,
and setting version and flags appropriately. There's no support for that
here, but it would be straightforward to add later and allows the
possibility that newer features could be applied to existing dedup
tables.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2023-06-20 05:06:13 +03:00
|
|
|
error = zap_lookup(ddt->ddt_os, ddt->ddt_dir_object, name,
|
2010-05-29 00:45:14 +04:00
|
|
|
sizeof (uint64_t), 1, &ddt->ddt_object[type][class]);
|
2013-12-09 22:37:51 +04:00
|
|
|
if (error != 0)
|
2010-05-29 00:45:14 +04:00
|
|
|
return (error);
|
|
|
|
|
2015-08-18 21:20:22 +03:00
|
|
|
error = zap_lookup(ddt->ddt_os, ddt->ddt_spa->spa_ddt_stat_object, name,
|
2010-05-29 00:45:14 +04:00
|
|
|
sizeof (uint64_t), sizeof (ddt_histogram_t) / sizeof (uint64_t),
|
2015-08-18 21:20:22 +03:00
|
|
|
&ddt->ddt_histogram[type][class]);
|
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Seed the cached statistics.
|
|
|
|
*/
|
2012-07-20 01:50:25 +04:00
|
|
|
error = ddt_object_info(ddt, type, class, &doi);
|
|
|
|
if (error)
|
|
|
|
return (error);
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2012-10-26 21:01:49 +04:00
|
|
|
error = ddt_object_count(ddt, type, class, &count);
|
|
|
|
if (error)
|
|
|
|
return (error);
|
|
|
|
|
|
|
|
ddo->ddo_count = count;
|
2010-05-29 00:45:14 +04:00
|
|
|
ddo->ddo_dspace = doi.doi_physical_blocks_512 << 9;
|
|
|
|
ddo->ddo_mspace = doi.doi_fill_count * doi.doi_data_block_size;
|
|
|
|
|
2013-12-09 22:37:51 +04:00
|
|
|
return (0);
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2023-07-03 05:32:53 +03:00
|
|
|
ddt_object_sync(ddt_t *ddt, ddt_type_t type, ddt_class_t class,
|
2010-05-29 00:45:14 +04:00
|
|
|
dmu_tx_t *tx)
|
|
|
|
{
|
|
|
|
ddt_object_t *ddo = &ddt->ddt_object_stats[type][class];
|
|
|
|
dmu_object_info_t doi;
|
2012-10-26 21:01:49 +04:00
|
|
|
uint64_t count;
|
2010-05-29 00:45:14 +04:00
|
|
|
char name[DDT_NAMELEN];
|
|
|
|
|
|
|
|
ddt_object_name(ddt, type, class, name);
|
|
|
|
|
2024-02-15 11:37:38 +03:00
|
|
|
VERIFY0(zap_update(ddt->ddt_os, ddt->ddt_spa->spa_ddt_stat_object, name,
|
2010-05-29 00:45:14 +04:00
|
|
|
sizeof (uint64_t), sizeof (ddt_histogram_t) / sizeof (uint64_t),
|
2024-02-15 11:37:38 +03:00
|
|
|
&ddt->ddt_histogram[type][class], tx));
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Cache DDT statistics; this is the only time they'll change.
|
|
|
|
*/
|
2024-02-15 11:37:38 +03:00
|
|
|
VERIFY0(ddt_object_info(ddt, type, class, &doi));
|
|
|
|
VERIFY0(ddt_object_count(ddt, type, class, &count));
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2012-10-26 21:01:49 +04:00
|
|
|
ddo->ddo_count = count;
|
2010-05-29 00:45:14 +04:00
|
|
|
ddo->ddo_dspace = doi.doi_physical_blocks_512 << 9;
|
|
|
|
ddo->ddo_mspace = doi.doi_fill_count * doi.doi_data_block_size;
|
|
|
|
}
|
|
|
|
|
2023-06-30 06:35:18 +03:00
|
|
|
static boolean_t
|
2023-07-03 05:32:53 +03:00
|
|
|
ddt_object_exists(ddt_t *ddt, ddt_type_t type, ddt_class_t class)
|
2023-06-30 06:35:18 +03:00
|
|
|
{
|
|
|
|
return (!!ddt->ddt_object[type][class]);
|
|
|
|
}
|
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
static int
|
2023-07-03 05:32:53 +03:00
|
|
|
ddt_object_lookup(ddt_t *ddt, ddt_type_t type, ddt_class_t class,
|
2010-05-29 00:45:14 +04:00
|
|
|
ddt_entry_t *dde)
|
|
|
|
{
|
|
|
|
if (!ddt_object_exists(ddt, type, class))
|
2013-03-08 22:41:28 +04:00
|
|
|
return (SET_ERROR(ENOENT));
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
return (ddt_ops[type]->ddt_op_lookup(ddt->ddt_os,
|
2023-07-03 16:28:46 +03:00
|
|
|
ddt->ddt_object[type][class], &dde->dde_key,
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
dde->dde_phys, DDT_PHYS_SIZE(ddt)));
|
2023-07-03 16:28:46 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
ddt_object_contains(ddt_t *ddt, ddt_type_t type, ddt_class_t class,
|
|
|
|
const ddt_key_t *ddk)
|
|
|
|
{
|
|
|
|
if (!ddt_object_exists(ddt, type, class))
|
|
|
|
return (SET_ERROR(ENOENT));
|
|
|
|
|
|
|
|
return (ddt_ops[type]->ddt_op_contains(ddt->ddt_os,
|
|
|
|
ddt->ddt_object[type][class], ddk));
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2023-07-03 05:32:53 +03:00
|
|
|
ddt_object_prefetch(ddt_t *ddt, ddt_type_t type, ddt_class_t class,
|
2023-07-03 16:28:46 +03:00
|
|
|
const ddt_key_t *ddk)
|
2010-05-29 00:45:14 +04:00
|
|
|
{
|
|
|
|
if (!ddt_object_exists(ddt, type, class))
|
|
|
|
return;
|
|
|
|
|
|
|
|
ddt_ops[type]->ddt_op_prefetch(ddt->ddt_os,
|
2023-07-03 16:28:46 +03:00
|
|
|
ddt->ddt_object[type][class], ddk);
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
2024-07-26 19:16:18 +03:00
|
|
|
static void
|
|
|
|
ddt_object_prefetch_all(ddt_t *ddt, ddt_type_t type, ddt_class_t class)
|
|
|
|
{
|
|
|
|
if (!ddt_object_exists(ddt, type, class))
|
|
|
|
return;
|
|
|
|
|
|
|
|
ddt_ops[type]->ddt_op_prefetch_all(ddt->ddt_os,
|
|
|
|
ddt->ddt_object[type][class]);
|
|
|
|
}
|
|
|
|
|
2023-06-30 06:35:18 +03:00
|
|
|
static int
|
2023-07-03 05:32:53 +03:00
|
|
|
ddt_object_update(ddt_t *ddt, ddt_type_t type, ddt_class_t class,
|
2010-05-29 00:45:14 +04:00
|
|
|
ddt_entry_t *dde, dmu_tx_t *tx)
|
|
|
|
{
|
|
|
|
ASSERT(ddt_object_exists(ddt, type, class));
|
|
|
|
|
|
|
|
return (ddt_ops[type]->ddt_op_update(ddt->ddt_os,
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ddt->ddt_object[type][class], &dde->dde_key,
|
|
|
|
dde->dde_phys, DDT_PHYS_SIZE(ddt), tx));
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2023-07-03 05:32:53 +03:00
|
|
|
ddt_object_remove(ddt_t *ddt, ddt_type_t type, ddt_class_t class,
|
2023-07-03 16:28:46 +03:00
|
|
|
const ddt_key_t *ddk, dmu_tx_t *tx)
|
2010-05-29 00:45:14 +04:00
|
|
|
{
|
|
|
|
ASSERT(ddt_object_exists(ddt, type, class));
|
|
|
|
|
|
|
|
return (ddt_ops[type]->ddt_op_remove(ddt->ddt_os,
|
2023-07-03 16:28:46 +03:00
|
|
|
ddt->ddt_object[type][class], ddk, tx));
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
int
|
2023-07-03 05:32:53 +03:00
|
|
|
ddt_object_walk(ddt_t *ddt, ddt_type_t type, ddt_class_t class,
|
2023-07-03 15:16:04 +03:00
|
|
|
uint64_t *walk, ddt_lightweight_entry_t *ddlwe)
|
2010-05-29 00:45:14 +04:00
|
|
|
{
|
|
|
|
ASSERT(ddt_object_exists(ddt, type, class));
|
|
|
|
|
2023-07-03 15:16:04 +03:00
|
|
|
int error = ddt_ops[type]->ddt_op_walk(ddt->ddt_os,
|
|
|
|
ddt->ddt_object[type][class], walk, &ddlwe->ddlwe_key,
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
&ddlwe->ddlwe_phys, DDT_PHYS_SIZE(ddt));
|
2023-07-03 15:16:04 +03:00
|
|
|
if (error == 0) {
|
|
|
|
ddlwe->ddlwe_type = type;
|
|
|
|
ddlwe->ddlwe_class = class;
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
return (error);
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
2012-10-26 21:01:49 +04:00
|
|
|
int
|
2023-07-03 05:32:53 +03:00
|
|
|
ddt_object_count(ddt_t *ddt, ddt_type_t type, ddt_class_t class,
|
2012-10-26 21:01:49 +04:00
|
|
|
uint64_t *count)
|
2010-05-29 00:45:14 +04:00
|
|
|
{
|
|
|
|
ASSERT(ddt_object_exists(ddt, type, class));
|
|
|
|
|
|
|
|
return (ddt_ops[type]->ddt_op_count(ddt->ddt_os,
|
2012-10-26 21:01:49 +04:00
|
|
|
ddt->ddt_object[type][class], count));
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
int
|
2023-07-03 05:32:53 +03:00
|
|
|
ddt_object_info(ddt_t *ddt, ddt_type_t type, ddt_class_t class,
|
2010-05-29 00:45:14 +04:00
|
|
|
dmu_object_info_t *doi)
|
|
|
|
{
|
|
|
|
if (!ddt_object_exists(ddt, type, class))
|
2013-03-08 22:41:28 +04:00
|
|
|
return (SET_ERROR(ENOENT));
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
return (dmu_object_info(ddt->ddt_os, ddt->ddt_object[type][class],
|
|
|
|
doi));
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2023-07-03 05:32:53 +03:00
|
|
|
ddt_object_name(ddt_t *ddt, ddt_type_t type, ddt_class_t class,
|
2010-05-29 00:45:14 +04:00
|
|
|
char *name)
|
|
|
|
{
|
2020-06-07 21:42:12 +03:00
|
|
|
(void) snprintf(name, DDT_NAMELEN, DMU_POOL_DDT,
|
2010-05-29 00:45:14 +04:00
|
|
|
zio_checksum_table[ddt->ddt_checksum].ci_name,
|
|
|
|
ddt_ops[type]->ddt_op_name, ddt_class_name[class]);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ddt_bp_fill(const ddt_univ_phys_t *ddp, ddt_phys_variant_t v,
|
|
|
|
blkptr_t *bp, uint64_t txg)
|
2010-05-29 00:45:14 +04:00
|
|
|
{
|
2024-02-15 11:37:38 +03:00
|
|
|
ASSERT3U(txg, !=, 0);
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ASSERT3U(v, <, DDT_PHYS_NONE);
|
|
|
|
uint64_t phys_birth;
|
|
|
|
const dva_t *dvap;
|
|
|
|
|
|
|
|
if (v == DDT_PHYS_FLAT) {
|
|
|
|
phys_birth = ddp->ddp_flat.ddp_phys_birth;
|
|
|
|
dvap = ddp->ddp_flat.ddp_dva;
|
|
|
|
} else {
|
|
|
|
phys_birth = ddp->ddp_trad[v].ddp_phys_birth;
|
|
|
|
dvap = ddp->ddp_trad[v].ddp_dva;
|
|
|
|
}
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2017-11-04 23:25:13 +03:00
|
|
|
for (int d = 0; d < SPA_DVAS_PER_BP; d++)
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
bp->blk_dva[d] = dvap[d];
|
|
|
|
BP_SET_BIRTH(bp, txg, phys_birth);
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
Native Encryption for ZFS on Linux
This change incorporates three major pieces:
The first change is a keystore that manages wrapping
and encryption keys for encrypted datasets. These
commands mostly involve manipulating the new
DSL Crypto Key ZAP Objects that live in the MOS. Each
encrypted dataset has its own DSL Crypto Key that is
protected with a user's key. This level of indirection
allows users to change their keys without re-encrypting
their entire datasets. The change implements the new
subcommands "zfs load-key", "zfs unload-key" and
"zfs change-key" which allow the user to manage their
encryption keys and settings. In addition, several new
flags and properties have been added to allow dataset
creation and to make mounting and unmounting more
convenient.
The second piece of this patch provides the ability to
encrypt, decyrpt, and authenticate protected datasets.
Each object set maintains a Merkel tree of Message
Authentication Codes that protect the lower layers,
similarly to how checksums are maintained. This part
impacts the zio layer, which handles the actual
encryption and generation of MACs, as well as the ARC
and DMU, which need to be able to handle encrypted
buffers and protected data.
The last addition is the ability to do raw, encrypted
sends and receives. The idea here is to send raw
encrypted and compressed data and receive it exactly
as is on a backup system. This means that the dataset
on the receiving system is protected using the same
user key that is in use on the sending side. By doing
so, datasets can be efficiently backed up to an
untrusted system without fear of data being
compromised.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #494
Closes #5769
2017-08-14 20:36:48 +03:00
|
|
|
/*
|
|
|
|
* The bp created via this function may be used for repairs and scrub, but it
|
|
|
|
* will be missing the salt / IV required to do a full decrypting read.
|
|
|
|
*/
|
2010-05-29 00:45:14 +04:00
|
|
|
void
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ddt_bp_create(enum zio_checksum checksum, const ddt_key_t *ddk,
|
|
|
|
const ddt_univ_phys_t *ddp, ddt_phys_variant_t v, blkptr_t *bp)
|
2010-05-29 00:45:14 +04:00
|
|
|
{
|
|
|
|
BP_ZERO(bp);
|
|
|
|
|
|
|
|
if (ddp != NULL)
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ddt_bp_fill(ddp, v, bp, ddt_phys_birth(ddp, v));
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
bp->blk_cksum = ddk->ddk_cksum;
|
|
|
|
|
|
|
|
BP_SET_LSIZE(bp, DDK_GET_LSIZE(ddk));
|
|
|
|
BP_SET_PSIZE(bp, DDK_GET_PSIZE(ddk));
|
|
|
|
BP_SET_COMPRESS(bp, DDK_GET_COMPRESS(ddk));
|
Native Encryption for ZFS on Linux
This change incorporates three major pieces:
The first change is a keystore that manages wrapping
and encryption keys for encrypted datasets. These
commands mostly involve manipulating the new
DSL Crypto Key ZAP Objects that live in the MOS. Each
encrypted dataset has its own DSL Crypto Key that is
protected with a user's key. This level of indirection
allows users to change their keys without re-encrypting
their entire datasets. The change implements the new
subcommands "zfs load-key", "zfs unload-key" and
"zfs change-key" which allow the user to manage their
encryption keys and settings. In addition, several new
flags and properties have been added to allow dataset
creation and to make mounting and unmounting more
convenient.
The second piece of this patch provides the ability to
encrypt, decyrpt, and authenticate protected datasets.
Each object set maintains a Merkel tree of Message
Authentication Codes that protect the lower layers,
similarly to how checksums are maintained. This part
impacts the zio layer, which handles the actual
encryption and generation of MACs, as well as the ARC
and DMU, which need to be able to handle encrypted
buffers and protected data.
The last addition is the ability to do raw, encrypted
sends and receives. The idea here is to send raw
encrypted and compressed data and receive it exactly
as is on a backup system. This means that the dataset
on the receiving system is protected using the same
user key that is in use on the sending side. By doing
so, datasets can be efficiently backed up to an
untrusted system without fear of data being
compromised.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #494
Closes #5769
2017-08-14 20:36:48 +03:00
|
|
|
BP_SET_CRYPT(bp, DDK_GET_CRYPT(ddk));
|
|
|
|
BP_SET_FILL(bp, 1);
|
2010-05-29 00:45:14 +04:00
|
|
|
BP_SET_CHECKSUM(bp, checksum);
|
|
|
|
BP_SET_TYPE(bp, DMU_OT_DEDUP);
|
|
|
|
BP_SET_LEVEL(bp, 0);
|
2019-01-18 02:25:00 +03:00
|
|
|
BP_SET_DEDUP(bp, 1);
|
2010-05-29 00:45:14 +04:00
|
|
|
BP_SET_BYTEORDER(bp, ZFS_HOST_BYTEORDER);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
ddt_key_fill(ddt_key_t *ddk, const blkptr_t *bp)
|
|
|
|
{
|
|
|
|
ddk->ddk_cksum = bp->blk_cksum;
|
|
|
|
ddk->ddk_prop = 0;
|
|
|
|
|
Native Encryption for ZFS on Linux
This change incorporates three major pieces:
The first change is a keystore that manages wrapping
and encryption keys for encrypted datasets. These
commands mostly involve manipulating the new
DSL Crypto Key ZAP Objects that live in the MOS. Each
encrypted dataset has its own DSL Crypto Key that is
protected with a user's key. This level of indirection
allows users to change their keys without re-encrypting
their entire datasets. The change implements the new
subcommands "zfs load-key", "zfs unload-key" and
"zfs change-key" which allow the user to manage their
encryption keys and settings. In addition, several new
flags and properties have been added to allow dataset
creation and to make mounting and unmounting more
convenient.
The second piece of this patch provides the ability to
encrypt, decyrpt, and authenticate protected datasets.
Each object set maintains a Merkel tree of Message
Authentication Codes that protect the lower layers,
similarly to how checksums are maintained. This part
impacts the zio layer, which handles the actual
encryption and generation of MACs, as well as the ARC
and DMU, which need to be able to handle encrypted
buffers and protected data.
The last addition is the ability to do raw, encrypted
sends and receives. The idea here is to send raw
encrypted and compressed data and receive it exactly
as is on a backup system. This means that the dataset
on the receiving system is protected using the same
user key that is in use on the sending side. By doing
so, datasets can be efficiently backed up to an
untrusted system without fear of data being
compromised.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #494
Closes #5769
2017-08-14 20:36:48 +03:00
|
|
|
ASSERT(BP_IS_ENCRYPTED(bp) || !BP_USES_CRYPT(bp));
|
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
DDK_SET_LSIZE(ddk, BP_GET_LSIZE(bp));
|
|
|
|
DDK_SET_PSIZE(ddk, BP_GET_PSIZE(bp));
|
|
|
|
DDK_SET_COMPRESS(ddk, BP_GET_COMPRESS(bp));
|
Native Encryption for ZFS on Linux
This change incorporates three major pieces:
The first change is a keystore that manages wrapping
and encryption keys for encrypted datasets. These
commands mostly involve manipulating the new
DSL Crypto Key ZAP Objects that live in the MOS. Each
encrypted dataset has its own DSL Crypto Key that is
protected with a user's key. This level of indirection
allows users to change their keys without re-encrypting
their entire datasets. The change implements the new
subcommands "zfs load-key", "zfs unload-key" and
"zfs change-key" which allow the user to manage their
encryption keys and settings. In addition, several new
flags and properties have been added to allow dataset
creation and to make mounting and unmounting more
convenient.
The second piece of this patch provides the ability to
encrypt, decyrpt, and authenticate protected datasets.
Each object set maintains a Merkel tree of Message
Authentication Codes that protect the lower layers,
similarly to how checksums are maintained. This part
impacts the zio layer, which handles the actual
encryption and generation of MACs, as well as the ARC
and DMU, which need to be able to handle encrypted
buffers and protected data.
The last addition is the ability to do raw, encrypted
sends and receives. The idea here is to send raw
encrypted and compressed data and receive it exactly
as is on a backup system. This means that the dataset
on the receiving system is protected using the same
user key that is in use on the sending side. By doing
so, datasets can be efficiently backed up to an
untrusted system without fear of data being
compromised.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #494
Closes #5769
2017-08-14 20:36:48 +03:00
|
|
|
DDK_SET_CRYPT(ddk, BP_USES_CRYPT(bp));
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ddt_phys_extend(ddt_univ_phys_t *ddp, ddt_phys_variant_t v, const blkptr_t *bp)
|
2010-05-29 00:45:14 +04:00
|
|
|
{
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ASSERT3U(v, <, DDT_PHYS_NONE);
|
|
|
|
int bp_ndvas = BP_GET_NDVAS(bp);
|
|
|
|
int ddp_max_dvas = BP_IS_ENCRYPTED(bp) ?
|
|
|
|
SPA_DVAS_PER_BP - 1 : SPA_DVAS_PER_BP;
|
|
|
|
dva_t *dvas = (v == DDT_PHYS_FLAT) ?
|
|
|
|
ddp->ddp_flat.ddp_dva : ddp->ddp_trad[v].ddp_dva;
|
|
|
|
|
|
|
|
int s = 0, d = 0;
|
|
|
|
while (s < bp_ndvas && d < ddp_max_dvas) {
|
|
|
|
if (DVA_IS_VALID(&dvas[d])) {
|
|
|
|
d++;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
dvas[d] = bp->blk_dva[s];
|
|
|
|
s++; d++;
|
|
|
|
}
|
2010-05-29 00:45:14 +04:00
|
|
|
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
/*
|
|
|
|
* If the caller offered us more DVAs than we can fit, something has
|
|
|
|
* gone wrong in their accounting. zio_ddt_write() should never ask for
|
|
|
|
* more than we need.
|
|
|
|
*/
|
|
|
|
ASSERT3U(s, ==, bp_ndvas);
|
|
|
|
|
|
|
|
if (BP_IS_ENCRYPTED(bp))
|
|
|
|
dvas[2] = bp->blk_dva[2];
|
|
|
|
|
|
|
|
if (ddt_phys_birth(ddp, v) == 0) {
|
|
|
|
if (v == DDT_PHYS_FLAT)
|
|
|
|
ddp->ddp_flat.ddp_phys_birth = BP_GET_BIRTH(bp);
|
|
|
|
else
|
|
|
|
ddp->ddp_trad[v].ddp_phys_birth = BP_GET_BIRTH(bp);
|
|
|
|
}
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ddt_phys_copy(ddt_univ_phys_t *dst, const ddt_univ_phys_t *src,
|
|
|
|
ddt_phys_variant_t v)
|
2010-05-29 00:45:14 +04:00
|
|
|
{
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ASSERT3U(v, <, DDT_PHYS_NONE);
|
|
|
|
|
|
|
|
if (v == DDT_PHYS_FLAT)
|
|
|
|
dst->ddp_flat = src->ddp_flat;
|
|
|
|
else
|
|
|
|
dst->ddp_trad[v] = src->ddp_trad[v];
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ddt_phys_clear(ddt_univ_phys_t *ddp, ddt_phys_variant_t v)
|
2010-05-29 00:45:14 +04:00
|
|
|
{
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ASSERT3U(v, <, DDT_PHYS_NONE);
|
|
|
|
|
|
|
|
if (v == DDT_PHYS_FLAT)
|
|
|
|
memset(&ddp->ddp_flat, 0, DDT_FLAT_PHYS_SIZE);
|
|
|
|
else
|
|
|
|
memset(&ddp->ddp_trad[v], 0, DDT_TRAD_PHYS_SIZE / DDT_PHYS_MAX);
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ddt_phys_addref(ddt_univ_phys_t *ddp, ddt_phys_variant_t v)
|
2010-05-29 00:45:14 +04:00
|
|
|
{
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ASSERT3U(v, <, DDT_PHYS_NONE);
|
|
|
|
|
|
|
|
if (v == DDT_PHYS_FLAT)
|
|
|
|
ddp->ddp_flat.ddp_refcnt++;
|
|
|
|
else
|
|
|
|
ddp->ddp_trad[v].ddp_refcnt++;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint64_t
|
|
|
|
ddt_phys_decref(ddt_univ_phys_t *ddp, ddt_phys_variant_t v)
|
|
|
|
{
|
|
|
|
ASSERT3U(v, <, DDT_PHYS_NONE);
|
|
|
|
|
|
|
|
uint64_t *refcntp;
|
|
|
|
|
|
|
|
if (v == DDT_PHYS_FLAT)
|
|
|
|
refcntp = &ddp->ddp_flat.ddp_refcnt;
|
|
|
|
else
|
|
|
|
refcntp = &ddp->ddp_trad[v].ddp_refcnt;
|
|
|
|
|
|
|
|
ASSERT3U(*refcntp, >, 0);
|
|
|
|
(*refcntp)--;
|
|
|
|
return (*refcntp);
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
2023-06-30 06:35:18 +03:00
|
|
|
static void
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ddt_phys_free(ddt_t *ddt, ddt_key_t *ddk, ddt_univ_phys_t *ddp,
|
|
|
|
ddt_phys_variant_t v, uint64_t txg)
|
2010-05-29 00:45:14 +04:00
|
|
|
{
|
|
|
|
blkptr_t blk;
|
|
|
|
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ddt_bp_create(ddt->ddt_checksum, ddk, ddp, v, &blk);
|
2019-01-18 02:25:00 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We clear the dedup bit so that zio_free() will actually free the
|
|
|
|
* space, rather than just decrementing the refcount in the DDT.
|
|
|
|
*/
|
|
|
|
BP_SET_DEDUP(&blk, 0);
|
|
|
|
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ddt_phys_clear(ddp, v);
|
2010-05-29 00:45:14 +04:00
|
|
|
zio_free(ddt->ddt_spa, txg, &blk);
|
|
|
|
}
|
|
|
|
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
uint64_t
|
|
|
|
ddt_phys_birth(const ddt_univ_phys_t *ddp, ddt_phys_variant_t v)
|
|
|
|
{
|
|
|
|
ASSERT3U(v, <, DDT_PHYS_NONE);
|
|
|
|
|
|
|
|
if (v == DDT_PHYS_FLAT)
|
|
|
|
return (ddp->ddp_flat.ddp_phys_birth);
|
|
|
|
else
|
|
|
|
return (ddp->ddp_trad[v].ddp_phys_birth);
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
ddt_phys_dva_count(const ddt_univ_phys_t *ddp, ddt_phys_variant_t v,
|
|
|
|
boolean_t encrypted)
|
|
|
|
{
|
|
|
|
ASSERT3U(v, <, DDT_PHYS_NONE);
|
|
|
|
|
|
|
|
const dva_t *dvas = (v == DDT_PHYS_FLAT) ?
|
|
|
|
ddp->ddp_flat.ddp_dva : ddp->ddp_trad[v].ddp_dva;
|
|
|
|
|
|
|
|
return (DVA_IS_VALID(&dvas[0]) +
|
|
|
|
DVA_IS_VALID(&dvas[1]) +
|
|
|
|
DVA_IS_VALID(&dvas[2]) * !encrypted);
|
|
|
|
}
|
|
|
|
|
|
|
|
ddt_phys_variant_t
|
2023-07-03 08:16:02 +03:00
|
|
|
ddt_phys_select(const ddt_t *ddt, const ddt_entry_t *dde, const blkptr_t *bp)
|
2010-05-29 00:45:14 +04:00
|
|
|
{
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
const ddt_univ_phys_t *ddp = dde->dde_phys;
|
|
|
|
|
|
|
|
if (ddt->ddt_flags & DDT_FLAG_FLAT) {
|
|
|
|
if (DVA_EQUAL(BP_IDENTITY(bp), &ddp->ddp_flat.ddp_dva[0]) &&
|
|
|
|
BP_GET_BIRTH(bp) == ddp->ddp_flat.ddp_phys_birth) {
|
|
|
|
return (DDT_PHYS_FLAT);
|
|
|
|
}
|
|
|
|
} else /* traditional phys */ {
|
|
|
|
for (int p = 0; p < DDT_PHYS_MAX; p++) {
|
|
|
|
if (DVA_EQUAL(BP_IDENTITY(bp),
|
|
|
|
&ddp->ddp_trad[p].ddp_dva[0]) &&
|
|
|
|
BP_GET_BIRTH(bp) ==
|
|
|
|
ddp->ddp_trad[p].ddp_phys_birth) {
|
|
|
|
return (p);
|
|
|
|
}
|
|
|
|
}
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
return (DDT_PHYS_NONE);
|
|
|
|
}
|
|
|
|
|
|
|
|
uint64_t
|
|
|
|
ddt_phys_refcnt(const ddt_univ_phys_t *ddp, ddt_phys_variant_t v)
|
|
|
|
{
|
|
|
|
ASSERT3U(v, <, DDT_PHYS_NONE);
|
|
|
|
|
|
|
|
if (v == DDT_PHYS_FLAT)
|
|
|
|
return (ddp->ddp_flat.ddp_refcnt);
|
|
|
|
else
|
|
|
|
return (ddp->ddp_trad[v].ddp_refcnt);
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
uint64_t
|
2023-07-03 08:16:02 +03:00
|
|
|
ddt_phys_total_refcnt(const ddt_t *ddt, const ddt_entry_t *dde)
|
2010-05-29 00:45:14 +04:00
|
|
|
{
|
|
|
|
uint64_t refcnt = 0;
|
|
|
|
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
if (ddt->ddt_flags & DDT_FLAG_FLAT) {
|
|
|
|
refcnt = dde->dde_phys->ddp_flat.ddp_refcnt;
|
|
|
|
} else {
|
|
|
|
for (int p = DDT_PHYS_SINGLE; p <= DDT_PHYS_TRIPLE; p++)
|
|
|
|
refcnt += dde->dde_phys->ddp_trad[p].ddp_refcnt;
|
2023-07-03 08:16:02 +03:00
|
|
|
}
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
return (refcnt);
|
|
|
|
}
|
|
|
|
|
|
|
|
ddt_t *
|
|
|
|
ddt_select(spa_t *spa, const blkptr_t *bp)
|
|
|
|
{
|
2024-02-01 03:05:18 +03:00
|
|
|
ASSERT(DDT_CHECKSUM_VALID(BP_GET_CHECKSUM(bp)));
|
2010-05-29 00:45:14 +04:00
|
|
|
return (spa->spa_ddt[BP_GET_CHECKSUM(bp)]);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
ddt_enter(ddt_t *ddt)
|
|
|
|
{
|
|
|
|
mutex_enter(&ddt->ddt_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
ddt_exit(ddt_t *ddt)
|
|
|
|
{
|
|
|
|
mutex_exit(&ddt->ddt_lock);
|
|
|
|
}
|
|
|
|
|
2013-11-20 01:34:46 +04:00
|
|
|
void
|
|
|
|
ddt_init(void)
|
|
|
|
{
|
|
|
|
ddt_cache = kmem_cache_create("ddt_cache",
|
|
|
|
sizeof (ddt_t), 0, NULL, NULL, NULL, NULL, NULL, 0);
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ddt_entry_flat_cache = kmem_cache_create("ddt_entry_flat_cache",
|
|
|
|
DDT_ENTRY_FLAT_SIZE, 0, NULL, NULL, NULL, NULL, NULL, 0);
|
|
|
|
ddt_entry_trad_cache = kmem_cache_create("ddt_entry_trad_cache",
|
|
|
|
DDT_ENTRY_TRAD_SIZE, 0, NULL, NULL, NULL, NULL, NULL, 0);
|
2013-11-20 01:34:46 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
ddt_fini(void)
|
|
|
|
{
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
kmem_cache_destroy(ddt_entry_trad_cache);
|
|
|
|
kmem_cache_destroy(ddt_entry_flat_cache);
|
2013-11-20 01:34:46 +04:00
|
|
|
kmem_cache_destroy(ddt_cache);
|
|
|
|
}
|
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
static ddt_entry_t *
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ddt_alloc(const ddt_t *ddt, const ddt_key_t *ddk)
|
2010-05-29 00:45:14 +04:00
|
|
|
{
|
|
|
|
ddt_entry_t *dde;
|
|
|
|
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
if (ddt->ddt_flags & DDT_FLAG_FLAT) {
|
|
|
|
dde = kmem_cache_alloc(ddt_entry_flat_cache, KM_SLEEP);
|
|
|
|
memset(dde, 0, DDT_ENTRY_FLAT_SIZE);
|
|
|
|
} else {
|
|
|
|
dde = kmem_cache_alloc(ddt_entry_trad_cache, KM_SLEEP);
|
|
|
|
memset(dde, 0, DDT_ENTRY_TRAD_SIZE);
|
|
|
|
}
|
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
cv_init(&dde->dde_cv, NULL, CV_DEFAULT, NULL);
|
|
|
|
|
|
|
|
dde->dde_key = *ddk;
|
|
|
|
|
|
|
|
return (dde);
|
|
|
|
}
|
|
|
|
|
2023-07-03 12:54:40 +03:00
|
|
|
void
|
|
|
|
ddt_alloc_entry_io(ddt_entry_t *dde)
|
|
|
|
{
|
|
|
|
if (dde->dde_io != NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
dde->dde_io = kmem_zalloc(sizeof (ddt_entry_io_t), KM_SLEEP);
|
|
|
|
}
|
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
static void
|
2023-07-03 08:16:02 +03:00
|
|
|
ddt_free(const ddt_t *ddt, ddt_entry_t *dde)
|
2010-05-29 00:45:14 +04:00
|
|
|
{
|
2023-07-03 12:54:40 +03:00
|
|
|
if (dde->dde_io != NULL) {
|
|
|
|
for (int p = 0; p < DDT_NPHYS(ddt); p++)
|
|
|
|
ASSERT3P(dde->dde_io->dde_lead_zio[p], ==, NULL);
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2023-07-03 12:54:40 +03:00
|
|
|
if (dde->dde_io->dde_repair_abd != NULL)
|
|
|
|
abd_free(dde->dde_io->dde_repair_abd);
|
|
|
|
|
|
|
|
kmem_free(dde->dde_io, sizeof (ddt_entry_io_t));
|
|
|
|
}
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
cv_destroy(&dde->dde_cv);
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
kmem_cache_free(ddt->ddt_flags & DDT_FLAG_FLAT ?
|
|
|
|
ddt_entry_flat_cache : ddt_entry_trad_cache, dde);
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
ddt_remove(ddt_t *ddt, ddt_entry_t *dde)
|
|
|
|
{
|
|
|
|
ASSERT(MUTEX_HELD(&ddt->ddt_lock));
|
|
|
|
|
|
|
|
avl_remove(&ddt->ddt_tree, dde);
|
2023-07-03 08:16:02 +03:00
|
|
|
ddt_free(ddt, dde);
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
ddt: dedup table quota enforcement
This adds two new pool properties:
- dedup_table_size, the total size of all DDTs on the pool; and
- dedup_table_quota, the maximum possible size of all DDTs in the pool
When set, quota will be enforced by checking when a new entry is about
to be created. If the pool is over its dedup quota, the entry won't be
created, and the corresponding write will be converted to a regular
non-dedup write. Note that existing entries can be updated (ie their
refcounts changed), as that reuses the space rather than requiring more.
dedup_table_quota can be set to 'auto', which will set it based on the
size of the devices backing the "dedup" allocation device. This makes it
possible to limit the DDTs to the size of a dedup vdev only, such that
when the device fills, no new blocks are deduplicated.
Sponsored-by: iXsystems, Inc.
Sponsored-By: Klara Inc.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Signed-off-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Rob Wing <rob.wing@klarasystems.com>
Co-authored-by: Sean Eric Fagan <sean.fagan@klarasystems.com>
Closes #15889
2024-07-25 19:47:36 +03:00
|
|
|
static boolean_t
|
|
|
|
ddt_special_over_quota(spa_t *spa, metaslab_class_t *mc)
|
|
|
|
{
|
|
|
|
if (mc != NULL && metaslab_class_get_space(mc) > 0) {
|
|
|
|
/* Over quota if allocating outside of this special class */
|
|
|
|
if (spa_syncing_txg(spa) <= spa->spa_dedup_class_full_txg +
|
|
|
|
dedup_class_wait_txgs) {
|
|
|
|
/* Waiting for some deferred frees to be processed */
|
|
|
|
return (B_TRUE);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We're considered over quota when we hit 85% full, or for
|
|
|
|
* larger drives, when there is less than 8GB free.
|
|
|
|
*/
|
|
|
|
uint64_t allocated = metaslab_class_get_alloc(mc);
|
|
|
|
uint64_t capacity = metaslab_class_get_space(mc);
|
|
|
|
uint64_t limit = MAX(capacity * 85 / 100,
|
|
|
|
(capacity > (1LL<<33)) ? capacity - (1LL<<33) : 0);
|
|
|
|
|
|
|
|
return (allocated >= limit);
|
|
|
|
}
|
|
|
|
return (B_FALSE);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check if the DDT is over its quota. This can be due to a few conditions:
|
|
|
|
* 1. 'dedup_table_quota' property is not 0 (none) and the dedup dsize
|
|
|
|
* exceeds this limit
|
|
|
|
*
|
|
|
|
* 2. 'dedup_table_quota' property is set to automatic and
|
|
|
|
* a. the dedup or special allocation class could not satisfy a DDT
|
|
|
|
* allocation in a recent transaction
|
|
|
|
* b. the dedup or special allocation class has exceeded its 85% limit
|
|
|
|
*/
|
|
|
|
static boolean_t
|
|
|
|
ddt_over_quota(spa_t *spa)
|
|
|
|
{
|
|
|
|
if (spa->spa_dedup_table_quota == 0)
|
|
|
|
return (B_FALSE);
|
|
|
|
|
|
|
|
if (spa->spa_dedup_table_quota != UINT64_MAX)
|
|
|
|
return (ddt_get_ddt_dsize(spa) > spa->spa_dedup_table_quota);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* For automatic quota, table size is limited by dedup or special class
|
|
|
|
*/
|
|
|
|
if (ddt_special_over_quota(spa, spa_dedup_class(spa)))
|
|
|
|
return (B_TRUE);
|
|
|
|
else if (spa_special_has_ddt(spa) &&
|
|
|
|
ddt_special_over_quota(spa, spa_special_class(spa)))
|
|
|
|
return (B_TRUE);
|
|
|
|
|
|
|
|
return (B_FALSE);
|
|
|
|
}
|
|
|
|
|
2024-07-26 19:16:18 +03:00
|
|
|
void
|
|
|
|
ddt_prefetch_all(spa_t *spa)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Load all DDT entries for each type/class combination. This is
|
|
|
|
* indended to perform a prefetch on all such blocks. For the same
|
|
|
|
* reason that ddt_prefetch isn't locked, this is also not locked.
|
|
|
|
*/
|
|
|
|
for (enum zio_checksum c = 0; c < ZIO_CHECKSUM_FUNCTIONS; c++) {
|
|
|
|
ddt_t *ddt = spa->spa_ddt[c];
|
|
|
|
if (!ddt)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
for (ddt_type_t type = 0; type < DDT_TYPES; type++) {
|
|
|
|
for (ddt_class_t class = 0; class < DDT_CLASSES;
|
|
|
|
class++) {
|
|
|
|
ddt_object_prefetch_all(ddt, type, class);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
ddt: add FDT feature and support for legacy and new on-disk formats
This is the supporting infrastructure for the upcoming dedup features.
Traditionally, dedup objects live directly in the MOS root. While their
details vary (checksum, type and class), they are all the same "kind" of
thing - a store of dedup entries.
The new features are more varied than that, and are better thought of as
a set of related stores for the overall state of a dedup table.
This adds a new feature flag, SPA_FEATURE_FAST_DEDUP. Enabling this will
cause new DDTs to be created as a ZAP in the MOS root, named
DDT-<checksum>. The is used as the root object for the normal type/class
store objects, but will also be a place for any storage required by new
features.
This commit adds two new fields to ddt_t, for version and flags. These
are intended to describe the structure and features of the overall dedup
table, and are stored as-is in the DDT root. In this commit, flags are
always zero, but the intent is that they can be used to hang optional
logic or state onto for new dedup features. Version is always 1.
For a "legacy" dedup table, where no DDT root directory exists, the
version will be 0.
ddt_configure() is expected to determine the version and flags features
currently in operation based on whether or not the fast_dedup feature is
enabled, and from what's available on disk. In this way, its possible to
support both old and new tables.
This also provides a migration path. A legacy setup can be upgraded to
FDT by creating the DDT root ZAP, moving the existing objects into it,
and setting version and flags appropriately. There's no support for that
here, but it would be straightforward to add later and allows the
possibility that newer features could be applied to existing dedup
tables.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2023-06-20 05:06:13 +03:00
|
|
|
static int ddt_configure(ddt_t *ddt, boolean_t new);
|
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
ddt_entry_t *
|
zdb: rework DDT block count and leak check to just count the blocks
The upcoming dedup features break the long held assumption that all
blocks on disk with a 'D' dedup bit will always be present in the DDT,
or will have the same set of DVA allocations on disk as in the DDT.
If the DDT is no longer a complete picture of all the dedup blocks that
will be and should be on disk, then it does us no good to walk and prime
it up front, since it won't necessarily match up with every block we'll
see anyway.
Instead, we rework things here to be more like the BRT checks. When we
see a dedup'd block, we look it up in the DDT, consume a refcount, and
for the second-or-later instances, count them as duplicates.
The DDT and BRT are moved ahead of the space accounting. This will
become important for the "flat" feature, which may need to count a
modified version of the block.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2024-06-18 07:11:11 +03:00
|
|
|
ddt_lookup(ddt_t *ddt, const blkptr_t *bp)
|
2010-05-29 00:45:14 +04:00
|
|
|
{
|
ddt: dedup table quota enforcement
This adds two new pool properties:
- dedup_table_size, the total size of all DDTs on the pool; and
- dedup_table_quota, the maximum possible size of all DDTs in the pool
When set, quota will be enforced by checking when a new entry is about
to be created. If the pool is over its dedup quota, the entry won't be
created, and the corresponding write will be converted to a regular
non-dedup write. Note that existing entries can be updated (ie their
refcounts changed), as that reuses the space rather than requiring more.
dedup_table_quota can be set to 'auto', which will set it based on the
size of the devices backing the "dedup" allocation device. This makes it
possible to limit the DDTs to the size of a dedup vdev only, such that
when the device fills, no new blocks are deduplicated.
Sponsored-by: iXsystems, Inc.
Sponsored-By: Klara Inc.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Signed-off-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Rob Wing <rob.wing@klarasystems.com>
Co-authored-by: Sean Eric Fagan <sean.fagan@klarasystems.com>
Closes #15889
2024-07-25 19:47:36 +03:00
|
|
|
spa_t *spa = ddt->ddt_spa;
|
2023-06-09 03:14:42 +03:00
|
|
|
ddt_key_t search;
|
|
|
|
ddt_entry_t *dde;
|
2023-07-03 05:32:53 +03:00
|
|
|
ddt_type_t type;
|
|
|
|
ddt_class_t class;
|
2010-05-29 00:45:14 +04:00
|
|
|
avl_index_t where;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
ASSERT(MUTEX_HELD(&ddt->ddt_lock));
|
|
|
|
|
ddt: add FDT feature and support for legacy and new on-disk formats
This is the supporting infrastructure for the upcoming dedup features.
Traditionally, dedup objects live directly in the MOS root. While their
details vary (checksum, type and class), they are all the same "kind" of
thing - a store of dedup entries.
The new features are more varied than that, and are better thought of as
a set of related stores for the overall state of a dedup table.
This adds a new feature flag, SPA_FEATURE_FAST_DEDUP. Enabling this will
cause new DDTs to be created as a ZAP in the MOS root, named
DDT-<checksum>. The is used as the root object for the normal type/class
store objects, but will also be a place for any storage required by new
features.
This commit adds two new fields to ddt_t, for version and flags. These
are intended to describe the structure and features of the overall dedup
table, and are stored as-is in the DDT root. In this commit, flags are
always zero, but the intent is that they can be used to hang optional
logic or state onto for new dedup features. Version is always 1.
For a "legacy" dedup table, where no DDT root directory exists, the
version will be 0.
ddt_configure() is expected to determine the version and flags features
currently in operation based on whether or not the fast_dedup feature is
enabled, and from what's available on disk. In this way, its possible to
support both old and new tables.
This also provides a migration path. A legacy setup can be upgraded to
FDT by creating the DDT root ZAP, moving the existing objects into it,
and setting version and flags appropriately. There's no support for that
here, but it would be straightforward to add later and allows the
possibility that newer features could be applied to existing dedup
tables.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2023-06-20 05:06:13 +03:00
|
|
|
if (ddt->ddt_version == DDT_VERSION_UNCONFIGURED) {
|
|
|
|
/*
|
|
|
|
* This is the first use of this DDT since the pool was
|
|
|
|
* created; finish getting it ready for use.
|
|
|
|
*/
|
|
|
|
VERIFY0(ddt_configure(ddt, B_TRUE));
|
|
|
|
ASSERT3U(ddt->ddt_version, !=, DDT_VERSION_UNCONFIGURED);
|
|
|
|
}
|
|
|
|
|
2023-06-09 03:14:42 +03:00
|
|
|
ddt_key_fill(&search, bp);
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2023-12-05 06:28:39 +03:00
|
|
|
/* Find an existing live entry */
|
2023-06-09 03:14:42 +03:00
|
|
|
dde = avl_find(&ddt->ddt_tree, &search, &where);
|
2023-12-05 06:28:39 +03:00
|
|
|
if (dde != NULL) {
|
ddt: dedup table quota enforcement
This adds two new pool properties:
- dedup_table_size, the total size of all DDTs on the pool; and
- dedup_table_quota, the maximum possible size of all DDTs in the pool
When set, quota will be enforced by checking when a new entry is about
to be created. If the pool is over its dedup quota, the entry won't be
created, and the corresponding write will be converted to a regular
non-dedup write. Note that existing entries can be updated (ie their
refcounts changed), as that reuses the space rather than requiring more.
dedup_table_quota can be set to 'auto', which will set it based on the
size of the devices backing the "dedup" allocation device. This makes it
possible to limit the DDTs to the size of a dedup vdev only, such that
when the device fills, no new blocks are deduplicated.
Sponsored-by: iXsystems, Inc.
Sponsored-By: Klara Inc.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Signed-off-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Rob Wing <rob.wing@klarasystems.com>
Co-authored-by: Sean Eric Fagan <sean.fagan@klarasystems.com>
Closes #15889
2024-07-25 19:47:36 +03:00
|
|
|
/* If we went over quota, act like we didn't find it */
|
|
|
|
if (dde->dde_flags & DDE_FLAG_OVERQUOTA)
|
|
|
|
return (NULL);
|
|
|
|
|
|
|
|
/* If it's already loaded, we can just return it. */
|
2023-12-05 06:28:39 +03:00
|
|
|
if (dde->dde_flags & DDE_FLAG_LOADED)
|
|
|
|
return (dde);
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2023-12-05 06:28:39 +03:00
|
|
|
/* Someone else is loading it, wait for it. */
|
ddt: dedup table quota enforcement
This adds two new pool properties:
- dedup_table_size, the total size of all DDTs on the pool; and
- dedup_table_quota, the maximum possible size of all DDTs in the pool
When set, quota will be enforced by checking when a new entry is about
to be created. If the pool is over its dedup quota, the entry won't be
created, and the corresponding write will be converted to a regular
non-dedup write. Note that existing entries can be updated (ie their
refcounts changed), as that reuses the space rather than requiring more.
dedup_table_quota can be set to 'auto', which will set it based on the
size of the devices backing the "dedup" allocation device. This makes it
possible to limit the DDTs to the size of a dedup vdev only, such that
when the device fills, no new blocks are deduplicated.
Sponsored-by: iXsystems, Inc.
Sponsored-By: Klara Inc.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Signed-off-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Rob Wing <rob.wing@klarasystems.com>
Co-authored-by: Sean Eric Fagan <sean.fagan@klarasystems.com>
Closes #15889
2024-07-25 19:47:36 +03:00
|
|
|
dde->dde_waiters++;
|
2023-12-05 06:28:39 +03:00
|
|
|
while (!(dde->dde_flags & DDE_FLAG_LOADED))
|
|
|
|
cv_wait(&dde->dde_cv, &ddt->ddt_lock);
|
ddt: dedup table quota enforcement
This adds two new pool properties:
- dedup_table_size, the total size of all DDTs on the pool; and
- dedup_table_quota, the maximum possible size of all DDTs in the pool
When set, quota will be enforced by checking when a new entry is about
to be created. If the pool is over its dedup quota, the entry won't be
created, and the corresponding write will be converted to a regular
non-dedup write. Note that existing entries can be updated (ie their
refcounts changed), as that reuses the space rather than requiring more.
dedup_table_quota can be set to 'auto', which will set it based on the
size of the devices backing the "dedup" allocation device. This makes it
possible to limit the DDTs to the size of a dedup vdev only, such that
when the device fills, no new blocks are deduplicated.
Sponsored-by: iXsystems, Inc.
Sponsored-By: Klara Inc.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Signed-off-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Rob Wing <rob.wing@klarasystems.com>
Co-authored-by: Sean Eric Fagan <sean.fagan@klarasystems.com>
Closes #15889
2024-07-25 19:47:36 +03:00
|
|
|
dde->dde_waiters--;
|
|
|
|
|
|
|
|
/* Loaded but over quota, forget we were ever here */
|
|
|
|
if (dde->dde_flags & DDE_FLAG_OVERQUOTA) {
|
|
|
|
if (dde->dde_waiters == 0) {
|
|
|
|
avl_remove(&ddt->ddt_tree, dde);
|
2023-07-03 08:16:02 +03:00
|
|
|
ddt_free(ddt, dde);
|
ddt: dedup table quota enforcement
This adds two new pool properties:
- dedup_table_size, the total size of all DDTs on the pool; and
- dedup_table_quota, the maximum possible size of all DDTs in the pool
When set, quota will be enforced by checking when a new entry is about
to be created. If the pool is over its dedup quota, the entry won't be
created, and the corresponding write will be converted to a regular
non-dedup write. Note that existing entries can be updated (ie their
refcounts changed), as that reuses the space rather than requiring more.
dedup_table_quota can be set to 'auto', which will set it based on the
size of the devices backing the "dedup" allocation device. This makes it
possible to limit the DDTs to the size of a dedup vdev only, such that
when the device fills, no new blocks are deduplicated.
Sponsored-by: iXsystems, Inc.
Sponsored-By: Klara Inc.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Signed-off-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Rob Wing <rob.wing@klarasystems.com>
Co-authored-by: Sean Eric Fagan <sean.fagan@klarasystems.com>
Closes #15889
2024-07-25 19:47:36 +03:00
|
|
|
}
|
|
|
|
return (NULL);
|
|
|
|
}
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
return (dde);
|
2023-12-05 06:28:39 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Time to make a new entry. */
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
dde = ddt_alloc(ddt, &search);
|
|
|
|
|
|
|
|
/* Record the time this class was created (used by ddt prune) */
|
|
|
|
if (ddt->ddt_flags & DDT_FLAG_FLAT)
|
|
|
|
dde->dde_phys->ddp_flat.ddp_class_start = gethrestime_sec();
|
|
|
|
|
2023-12-05 06:28:39 +03:00
|
|
|
avl_insert(&ddt->ddt_tree, dde, where);
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2023-12-05 06:28:39 +03:00
|
|
|
/*
|
|
|
|
* ddt_tree is now stable, so unlock and let everyone else keep moving.
|
|
|
|
* Anyone landing on this entry will find it without DDE_FLAG_LOADED,
|
|
|
|
* and go to sleep waiting for it above.
|
|
|
|
*/
|
2010-05-29 00:45:14 +04:00
|
|
|
ddt_exit(ddt);
|
|
|
|
|
2023-12-05 06:28:39 +03:00
|
|
|
/* Search all store objects for the entry. */
|
2010-05-29 00:45:14 +04:00
|
|
|
error = ENOENT;
|
|
|
|
for (type = 0; type < DDT_TYPES; type++) {
|
|
|
|
for (class = 0; class < DDT_CLASSES; class++) {
|
|
|
|
error = ddt_object_lookup(ddt, type, class, dde);
|
OpenZFS 7614, 9064 - zfs device evacuation/removal
OpenZFS 7614 - zfs device evacuation/removal
OpenZFS 9064 - remove_mirror should wait for device removal to complete
This project allows top-level vdevs to be removed from the storage pool
with "zpool remove", reducing the total amount of storage in the pool.
This operation copies all allocated regions of the device to be removed
onto other devices, recording the mapping from old to new location.
After the removal is complete, read and free operations to the removed
(now "indirect") vdev must be remapped and performed at the new location
on disk. The indirect mapping table is kept in memory whenever the pool
is loaded, so there is minimal performance overhead when doing operations
on the indirect vdev.
The size of the in-memory mapping table will be reduced when its entries
become "obsolete" because they are no longer used by any block pointers
in the pool. An entry becomes obsolete when all the blocks that use
it are freed. An entry can also become obsolete when all the snapshots
that reference it are deleted, and the block pointers that reference it
have been "remapped" in all filesystems/zvols (and clones). Whenever an
indirect block is written, all the block pointers in it will be "remapped"
to their new (concrete) locations if possible. This process can be
accelerated by using the "zfs remap" command to proactively rewrite all
indirect blocks that reference indirect (removed) vdevs.
Note that when a device is removed, we do not verify the checksum of
the data that is copied. This makes the process much faster, but if it
were used on redundant vdevs (i.e. mirror or raidz vdevs), it would be
possible to copy the wrong data, when we have the correct data on e.g.
the other side of the mirror.
At the moment, only mirrors and simple top-level vdevs can be removed
and no removal is allowed if any of the top-level vdevs are raidz.
Porting Notes:
* Avoid zero-sized kmem_alloc() in vdev_compact_children().
The device evacuation code adds a dependency that
vdev_compact_children() be able to properly empty the vdev_child
array by setting it to NULL and zeroing vdev_children. Under Linux,
kmem_alloc() and related functions return a sentinel pointer rather
than NULL for zero-sized allocations.
* Remove comment regarding "mpt" driver where zfs_remove_max_segment
is initialized to SPA_MAXBLOCKSIZE.
Change zfs_condense_indirect_commit_entry_delay_ticks to
zfs_condense_indirect_commit_entry_delay_ms for consistency with
most other tunables in which delays are specified in ms.
* ZTS changes:
Use set_tunable rather than mdb
Use zpool sync as appropriate
Use sync_pool instead of sync
Kill jobs during test_removal_with_operation to allow unmount/export
Don't add non-disk names such as "mirror" or "raidz" to $DISKS
Use $TEST_BASE_DIR instead of /tmp
Increase HZ from 100 to 1000 which is more common on Linux
removal_multiple_indirection.ksh
Reduce iterations in order to not time out on the code
coverage builders.
removal_resume_export:
Functionally, the test case is correct but there exists a race
where the kernel thread hasn't been fully started yet and is
not visible. Wait for up to 1 second for the removal thread
to be started before giving up on it. Also, increase the
amount of data copied in order that the removal not finish
before the export has a chance to fail.
* MMP compatibility, the concept of concrete versus non-concrete devices
has slightly changed the semantics of vdev_writeable(). Update
mmp_random_leaf_impl() accordingly.
* Updated dbuf_remap() to handle the org.zfsonlinux:large_dnode pool
feature which is not supported by OpenZFS.
* Added support for new vdev removal tracepoints.
* Test cases removal_with_zdb and removal_condense_export have been
intentionally disabled. When run manually they pass as intended,
but when running in the automated test environment they produce
unreliable results on the latest Fedora release.
They may work better once the upstream pool import refectoring is
merged into ZoL at which point they will be re-enabled.
Authored by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Alex Reece <alex@delphix.com>
Reviewed-by: George Wilson <george.wilson@delphix.com>
Reviewed-by: John Kennedy <john.kennedy@delphix.com>
Reviewed-by: Prakash Surya <prakash.surya@delphix.com>
Reviewed by: Richard Laager <rlaager@wiktel.com>
Reviewed by: Tim Chase <tim@chase2k.com>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Approved by: Garrett D'Amore <garrett@damore.org>
Ported-by: Tim Chase <tim@chase2k.com>
Signed-off-by: Tim Chase <tim@chase2k.com>
OpenZFS-issue: https://www.illumos.org/issues/7614
OpenZFS-commit: https://github.com/openzfs/openzfs/commit/f539f1eb
Closes #6900
2016-09-22 19:30:13 +03:00
|
|
|
if (error != ENOENT) {
|
|
|
|
ASSERT0(error);
|
2010-05-29 00:45:14 +04:00
|
|
|
break;
|
OpenZFS 7614, 9064 - zfs device evacuation/removal
OpenZFS 7614 - zfs device evacuation/removal
OpenZFS 9064 - remove_mirror should wait for device removal to complete
This project allows top-level vdevs to be removed from the storage pool
with "zpool remove", reducing the total amount of storage in the pool.
This operation copies all allocated regions of the device to be removed
onto other devices, recording the mapping from old to new location.
After the removal is complete, read and free operations to the removed
(now "indirect") vdev must be remapped and performed at the new location
on disk. The indirect mapping table is kept in memory whenever the pool
is loaded, so there is minimal performance overhead when doing operations
on the indirect vdev.
The size of the in-memory mapping table will be reduced when its entries
become "obsolete" because they are no longer used by any block pointers
in the pool. An entry becomes obsolete when all the blocks that use
it are freed. An entry can also become obsolete when all the snapshots
that reference it are deleted, and the block pointers that reference it
have been "remapped" in all filesystems/zvols (and clones). Whenever an
indirect block is written, all the block pointers in it will be "remapped"
to their new (concrete) locations if possible. This process can be
accelerated by using the "zfs remap" command to proactively rewrite all
indirect blocks that reference indirect (removed) vdevs.
Note that when a device is removed, we do not verify the checksum of
the data that is copied. This makes the process much faster, but if it
were used on redundant vdevs (i.e. mirror or raidz vdevs), it would be
possible to copy the wrong data, when we have the correct data on e.g.
the other side of the mirror.
At the moment, only mirrors and simple top-level vdevs can be removed
and no removal is allowed if any of the top-level vdevs are raidz.
Porting Notes:
* Avoid zero-sized kmem_alloc() in vdev_compact_children().
The device evacuation code adds a dependency that
vdev_compact_children() be able to properly empty the vdev_child
array by setting it to NULL and zeroing vdev_children. Under Linux,
kmem_alloc() and related functions return a sentinel pointer rather
than NULL for zero-sized allocations.
* Remove comment regarding "mpt" driver where zfs_remove_max_segment
is initialized to SPA_MAXBLOCKSIZE.
Change zfs_condense_indirect_commit_entry_delay_ticks to
zfs_condense_indirect_commit_entry_delay_ms for consistency with
most other tunables in which delays are specified in ms.
* ZTS changes:
Use set_tunable rather than mdb
Use zpool sync as appropriate
Use sync_pool instead of sync
Kill jobs during test_removal_with_operation to allow unmount/export
Don't add non-disk names such as "mirror" or "raidz" to $DISKS
Use $TEST_BASE_DIR instead of /tmp
Increase HZ from 100 to 1000 which is more common on Linux
removal_multiple_indirection.ksh
Reduce iterations in order to not time out on the code
coverage builders.
removal_resume_export:
Functionally, the test case is correct but there exists a race
where the kernel thread hasn't been fully started yet and is
not visible. Wait for up to 1 second for the removal thread
to be started before giving up on it. Also, increase the
amount of data copied in order that the removal not finish
before the export has a chance to fail.
* MMP compatibility, the concept of concrete versus non-concrete devices
has slightly changed the semantics of vdev_writeable(). Update
mmp_random_leaf_impl() accordingly.
* Updated dbuf_remap() to handle the org.zfsonlinux:large_dnode pool
feature which is not supported by OpenZFS.
* Added support for new vdev removal tracepoints.
* Test cases removal_with_zdb and removal_condense_export have been
intentionally disabled. When run manually they pass as intended,
but when running in the automated test environment they produce
unreliable results on the latest Fedora release.
They may work better once the upstream pool import refectoring is
merged into ZoL at which point they will be re-enabled.
Authored by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Alex Reece <alex@delphix.com>
Reviewed-by: George Wilson <george.wilson@delphix.com>
Reviewed-by: John Kennedy <john.kennedy@delphix.com>
Reviewed-by: Prakash Surya <prakash.surya@delphix.com>
Reviewed by: Richard Laager <rlaager@wiktel.com>
Reviewed by: Tim Chase <tim@chase2k.com>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Approved by: Garrett D'Amore <garrett@damore.org>
Ported-by: Tim Chase <tim@chase2k.com>
Signed-off-by: Tim Chase <tim@chase2k.com>
OpenZFS-issue: https://www.illumos.org/issues/7614
OpenZFS-commit: https://github.com/openzfs/openzfs/commit/f539f1eb
Closes #6900
2016-09-22 19:30:13 +03:00
|
|
|
}
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
if (error != ENOENT)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
ddt_enter(ddt);
|
|
|
|
|
2023-12-05 06:28:39 +03:00
|
|
|
ASSERT(!(dde->dde_flags & DDE_FLAG_LOADED));
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
dde->dde_type = type; /* will be DDT_TYPES if no entry found */
|
|
|
|
dde->dde_class = class; /* will be DDT_CLASSES if no entry found */
|
|
|
|
|
ddt: dedup table quota enforcement
This adds two new pool properties:
- dedup_table_size, the total size of all DDTs on the pool; and
- dedup_table_quota, the maximum possible size of all DDTs in the pool
When set, quota will be enforced by checking when a new entry is about
to be created. If the pool is over its dedup quota, the entry won't be
created, and the corresponding write will be converted to a regular
non-dedup write. Note that existing entries can be updated (ie their
refcounts changed), as that reuses the space rather than requiring more.
dedup_table_quota can be set to 'auto', which will set it based on the
size of the devices backing the "dedup" allocation device. This makes it
possible to limit the DDTs to the size of a dedup vdev only, such that
when the device fills, no new blocks are deduplicated.
Sponsored-by: iXsystems, Inc.
Sponsored-By: Klara Inc.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Signed-off-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Rob Wing <rob.wing@klarasystems.com>
Co-authored-by: Sean Eric Fagan <sean.fagan@klarasystems.com>
Closes #15889
2024-07-25 19:47:36 +03:00
|
|
|
if (dde->dde_type == DDT_TYPES &&
|
|
|
|
dde->dde_class == DDT_CLASSES &&
|
|
|
|
ddt_over_quota(spa)) {
|
|
|
|
/* Over quota. If no one is waiting, clean up right now. */
|
|
|
|
if (dde->dde_waiters == 0) {
|
|
|
|
avl_remove(&ddt->ddt_tree, dde);
|
2023-07-03 08:16:02 +03:00
|
|
|
ddt_free(ddt, dde);
|
ddt: dedup table quota enforcement
This adds two new pool properties:
- dedup_table_size, the total size of all DDTs on the pool; and
- dedup_table_quota, the maximum possible size of all DDTs in the pool
When set, quota will be enforced by checking when a new entry is about
to be created. If the pool is over its dedup quota, the entry won't be
created, and the corresponding write will be converted to a regular
non-dedup write. Note that existing entries can be updated (ie their
refcounts changed), as that reuses the space rather than requiring more.
dedup_table_quota can be set to 'auto', which will set it based on the
size of the devices backing the "dedup" allocation device. This makes it
possible to limit the DDTs to the size of a dedup vdev only, such that
when the device fills, no new blocks are deduplicated.
Sponsored-by: iXsystems, Inc.
Sponsored-By: Klara Inc.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Signed-off-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Rob Wing <rob.wing@klarasystems.com>
Co-authored-by: Sean Eric Fagan <sean.fagan@klarasystems.com>
Closes #15889
2024-07-25 19:47:36 +03:00
|
|
|
return (NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Flag cleanup required */
|
|
|
|
dde->dde_flags |= DDE_FLAG_OVERQUOTA;
|
|
|
|
} else if (error == 0) {
|
ddt: cleanup the stats & histogram code
Both the API and the code were kinda mangled and I was really struggling
to follow it. The worst offender was the old ddt_stat_add(); after
fixing it up the rest of the changes are mostly knock-on effects and
targets of opportunity.
Note that the old ddt_stat_add() was safe against overflows - it could
produce crazy numbers, but the compiler wouldn't do anything stupid. The
assertions in ddt_stat_sub() go a lot of the way to protecting against
this; getting in a position where overflows are a problem is definitely
a programming error.
Also expanding ddt_stat_add() and ddt_histogram_empty() produces less
efficient assembly. I'm not bothered about this right now though; these
should not be hot functions, and if they are we'll optimise them later.
If we have to go back to the old form, we'll comment it like crazy.
Finally, I've removed the assertion that the bucket will never be
negative, as it will soon be possible to have entries with zero
refcounts: an entry for a block that is no longer on the pool, but is on
the log waiting to be synced out. It might be better to have a separate
bucket for these, since they're still using real space on disk, but
ultimately these stats are driving UI, and for now I've chosen to keep
them matching how they've looked in the past, as well as match the
operators mental model - pool usage is managed elsewhere.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15895
2023-06-15 10:19:41 +03:00
|
|
|
/*
|
|
|
|
* The histograms only track inactive (stored) blocks.
|
|
|
|
* We've just put an entry onto the live list, so we need to
|
|
|
|
* remove its counts. When its synced back, it'll be re-added
|
|
|
|
* to the right one.
|
|
|
|
*/
|
|
|
|
ddt_histogram_t *ddh =
|
|
|
|
&ddt->ddt_histogram[dde->dde_type][dde->dde_class];
|
|
|
|
|
|
|
|
ddt_lightweight_entry_t ddlwe;
|
|
|
|
DDT_ENTRY_TO_LIGHTWEIGHT(ddt, dde, &ddlwe);
|
|
|
|
ddt_histogram_sub_entry(ddt, ddh, &ddlwe);
|
ddt: dedup table quota enforcement
This adds two new pool properties:
- dedup_table_size, the total size of all DDTs on the pool; and
- dedup_table_quota, the maximum possible size of all DDTs in the pool
When set, quota will be enforced by checking when a new entry is about
to be created. If the pool is over its dedup quota, the entry won't be
created, and the corresponding write will be converted to a regular
non-dedup write. Note that existing entries can be updated (ie their
refcounts changed), as that reuses the space rather than requiring more.
dedup_table_quota can be set to 'auto', which will set it based on the
size of the devices backing the "dedup" allocation device. This makes it
possible to limit the DDTs to the size of a dedup vdev only, such that
when the device fills, no new blocks are deduplicated.
Sponsored-by: iXsystems, Inc.
Sponsored-By: Klara Inc.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Signed-off-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Rob Wing <rob.wing@klarasystems.com>
Co-authored-by: Sean Eric Fagan <sean.fagan@klarasystems.com>
Closes #15889
2024-07-25 19:47:36 +03:00
|
|
|
}
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2023-12-05 06:28:39 +03:00
|
|
|
/* Entry loaded, everyone can proceed now */
|
|
|
|
dde->dde_flags |= DDE_FLAG_LOADED;
|
2010-05-29 00:45:14 +04:00
|
|
|
cv_broadcast(&dde->dde_cv);
|
|
|
|
|
ddt: dedup table quota enforcement
This adds two new pool properties:
- dedup_table_size, the total size of all DDTs on the pool; and
- dedup_table_quota, the maximum possible size of all DDTs in the pool
When set, quota will be enforced by checking when a new entry is about
to be created. If the pool is over its dedup quota, the entry won't be
created, and the corresponding write will be converted to a regular
non-dedup write. Note that existing entries can be updated (ie their
refcounts changed), as that reuses the space rather than requiring more.
dedup_table_quota can be set to 'auto', which will set it based on the
size of the devices backing the "dedup" allocation device. This makes it
possible to limit the DDTs to the size of a dedup vdev only, such that
when the device fills, no new blocks are deduplicated.
Sponsored-by: iXsystems, Inc.
Sponsored-By: Klara Inc.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Signed-off-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Rob Wing <rob.wing@klarasystems.com>
Co-authored-by: Sean Eric Fagan <sean.fagan@klarasystems.com>
Closes #15889
2024-07-25 19:47:36 +03:00
|
|
|
return (dde->dde_flags & DDE_FLAG_OVERQUOTA ? NULL : dde);
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
ddt_prefetch(spa_t *spa, const blkptr_t *bp)
|
|
|
|
{
|
|
|
|
ddt_t *ddt;
|
2023-07-03 16:28:46 +03:00
|
|
|
ddt_key_t ddk;
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2010-08-27 01:24:34 +04:00
|
|
|
if (!zfs_dedup_prefetch || bp == NULL || !BP_GET_DEDUP(bp))
|
2010-05-29 00:45:14 +04:00
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
2010-08-27 01:24:34 +04:00
|
|
|
* We only remove the DDT once all tables are empty and only
|
|
|
|
* prefetch dedup blocks when there are entries in the DDT.
|
|
|
|
* Thus no locking is required as the DDT can't disappear on us.
|
2010-05-29 00:45:14 +04:00
|
|
|
*/
|
|
|
|
ddt = ddt_select(spa, bp);
|
2023-07-03 16:28:46 +03:00
|
|
|
ddt_key_fill(&ddk, bp);
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2023-07-03 05:32:53 +03:00
|
|
|
for (ddt_type_t type = 0; type < DDT_TYPES; type++) {
|
|
|
|
for (ddt_class_t class = 0; class < DDT_CLASSES; class++) {
|
2023-07-03 16:28:46 +03:00
|
|
|
ddt_object_prefetch(ddt, type, class, &ddk);
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-08-27 21:12:53 +03:00
|
|
|
/*
|
2023-10-11 04:46:55 +03:00
|
|
|
* ddt_key_t comparison. Any struct wanting to make use of this function must
|
|
|
|
* have the key as the first element. Casts it to N uint64_ts, and checks until
|
|
|
|
* we find there's a difference. This is intended to match how ddt_zap.c drives
|
|
|
|
* the ZAPs (first uint64_t as the key prehash), which will minimise the number
|
|
|
|
* of ZAP blocks touched when flushing logged entries from an AVL walk. This is
|
|
|
|
* not an invariant for this function though, should you wish to change it.
|
2016-08-27 21:12:53 +03:00
|
|
|
*/
|
2010-05-29 00:45:14 +04:00
|
|
|
int
|
2023-06-09 03:14:42 +03:00
|
|
|
ddt_key_compare(const void *x1, const void *x2)
|
2010-05-29 00:45:14 +04:00
|
|
|
{
|
2023-10-11 04:46:55 +03:00
|
|
|
const uint64_t *k1 = (const uint64_t *)x1;
|
|
|
|
const uint64_t *k2 = (const uint64_t *)x2;
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2023-10-11 04:46:55 +03:00
|
|
|
int cmp;
|
|
|
|
for (int i = 0; i < (sizeof (ddt_key_t) / sizeof (uint64_t)); i++)
|
|
|
|
if (likely((cmp = TREE_CMP(k1[i], k2[i])) != 0))
|
|
|
|
return (cmp);
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2023-10-11 04:46:55 +03:00
|
|
|
return (0);
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
ddt: add FDT feature and support for legacy and new on-disk formats
This is the supporting infrastructure for the upcoming dedup features.
Traditionally, dedup objects live directly in the MOS root. While their
details vary (checksum, type and class), they are all the same "kind" of
thing - a store of dedup entries.
The new features are more varied than that, and are better thought of as
a set of related stores for the overall state of a dedup table.
This adds a new feature flag, SPA_FEATURE_FAST_DEDUP. Enabling this will
cause new DDTs to be created as a ZAP in the MOS root, named
DDT-<checksum>. The is used as the root object for the normal type/class
store objects, but will also be a place for any storage required by new
features.
This commit adds two new fields to ddt_t, for version and flags. These
are intended to describe the structure and features of the overall dedup
table, and are stored as-is in the DDT root. In this commit, flags are
always zero, but the intent is that they can be used to hang optional
logic or state onto for new dedup features. Version is always 1.
For a "legacy" dedup table, where no DDT root directory exists, the
version will be 0.
ddt_configure() is expected to determine the version and flags features
currently in operation based on whether or not the fast_dedup feature is
enabled, and from what's available on disk. In this way, its possible to
support both old and new tables.
This also provides a migration path. A legacy setup can be upgraded to
FDT by creating the DDT root ZAP, moving the existing objects into it,
and setting version and flags appropriately. There's no support for that
here, but it would be straightforward to add later and allows the
possibility that newer features could be applied to existing dedup
tables.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2023-06-20 05:06:13 +03:00
|
|
|
/* Create the containing dir for this DDT and bump the feature count */
|
|
|
|
static void
|
|
|
|
ddt_create_dir(ddt_t *ddt, dmu_tx_t *tx)
|
|
|
|
{
|
|
|
|
ASSERT3U(ddt->ddt_dir_object, ==, 0);
|
|
|
|
ASSERT3U(ddt->ddt_version, ==, DDT_VERSION_FDT);
|
|
|
|
|
|
|
|
char name[DDT_NAMELEN];
|
|
|
|
snprintf(name, DDT_NAMELEN, DMU_POOL_DDT_DIR,
|
|
|
|
zio_checksum_table[ddt->ddt_checksum].ci_name);
|
|
|
|
|
|
|
|
ddt->ddt_dir_object = zap_create_link(ddt->ddt_os,
|
|
|
|
DMU_OTN_ZAP_METADATA, DMU_POOL_DIRECTORY_OBJECT, name, tx);
|
|
|
|
|
|
|
|
VERIFY0(zap_add(ddt->ddt_os, ddt->ddt_dir_object, DDT_DIR_VERSION,
|
|
|
|
sizeof (uint64_t), 1, &ddt->ddt_version, tx));
|
|
|
|
VERIFY0(zap_add(ddt->ddt_os, ddt->ddt_dir_object, DDT_DIR_FLAGS,
|
|
|
|
sizeof (uint64_t), 1, &ddt->ddt_flags, tx));
|
|
|
|
|
|
|
|
spa_feature_incr(ddt->ddt_spa, SPA_FEATURE_FAST_DEDUP, tx);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Destroy the containing dir and deactivate the feature */
|
|
|
|
static void
|
|
|
|
ddt_destroy_dir(ddt_t *ddt, dmu_tx_t *tx)
|
|
|
|
{
|
|
|
|
ASSERT3U(ddt->ddt_dir_object, !=, 0);
|
|
|
|
ASSERT3U(ddt->ddt_dir_object, !=, DMU_POOL_DIRECTORY_OBJECT);
|
|
|
|
ASSERT3U(ddt->ddt_version, ==, DDT_VERSION_FDT);
|
|
|
|
|
|
|
|
char name[DDT_NAMELEN];
|
|
|
|
snprintf(name, DDT_NAMELEN, DMU_POOL_DDT_DIR,
|
|
|
|
zio_checksum_table[ddt->ddt_checksum].ci_name);
|
|
|
|
|
|
|
|
for (ddt_type_t type = 0; type < DDT_TYPES; type++) {
|
|
|
|
for (ddt_class_t class = 0; class < DDT_CLASSES; class++) {
|
|
|
|
ASSERT(!ddt_object_exists(ddt, type, class));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
uint64_t count;
|
|
|
|
ASSERT0(zap_count(ddt->ddt_os, ddt->ddt_dir_object, &count));
|
|
|
|
ASSERT0(zap_contains(ddt->ddt_os, ddt->ddt_dir_object,
|
|
|
|
DDT_DIR_VERSION));
|
|
|
|
ASSERT0(zap_contains(ddt->ddt_os, ddt->ddt_dir_object, DDT_DIR_FLAGS));
|
|
|
|
ASSERT3U(count, ==, 2);
|
|
|
|
|
|
|
|
VERIFY0(zap_remove(ddt->ddt_os, DMU_POOL_DIRECTORY_OBJECT, name, tx));
|
|
|
|
VERIFY0(zap_destroy(ddt->ddt_os, ddt->ddt_dir_object, tx));
|
|
|
|
|
|
|
|
ddt->ddt_dir_object = 0;
|
|
|
|
|
|
|
|
spa_feature_decr(ddt->ddt_spa, SPA_FEATURE_FAST_DEDUP, tx);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Determine, flags and on-disk layout from what's already stored. If there's
|
|
|
|
* nothing stored, then if new is false, returns ENOENT, and if true, selects
|
|
|
|
* based on pool config.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
ddt_configure(ddt_t *ddt, boolean_t new)
|
|
|
|
{
|
|
|
|
spa_t *spa = ddt->ddt_spa;
|
|
|
|
char name[DDT_NAMELEN];
|
|
|
|
int error;
|
|
|
|
|
|
|
|
ASSERT3U(spa_load_state(spa), !=, SPA_LOAD_CREATE);
|
|
|
|
|
|
|
|
boolean_t fdt_enabled =
|
|
|
|
spa_feature_is_enabled(spa, SPA_FEATURE_FAST_DEDUP);
|
|
|
|
boolean_t fdt_active =
|
|
|
|
spa_feature_is_active(spa, SPA_FEATURE_FAST_DEDUP);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* First, look for the global DDT stats object. If its not there, then
|
|
|
|
* there's never been a DDT written before ever, and we know we're
|
|
|
|
* starting from scratch.
|
|
|
|
*/
|
|
|
|
error = zap_lookup(spa->spa_meta_objset, DMU_POOL_DIRECTORY_OBJECT,
|
|
|
|
DMU_POOL_DDT_STATS, sizeof (uint64_t), 1,
|
|
|
|
&spa->spa_ddt_stat_object);
|
|
|
|
if (error != 0) {
|
|
|
|
if (error != ENOENT)
|
|
|
|
return (error);
|
|
|
|
goto not_found;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (fdt_active) {
|
|
|
|
/*
|
|
|
|
* Now look for a DDT directory. If it exists, then it has
|
|
|
|
* everything we need.
|
|
|
|
*/
|
|
|
|
snprintf(name, DDT_NAMELEN, DMU_POOL_DDT_DIR,
|
|
|
|
zio_checksum_table[ddt->ddt_checksum].ci_name);
|
|
|
|
|
|
|
|
error = zap_lookup(spa->spa_meta_objset,
|
|
|
|
DMU_POOL_DIRECTORY_OBJECT, name, sizeof (uint64_t), 1,
|
|
|
|
&ddt->ddt_dir_object);
|
|
|
|
if (error == 0) {
|
|
|
|
ASSERT3U(spa->spa_meta_objset, ==, ddt->ddt_os);
|
|
|
|
|
|
|
|
error = zap_lookup(ddt->ddt_os, ddt->ddt_dir_object,
|
|
|
|
DDT_DIR_VERSION, sizeof (uint64_t), 1,
|
|
|
|
&ddt->ddt_version);
|
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
|
|
|
|
|
|
|
error = zap_lookup(ddt->ddt_os, ddt->ddt_dir_object,
|
|
|
|
DDT_DIR_FLAGS, sizeof (uint64_t), 1,
|
|
|
|
&ddt->ddt_flags);
|
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
|
|
|
|
|
|
|
if (ddt->ddt_version != DDT_VERSION_FDT) {
|
|
|
|
zfs_dbgmsg("ddt_configure: spa=%s ddt_dir=%s "
|
|
|
|
"unknown version %llu", spa_name(spa),
|
|
|
|
name, (u_longlong_t)ddt->ddt_version);
|
|
|
|
return (SET_ERROR(EINVAL));
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((ddt->ddt_flags & ~DDT_FLAG_MASK) != 0) {
|
|
|
|
zfs_dbgmsg("ddt_configure: spa=%s ddt_dir=%s "
|
|
|
|
"version=%llu unknown flags %llx",
|
|
|
|
spa_name(spa), name,
|
|
|
|
(u_longlong_t)ddt->ddt_flags,
|
|
|
|
(u_longlong_t)ddt->ddt_version);
|
|
|
|
return (SET_ERROR(EINVAL));
|
|
|
|
}
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
if (error != ENOENT)
|
|
|
|
return (error);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Any object in the root indicates a traditional setup. */
|
|
|
|
for (ddt_type_t type = 0; type < DDT_TYPES; type++) {
|
|
|
|
for (ddt_class_t class = 0; class < DDT_CLASSES; class++) {
|
|
|
|
ddt_object_name(ddt, type, class, name);
|
|
|
|
uint64_t obj;
|
|
|
|
error = zap_lookup(spa->spa_meta_objset,
|
|
|
|
DMU_POOL_DIRECTORY_OBJECT, name, sizeof (uint64_t),
|
|
|
|
1, &obj);
|
|
|
|
if (error == ENOENT)
|
|
|
|
continue;
|
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
|
|
|
|
|
|
|
ddt->ddt_version = DDT_VERSION_LEGACY;
|
|
|
|
ddt->ddt_flags = ddt_version_flags[ddt->ddt_version];
|
|
|
|
ddt->ddt_dir_object = DMU_POOL_DIRECTORY_OBJECT;
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
not_found:
|
|
|
|
if (!new)
|
|
|
|
return (SET_ERROR(ENOENT));
|
|
|
|
|
|
|
|
/* Nothing on disk, so set up for the best version we can */
|
|
|
|
if (fdt_enabled) {
|
|
|
|
ddt->ddt_version = DDT_VERSION_FDT;
|
|
|
|
ddt->ddt_flags = ddt_version_flags[ddt->ddt_version];
|
|
|
|
ddt->ddt_dir_object = 0; /* create on first use */
|
|
|
|
} else {
|
|
|
|
ddt->ddt_version = DDT_VERSION_LEGACY;
|
|
|
|
ddt->ddt_flags = ddt_version_flags[ddt->ddt_version];
|
|
|
|
ddt->ddt_dir_object = DMU_POOL_DIRECTORY_OBJECT;
|
|
|
|
}
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
static ddt_t *
|
|
|
|
ddt_table_alloc(spa_t *spa, enum zio_checksum c)
|
|
|
|
{
|
|
|
|
ddt_t *ddt;
|
|
|
|
|
2014-11-21 03:09:39 +03:00
|
|
|
ddt = kmem_cache_alloc(ddt_cache, KM_SLEEP);
|
2022-02-25 16:26:54 +03:00
|
|
|
memset(ddt, 0, sizeof (ddt_t));
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
mutex_init(&ddt->ddt_lock, NULL, MUTEX_DEFAULT, NULL);
|
2023-06-09 03:14:42 +03:00
|
|
|
avl_create(&ddt->ddt_tree, ddt_key_compare,
|
2010-05-29 00:45:14 +04:00
|
|
|
sizeof (ddt_entry_t), offsetof(ddt_entry_t, dde_node));
|
2023-06-09 03:14:42 +03:00
|
|
|
avl_create(&ddt->ddt_repair_tree, ddt_key_compare,
|
2010-05-29 00:45:14 +04:00
|
|
|
sizeof (ddt_entry_t), offsetof(ddt_entry_t, dde_node));
|
|
|
|
ddt->ddt_checksum = c;
|
|
|
|
ddt->ddt_spa = spa;
|
|
|
|
ddt->ddt_os = spa->spa_meta_objset;
|
ddt: add FDT feature and support for legacy and new on-disk formats
This is the supporting infrastructure for the upcoming dedup features.
Traditionally, dedup objects live directly in the MOS root. While their
details vary (checksum, type and class), they are all the same "kind" of
thing - a store of dedup entries.
The new features are more varied than that, and are better thought of as
a set of related stores for the overall state of a dedup table.
This adds a new feature flag, SPA_FEATURE_FAST_DEDUP. Enabling this will
cause new DDTs to be created as a ZAP in the MOS root, named
DDT-<checksum>. The is used as the root object for the normal type/class
store objects, but will also be a place for any storage required by new
features.
This commit adds two new fields to ddt_t, for version and flags. These
are intended to describe the structure and features of the overall dedup
table, and are stored as-is in the DDT root. In this commit, flags are
always zero, but the intent is that they can be used to hang optional
logic or state onto for new dedup features. Version is always 1.
For a "legacy" dedup table, where no DDT root directory exists, the
version will be 0.
ddt_configure() is expected to determine the version and flags features
currently in operation based on whether or not the fast_dedup feature is
enabled, and from what's available on disk. In this way, its possible to
support both old and new tables.
This also provides a migration path. A legacy setup can be upgraded to
FDT by creating the DDT root ZAP, moving the existing objects into it,
and setting version and flags appropriately. There's no support for that
here, but it would be straightforward to add later and allows the
possibility that newer features could be applied to existing dedup
tables.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2023-06-20 05:06:13 +03:00
|
|
|
ddt->ddt_version = DDT_VERSION_UNCONFIGURED;
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
return (ddt);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
ddt_table_free(ddt_t *ddt)
|
|
|
|
{
|
2024-02-15 11:37:38 +03:00
|
|
|
ASSERT0(avl_numnodes(&ddt->ddt_tree));
|
|
|
|
ASSERT0(avl_numnodes(&ddt->ddt_repair_tree));
|
2010-05-29 00:45:14 +04:00
|
|
|
avl_destroy(&ddt->ddt_tree);
|
|
|
|
avl_destroy(&ddt->ddt_repair_tree);
|
|
|
|
mutex_destroy(&ddt->ddt_lock);
|
2013-11-20 01:34:46 +04:00
|
|
|
kmem_cache_free(ddt_cache, ddt);
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
ddt_create(spa_t *spa)
|
|
|
|
{
|
|
|
|
spa->spa_dedup_checksum = ZIO_DEDUPCHECKSUM;
|
|
|
|
|
2024-02-01 03:05:18 +03:00
|
|
|
for (enum zio_checksum c = 0; c < ZIO_CHECKSUM_FUNCTIONS; c++) {
|
|
|
|
if (DDT_CHECKSUM_VALID(c))
|
|
|
|
spa->spa_ddt[c] = ddt_table_alloc(spa, c);
|
|
|
|
}
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
ddt_load(spa_t *spa)
|
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
|
|
|
ddt_create(spa);
|
|
|
|
|
|
|
|
error = zap_lookup(spa->spa_meta_objset, DMU_POOL_DIRECTORY_OBJECT,
|
|
|
|
DMU_POOL_DDT_STATS, sizeof (uint64_t), 1,
|
|
|
|
&spa->spa_ddt_stat_object);
|
|
|
|
if (error)
|
|
|
|
return (error == ENOENT ? 0 : error);
|
|
|
|
|
2017-11-04 23:25:13 +03:00
|
|
|
for (enum zio_checksum c = 0; c < ZIO_CHECKSUM_FUNCTIONS; c++) {
|
2024-02-01 03:05:18 +03:00
|
|
|
if (!DDT_CHECKSUM_VALID(c))
|
|
|
|
continue;
|
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
ddt_t *ddt = spa->spa_ddt[c];
|
ddt: add FDT feature and support for legacy and new on-disk formats
This is the supporting infrastructure for the upcoming dedup features.
Traditionally, dedup objects live directly in the MOS root. While their
details vary (checksum, type and class), they are all the same "kind" of
thing - a store of dedup entries.
The new features are more varied than that, and are better thought of as
a set of related stores for the overall state of a dedup table.
This adds a new feature flag, SPA_FEATURE_FAST_DEDUP. Enabling this will
cause new DDTs to be created as a ZAP in the MOS root, named
DDT-<checksum>. The is used as the root object for the normal type/class
store objects, but will also be a place for any storage required by new
features.
This commit adds two new fields to ddt_t, for version and flags. These
are intended to describe the structure and features of the overall dedup
table, and are stored as-is in the DDT root. In this commit, flags are
always zero, but the intent is that they can be used to hang optional
logic or state onto for new dedup features. Version is always 1.
For a "legacy" dedup table, where no DDT root directory exists, the
version will be 0.
ddt_configure() is expected to determine the version and flags features
currently in operation based on whether or not the fast_dedup feature is
enabled, and from what's available on disk. In this way, its possible to
support both old and new tables.
This also provides a migration path. A legacy setup can be upgraded to
FDT by creating the DDT root ZAP, moving the existing objects into it,
and setting version and flags appropriately. There's no support for that
here, but it would be straightforward to add later and allows the
possibility that newer features could be applied to existing dedup
tables.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2023-06-20 05:06:13 +03:00
|
|
|
error = ddt_configure(ddt, B_FALSE);
|
|
|
|
if (error == ENOENT)
|
|
|
|
continue;
|
|
|
|
if (error != 0)
|
|
|
|
return (error);
|
|
|
|
|
2023-07-03 05:32:53 +03:00
|
|
|
for (ddt_type_t type = 0; type < DDT_TYPES; type++) {
|
|
|
|
for (ddt_class_t class = 0; class < DDT_CLASSES;
|
2010-05-29 00:45:14 +04:00
|
|
|
class++) {
|
|
|
|
error = ddt_object_load(ddt, type, class);
|
|
|
|
if (error != 0 && error != ENOENT)
|
|
|
|
return (error);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Seed the cached histograms.
|
|
|
|
*/
|
2022-02-25 16:26:54 +03:00
|
|
|
memcpy(&ddt->ddt_histogram_cache, ddt->ddt_histogram,
|
2010-05-29 00:45:14 +04:00
|
|
|
sizeof (ddt->ddt_histogram));
|
|
|
|
}
|
|
|
|
|
ddt: add FDT feature and support for legacy and new on-disk formats
This is the supporting infrastructure for the upcoming dedup features.
Traditionally, dedup objects live directly in the MOS root. While their
details vary (checksum, type and class), they are all the same "kind" of
thing - a store of dedup entries.
The new features are more varied than that, and are better thought of as
a set of related stores for the overall state of a dedup table.
This adds a new feature flag, SPA_FEATURE_FAST_DEDUP. Enabling this will
cause new DDTs to be created as a ZAP in the MOS root, named
DDT-<checksum>. The is used as the root object for the normal type/class
store objects, but will also be a place for any storage required by new
features.
This commit adds two new fields to ddt_t, for version and flags. These
are intended to describe the structure and features of the overall dedup
table, and are stored as-is in the DDT root. In this commit, flags are
always zero, but the intent is that they can be used to hang optional
logic or state onto for new dedup features. Version is always 1.
For a "legacy" dedup table, where no DDT root directory exists, the
version will be 0.
ddt_configure() is expected to determine the version and flags features
currently in operation based on whether or not the fast_dedup feature is
enabled, and from what's available on disk. In this way, its possible to
support both old and new tables.
This also provides a migration path. A legacy setup can be upgraded to
FDT by creating the DDT root ZAP, moving the existing objects into it,
and setting version and flags appropriately. There's no support for that
here, but it would be straightforward to add later and allows the
possibility that newer features could be applied to existing dedup
tables.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2023-06-20 05:06:13 +03:00
|
|
|
spa->spa_dedup_dspace = ~0ULL;
|
|
|
|
spa->spa_dedup_dsize = ~0ULL;
|
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
ddt_unload(spa_t *spa)
|
|
|
|
{
|
2017-11-04 23:25:13 +03:00
|
|
|
for (enum zio_checksum c = 0; c < ZIO_CHECKSUM_FUNCTIONS; c++) {
|
2010-05-29 00:45:14 +04:00
|
|
|
if (spa->spa_ddt[c]) {
|
|
|
|
ddt_table_free(spa->spa_ddt[c]);
|
|
|
|
spa->spa_ddt[c] = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
boolean_t
|
2023-07-03 05:32:53 +03:00
|
|
|
ddt_class_contains(spa_t *spa, ddt_class_t max_class, const blkptr_t *bp)
|
2010-05-29 00:45:14 +04:00
|
|
|
{
|
|
|
|
ddt_t *ddt;
|
2023-07-03 16:28:46 +03:00
|
|
|
ddt_key_t ddk;
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
if (!BP_GET_DEDUP(bp))
|
|
|
|
return (B_FALSE);
|
|
|
|
|
|
|
|
if (max_class == DDT_CLASS_UNIQUE)
|
|
|
|
return (B_TRUE);
|
|
|
|
|
|
|
|
ddt = spa->spa_ddt[BP_GET_CHECKSUM(bp)];
|
|
|
|
|
2023-07-03 16:28:46 +03:00
|
|
|
ddt_key_fill(&ddk, bp);
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2023-07-03 05:32:53 +03:00
|
|
|
for (ddt_type_t type = 0; type < DDT_TYPES; type++) {
|
|
|
|
for (ddt_class_t class = 0; class <= max_class; class++) {
|
2023-07-03 16:28:46 +03:00
|
|
|
if (ddt_object_contains(ddt, type, class, &ddk) == 0)
|
2010-05-29 00:45:14 +04:00
|
|
|
return (B_TRUE);
|
2011-05-26 00:56:40 +04:00
|
|
|
}
|
|
|
|
}
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
return (B_FALSE);
|
|
|
|
}
|
|
|
|
|
|
|
|
ddt_entry_t *
|
|
|
|
ddt_repair_start(ddt_t *ddt, const blkptr_t *bp)
|
|
|
|
{
|
|
|
|
ddt_key_t ddk;
|
|
|
|
ddt_entry_t *dde;
|
|
|
|
|
|
|
|
ddt_key_fill(&ddk, bp);
|
|
|
|
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
dde = ddt_alloc(ddt, &ddk);
|
2023-07-03 12:54:40 +03:00
|
|
|
ddt_alloc_entry_io(dde);
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2023-07-03 05:32:53 +03:00
|
|
|
for (ddt_type_t type = 0; type < DDT_TYPES; type++) {
|
|
|
|
for (ddt_class_t class = 0; class < DDT_CLASSES; class++) {
|
2010-05-29 00:45:14 +04:00
|
|
|
/*
|
|
|
|
* We can only do repair if there are multiple copies
|
|
|
|
* of the block. For anything in the UNIQUE class,
|
|
|
|
* there's definitely only one copy, so don't even try.
|
|
|
|
*/
|
|
|
|
if (class != DDT_CLASS_UNIQUE &&
|
|
|
|
ddt_object_lookup(ddt, type, class, dde) == 0)
|
|
|
|
return (dde);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
memset(dde->dde_phys, 0, DDT_PHYS_SIZE(ddt));
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
return (dde);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
ddt_repair_done(ddt_t *ddt, ddt_entry_t *dde)
|
|
|
|
{
|
|
|
|
avl_index_t where;
|
|
|
|
|
|
|
|
ddt_enter(ddt);
|
|
|
|
|
2023-07-03 12:54:40 +03:00
|
|
|
if (dde->dde_io->dde_repair_abd != NULL &&
|
|
|
|
spa_writeable(ddt->ddt_spa) &&
|
2010-05-29 00:45:14 +04:00
|
|
|
avl_find(&ddt->ddt_repair_tree, dde, &where) == NULL)
|
|
|
|
avl_insert(&ddt->ddt_repair_tree, dde, where);
|
|
|
|
else
|
2023-07-03 08:16:02 +03:00
|
|
|
ddt_free(ddt, dde);
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
ddt_exit(ddt);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
ddt_repair_entry_done(zio_t *zio)
|
|
|
|
{
|
2023-07-03 08:16:02 +03:00
|
|
|
ddt_t *ddt = ddt_select(zio->io_spa, zio->io_bp);
|
2010-05-29 00:45:14 +04:00
|
|
|
ddt_entry_t *rdde = zio->io_private;
|
|
|
|
|
2023-07-03 08:16:02 +03:00
|
|
|
ddt_free(ddt, rdde);
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
ddt_repair_entry(ddt_t *ddt, ddt_entry_t *dde, ddt_entry_t *rdde, zio_t *rio)
|
|
|
|
{
|
|
|
|
ddt_key_t *ddk = &dde->dde_key;
|
|
|
|
ddt_key_t *rddk = &rdde->dde_key;
|
|
|
|
zio_t *zio;
|
|
|
|
blkptr_t blk;
|
|
|
|
|
|
|
|
zio = zio_null(rio, rio->io_spa, NULL,
|
|
|
|
ddt_repair_entry_done, rdde, rio->io_flags);
|
|
|
|
|
2023-07-03 08:16:02 +03:00
|
|
|
for (int p = 0; p < DDT_NPHYS(ddt); p++) {
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ddt_univ_phys_t *ddp = dde->dde_phys;
|
|
|
|
ddt_univ_phys_t *rddp = rdde->dde_phys;
|
|
|
|
ddt_phys_variant_t v = DDT_PHYS_VARIANT(ddt, p);
|
|
|
|
uint64_t phys_birth = ddt_phys_birth(ddp, v);
|
|
|
|
const dva_t *dvas, *rdvas;
|
|
|
|
|
|
|
|
if (ddt->ddt_flags & DDT_FLAG_FLAT) {
|
|
|
|
dvas = ddp->ddp_flat.ddp_dva;
|
|
|
|
rdvas = rddp->ddp_flat.ddp_dva;
|
|
|
|
} else {
|
|
|
|
dvas = ddp->ddp_trad[p].ddp_dva;
|
|
|
|
rdvas = rddp->ddp_trad[p].ddp_dva;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (phys_birth == 0 ||
|
|
|
|
phys_birth != ddt_phys_birth(rddp, v) ||
|
|
|
|
memcmp(dvas, rdvas, sizeof (dva_t) * SPA_DVAS_PER_BP))
|
2010-05-29 00:45:14 +04:00
|
|
|
continue;
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
|
|
|
|
ddt_bp_create(ddt->ddt_checksum, ddk, ddp, v, &blk);
|
2010-05-29 00:45:14 +04:00
|
|
|
zio_nowait(zio_rewrite(zio, zio->io_spa, 0, &blk,
|
2023-07-03 12:54:40 +03:00
|
|
|
rdde->dde_io->dde_repair_abd, DDK_GET_PSIZE(rddk),
|
|
|
|
NULL, NULL, ZIO_PRIORITY_SYNC_WRITE,
|
|
|
|
ZIO_DDT_CHILD_FLAGS(zio), NULL));
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
zio_nowait(zio);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
ddt_repair_table(ddt_t *ddt, zio_t *rio)
|
|
|
|
{
|
|
|
|
spa_t *spa = ddt->ddt_spa;
|
|
|
|
ddt_entry_t *dde, *rdde_next, *rdde;
|
|
|
|
avl_tree_t *t = &ddt->ddt_repair_tree;
|
|
|
|
blkptr_t blk;
|
|
|
|
|
|
|
|
if (spa_sync_pass(spa) > 1)
|
|
|
|
return;
|
|
|
|
|
|
|
|
ddt_enter(ddt);
|
|
|
|
for (rdde = avl_first(t); rdde != NULL; rdde = rdde_next) {
|
|
|
|
rdde_next = AVL_NEXT(t, rdde);
|
|
|
|
avl_remove(&ddt->ddt_repair_tree, rdde);
|
|
|
|
ddt_exit(ddt);
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ddt_bp_create(ddt->ddt_checksum, &rdde->dde_key, NULL,
|
|
|
|
DDT_PHYS_NONE, &blk);
|
2010-05-29 00:45:14 +04:00
|
|
|
dde = ddt_repair_start(ddt, &blk);
|
|
|
|
ddt_repair_entry(ddt, dde, rdde, rio);
|
|
|
|
ddt_repair_done(ddt, dde);
|
|
|
|
ddt_enter(ddt);
|
|
|
|
}
|
|
|
|
ddt_exit(ddt);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
ddt_sync_entry(ddt_t *ddt, ddt_entry_t *dde, dmu_tx_t *tx, uint64_t txg)
|
|
|
|
{
|
|
|
|
dsl_pool_t *dp = ddt->ddt_spa->spa_dsl_pool;
|
|
|
|
ddt_key_t *ddk = &dde->dde_key;
|
2023-07-03 05:32:53 +03:00
|
|
|
ddt_type_t otype = dde->dde_type;
|
|
|
|
ddt_type_t ntype = DDT_TYPE_DEFAULT;
|
|
|
|
ddt_class_t oclass = dde->dde_class;
|
|
|
|
ddt_class_t nclass;
|
2010-05-29 00:45:14 +04:00
|
|
|
uint64_t total_refcnt = 0;
|
|
|
|
|
2023-12-05 06:28:39 +03:00
|
|
|
ASSERT(dde->dde_flags & DDE_FLAG_LOADED);
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2023-07-03 08:16:02 +03:00
|
|
|
for (int p = 0; p < DDT_NPHYS(ddt); p++) {
|
2023-07-03 12:54:40 +03:00
|
|
|
ASSERT(dde->dde_io == NULL ||
|
|
|
|
dde->dde_io->dde_lead_zio[p] == NULL);
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ddt_univ_phys_t *ddp = dde->dde_phys;
|
|
|
|
ddt_phys_variant_t v = DDT_PHYS_VARIANT(ddt, p);
|
|
|
|
uint64_t phys_refcnt = ddt_phys_refcnt(ddp, v);
|
|
|
|
|
|
|
|
if (ddt_phys_birth(ddp, v) == 0) {
|
|
|
|
ASSERT0(phys_refcnt);
|
2010-05-29 00:45:14 +04:00
|
|
|
continue;
|
|
|
|
}
|
2023-07-03 08:16:02 +03:00
|
|
|
if (DDT_PHYS_IS_DITTO(ddt, p)) {
|
Remove dedupditto functionality
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 https://github.com/zfsonlinux/zfs/pull/8270).
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 https://github.com/zfsonlinux/zfs/pull/8270).
We should remove 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.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Reviewed-by: Alek Pinchuk <apinchuk@datto.com>
Issue #8270
Closes #8310
2019-06-20 00:54:02 +03:00
|
|
|
/*
|
|
|
|
* Note, we no longer create DDT-DITTO blocks, but we
|
|
|
|
* don't want to leak any written by older software.
|
|
|
|
*/
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ddt_phys_free(ddt, ddk, ddp, v, txg);
|
2010-05-29 00:45:14 +04:00
|
|
|
continue;
|
|
|
|
}
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
if (phys_refcnt == 0)
|
|
|
|
ddt_phys_free(ddt, ddk, ddp, v, txg);
|
|
|
|
total_refcnt += phys_refcnt;
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
Remove dedupditto functionality
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 https://github.com/zfsonlinux/zfs/pull/8270).
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 https://github.com/zfsonlinux/zfs/pull/8270).
We should remove 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.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Igor Kozhukhov <igor@dilos.org>
Reviewed-by: Alek Pinchuk <apinchuk@datto.com>
Issue #8270
Closes #8310
2019-06-20 00:54:02 +03:00
|
|
|
if (total_refcnt > 1)
|
2010-05-29 00:45:14 +04:00
|
|
|
nclass = DDT_CLASS_DUPLICATE;
|
|
|
|
else
|
|
|
|
nclass = DDT_CLASS_UNIQUE;
|
|
|
|
|
|
|
|
if (otype != DDT_TYPES &&
|
|
|
|
(otype != ntype || oclass != nclass || total_refcnt == 0)) {
|
2023-07-03 16:28:46 +03:00
|
|
|
VERIFY0(ddt_object_remove(ddt, otype, oclass, ddk, tx));
|
2024-02-15 11:37:38 +03:00
|
|
|
ASSERT3U(
|
2023-07-03 16:28:46 +03:00
|
|
|
ddt_object_contains(ddt, otype, oclass, ddk), ==, ENOENT);
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
if (total_refcnt != 0) {
|
|
|
|
dde->dde_type = ntype;
|
|
|
|
dde->dde_class = nclass;
|
ddt: cleanup the stats & histogram code
Both the API and the code were kinda mangled and I was really struggling
to follow it. The worst offender was the old ddt_stat_add(); after
fixing it up the rest of the changes are mostly knock-on effects and
targets of opportunity.
Note that the old ddt_stat_add() was safe against overflows - it could
produce crazy numbers, but the compiler wouldn't do anything stupid. The
assertions in ddt_stat_sub() go a lot of the way to protecting against
this; getting in a position where overflows are a problem is definitely
a programming error.
Also expanding ddt_stat_add() and ddt_histogram_empty() produces less
efficient assembly. I'm not bothered about this right now though; these
should not be hot functions, and if they are we'll optimise them later.
If we have to go back to the old form, we'll comment it like crazy.
Finally, I've removed the assertion that the bucket will never be
negative, as it will soon be possible to have entries with zero
refcounts: an entry for a block that is no longer on the pool, but is on
the log waiting to be synced out. It might be better to have a separate
bucket for these, since they're still using real space on disk, but
ultimately these stats are driving UI, and for now I've chosen to keep
them matching how they've looked in the past, as well as match the
operators mental model - pool usage is managed elsewhere.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15895
2023-06-15 10:19:41 +03:00
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
if (!ddt_object_exists(ddt, ntype, nclass))
|
|
|
|
ddt_object_create(ddt, ntype, nclass, tx);
|
2024-02-15 11:37:38 +03:00
|
|
|
VERIFY0(ddt_object_update(ddt, ntype, nclass, dde, tx));
|
2010-05-29 00:45:14 +04:00
|
|
|
|
ddt: cleanup the stats & histogram code
Both the API and the code were kinda mangled and I was really struggling
to follow it. The worst offender was the old ddt_stat_add(); after
fixing it up the rest of the changes are mostly knock-on effects and
targets of opportunity.
Note that the old ddt_stat_add() was safe against overflows - it could
produce crazy numbers, but the compiler wouldn't do anything stupid. The
assertions in ddt_stat_sub() go a lot of the way to protecting against
this; getting in a position where overflows are a problem is definitely
a programming error.
Also expanding ddt_stat_add() and ddt_histogram_empty() produces less
efficient assembly. I'm not bothered about this right now though; these
should not be hot functions, and if they are we'll optimise them later.
If we have to go back to the old form, we'll comment it like crazy.
Finally, I've removed the assertion that the bucket will never be
negative, as it will soon be possible to have entries with zero
refcounts: an entry for a block that is no longer on the pool, but is on
the log waiting to be synced out. It might be better to have a separate
bucket for these, since they're still using real space on disk, but
ultimately these stats are driving UI, and for now I've chosen to keep
them matching how they've looked in the past, as well as match the
operators mental model - pool usage is managed elsewhere.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15895
2023-06-15 10:19:41 +03:00
|
|
|
ddt_lightweight_entry_t ddlwe;
|
|
|
|
DDT_ENTRY_TO_LIGHTWEIGHT(ddt, dde, &ddlwe);
|
|
|
|
|
|
|
|
ddt_histogram_t *ddh =
|
|
|
|
&ddt->ddt_histogram[ntype][nclass];
|
|
|
|
ddt_histogram_add_entry(ddt, ddh, &ddlwe);
|
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
/*
|
|
|
|
* If the class changes, the order that we scan this bp
|
|
|
|
* changes. If it decreases, we could miss it, so
|
|
|
|
* scan it right now. (This covers both class changing
|
|
|
|
* while we are doing ddt_walk(), and when we are
|
|
|
|
* traversing.)
|
|
|
|
*/
|
|
|
|
if (nclass < oclass) {
|
|
|
|
dsl_scan_ddt_entry(dp->dp_scan,
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ddt->ddt_checksum, ddt, &ddlwe, tx);
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
ddt_sync_table(ddt_t *ddt, dmu_tx_t *tx, uint64_t txg)
|
|
|
|
{
|
|
|
|
spa_t *spa = ddt->ddt_spa;
|
|
|
|
ddt_entry_t *dde;
|
|
|
|
void *cookie = NULL;
|
|
|
|
|
|
|
|
if (avl_numnodes(&ddt->ddt_tree) == 0)
|
|
|
|
return;
|
|
|
|
|
2024-02-15 11:37:38 +03:00
|
|
|
ASSERT3U(spa->spa_uberblock.ub_version, >=, SPA_VERSION_DEDUP);
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
if (spa->spa_ddt_stat_object == 0) {
|
2012-12-14 03:24:15 +04:00
|
|
|
spa->spa_ddt_stat_object = zap_create_link(ddt->ddt_os,
|
|
|
|
DMU_OT_DDT_STATS, DMU_POOL_DIRECTORY_OBJECT,
|
|
|
|
DMU_POOL_DDT_STATS, tx);
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
ddt: add FDT feature and support for legacy and new on-disk formats
This is the supporting infrastructure for the upcoming dedup features.
Traditionally, dedup objects live directly in the MOS root. While their
details vary (checksum, type and class), they are all the same "kind" of
thing - a store of dedup entries.
The new features are more varied than that, and are better thought of as
a set of related stores for the overall state of a dedup table.
This adds a new feature flag, SPA_FEATURE_FAST_DEDUP. Enabling this will
cause new DDTs to be created as a ZAP in the MOS root, named
DDT-<checksum>. The is used as the root object for the normal type/class
store objects, but will also be a place for any storage required by new
features.
This commit adds two new fields to ddt_t, for version and flags. These
are intended to describe the structure and features of the overall dedup
table, and are stored as-is in the DDT root. In this commit, flags are
always zero, but the intent is that they can be used to hang optional
logic or state onto for new dedup features. Version is always 1.
For a "legacy" dedup table, where no DDT root directory exists, the
version will be 0.
ddt_configure() is expected to determine the version and flags features
currently in operation based on whether or not the fast_dedup feature is
enabled, and from what's available on disk. In this way, its possible to
support both old and new tables.
This also provides a migration path. A legacy setup can be upgraded to
FDT by creating the DDT root ZAP, moving the existing objects into it,
and setting version and flags appropriately. There's no support for that
here, but it would be straightforward to add later and allows the
possibility that newer features could be applied to existing dedup
tables.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2023-06-20 05:06:13 +03:00
|
|
|
if (ddt->ddt_version == DDT_VERSION_FDT && ddt->ddt_dir_object == 0)
|
|
|
|
ddt_create_dir(ddt, tx);
|
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
while ((dde = avl_destroy_nodes(&ddt->ddt_tree, &cookie)) != NULL) {
|
|
|
|
ddt_sync_entry(ddt, dde, tx, txg);
|
2023-07-03 08:16:02 +03:00
|
|
|
ddt_free(ddt, dde);
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
ddt: add FDT feature and support for legacy and new on-disk formats
This is the supporting infrastructure for the upcoming dedup features.
Traditionally, dedup objects live directly in the MOS root. While their
details vary (checksum, type and class), they are all the same "kind" of
thing - a store of dedup entries.
The new features are more varied than that, and are better thought of as
a set of related stores for the overall state of a dedup table.
This adds a new feature flag, SPA_FEATURE_FAST_DEDUP. Enabling this will
cause new DDTs to be created as a ZAP in the MOS root, named
DDT-<checksum>. The is used as the root object for the normal type/class
store objects, but will also be a place for any storage required by new
features.
This commit adds two new fields to ddt_t, for version and flags. These
are intended to describe the structure and features of the overall dedup
table, and are stored as-is in the DDT root. In this commit, flags are
always zero, but the intent is that they can be used to hang optional
logic or state onto for new dedup features. Version is always 1.
For a "legacy" dedup table, where no DDT root directory exists, the
version will be 0.
ddt_configure() is expected to determine the version and flags features
currently in operation based on whether or not the fast_dedup feature is
enabled, and from what's available on disk. In this way, its possible to
support both old and new tables.
This also provides a migration path. A legacy setup can be upgraded to
FDT by creating the DDT root ZAP, moving the existing objects into it,
and setting version and flags appropriately. There's no support for that
here, but it would be straightforward to add later and allows the
possibility that newer features could be applied to existing dedup
tables.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2023-06-20 05:06:13 +03:00
|
|
|
uint64_t count = 0;
|
2023-07-03 05:32:53 +03:00
|
|
|
for (ddt_type_t type = 0; type < DDT_TYPES; type++) {
|
ddt: add FDT feature and support for legacy and new on-disk formats
This is the supporting infrastructure for the upcoming dedup features.
Traditionally, dedup objects live directly in the MOS root. While their
details vary (checksum, type and class), they are all the same "kind" of
thing - a store of dedup entries.
The new features are more varied than that, and are better thought of as
a set of related stores for the overall state of a dedup table.
This adds a new feature flag, SPA_FEATURE_FAST_DEDUP. Enabling this will
cause new DDTs to be created as a ZAP in the MOS root, named
DDT-<checksum>. The is used as the root object for the normal type/class
store objects, but will also be a place for any storage required by new
features.
This commit adds two new fields to ddt_t, for version and flags. These
are intended to describe the structure and features of the overall dedup
table, and are stored as-is in the DDT root. In this commit, flags are
always zero, but the intent is that they can be used to hang optional
logic or state onto for new dedup features. Version is always 1.
For a "legacy" dedup table, where no DDT root directory exists, the
version will be 0.
ddt_configure() is expected to determine the version and flags features
currently in operation based on whether or not the fast_dedup feature is
enabled, and from what's available on disk. In this way, its possible to
support both old and new tables.
This also provides a migration path. A legacy setup can be upgraded to
FDT by creating the DDT root ZAP, moving the existing objects into it,
and setting version and flags appropriately. There's no support for that
here, but it would be straightforward to add later and allows the
possibility that newer features could be applied to existing dedup
tables.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2023-06-20 05:06:13 +03:00
|
|
|
uint64_t add, tcount = 0;
|
2023-07-03 05:32:53 +03:00
|
|
|
for (ddt_class_t class = 0; class < DDT_CLASSES; class++) {
|
2010-08-27 01:24:34 +04:00
|
|
|
if (ddt_object_exists(ddt, type, class)) {
|
|
|
|
ddt_object_sync(ddt, type, class, tx);
|
2024-02-15 11:37:38 +03:00
|
|
|
VERIFY0(ddt_object_count(ddt, type, class,
|
|
|
|
&add));
|
ddt: add FDT feature and support for legacy and new on-disk formats
This is the supporting infrastructure for the upcoming dedup features.
Traditionally, dedup objects live directly in the MOS root. While their
details vary (checksum, type and class), they are all the same "kind" of
thing - a store of dedup entries.
The new features are more varied than that, and are better thought of as
a set of related stores for the overall state of a dedup table.
This adds a new feature flag, SPA_FEATURE_FAST_DEDUP. Enabling this will
cause new DDTs to be created as a ZAP in the MOS root, named
DDT-<checksum>. The is used as the root object for the normal type/class
store objects, but will also be a place for any storage required by new
features.
This commit adds two new fields to ddt_t, for version and flags. These
are intended to describe the structure and features of the overall dedup
table, and are stored as-is in the DDT root. In this commit, flags are
always zero, but the intent is that they can be used to hang optional
logic or state onto for new dedup features. Version is always 1.
For a "legacy" dedup table, where no DDT root directory exists, the
version will be 0.
ddt_configure() is expected to determine the version and flags features
currently in operation based on whether or not the fast_dedup feature is
enabled, and from what's available on disk. In this way, its possible to
support both old and new tables.
This also provides a migration path. A legacy setup can be upgraded to
FDT by creating the DDT root ZAP, moving the existing objects into it,
and setting version and flags appropriately. There's no support for that
here, but it would be straightforward to add later and allows the
possibility that newer features could be applied to existing dedup
tables.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2023-06-20 05:06:13 +03:00
|
|
|
tcount += add;
|
2010-08-27 01:24:34 +04:00
|
|
|
}
|
|
|
|
}
|
2023-07-03 05:32:53 +03:00
|
|
|
for (ddt_class_t class = 0; class < DDT_CLASSES; class++) {
|
ddt: add FDT feature and support for legacy and new on-disk formats
This is the supporting infrastructure for the upcoming dedup features.
Traditionally, dedup objects live directly in the MOS root. While their
details vary (checksum, type and class), they are all the same "kind" of
thing - a store of dedup entries.
The new features are more varied than that, and are better thought of as
a set of related stores for the overall state of a dedup table.
This adds a new feature flag, SPA_FEATURE_FAST_DEDUP. Enabling this will
cause new DDTs to be created as a ZAP in the MOS root, named
DDT-<checksum>. The is used as the root object for the normal type/class
store objects, but will also be a place for any storage required by new
features.
This commit adds two new fields to ddt_t, for version and flags. These
are intended to describe the structure and features of the overall dedup
table, and are stored as-is in the DDT root. In this commit, flags are
always zero, but the intent is that they can be used to hang optional
logic or state onto for new dedup features. Version is always 1.
For a "legacy" dedup table, where no DDT root directory exists, the
version will be 0.
ddt_configure() is expected to determine the version and flags features
currently in operation based on whether or not the fast_dedup feature is
enabled, and from what's available on disk. In this way, its possible to
support both old and new tables.
This also provides a migration path. A legacy setup can be upgraded to
FDT by creating the DDT root ZAP, moving the existing objects into it,
and setting version and flags appropriately. There's no support for that
here, but it would be straightforward to add later and allows the
possibility that newer features could be applied to existing dedup
tables.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2023-06-20 05:06:13 +03:00
|
|
|
if (tcount == 0 && ddt_object_exists(ddt, type, class))
|
2010-05-29 00:45:14 +04:00
|
|
|
ddt_object_destroy(ddt, type, class, tx);
|
|
|
|
}
|
ddt: add FDT feature and support for legacy and new on-disk formats
This is the supporting infrastructure for the upcoming dedup features.
Traditionally, dedup objects live directly in the MOS root. While their
details vary (checksum, type and class), they are all the same "kind" of
thing - a store of dedup entries.
The new features are more varied than that, and are better thought of as
a set of related stores for the overall state of a dedup table.
This adds a new feature flag, SPA_FEATURE_FAST_DEDUP. Enabling this will
cause new DDTs to be created as a ZAP in the MOS root, named
DDT-<checksum>. The is used as the root object for the normal type/class
store objects, but will also be a place for any storage required by new
features.
This commit adds two new fields to ddt_t, for version and flags. These
are intended to describe the structure and features of the overall dedup
table, and are stored as-is in the DDT root. In this commit, flags are
always zero, but the intent is that they can be used to hang optional
logic or state onto for new dedup features. Version is always 1.
For a "legacy" dedup table, where no DDT root directory exists, the
version will be 0.
ddt_configure() is expected to determine the version and flags features
currently in operation based on whether or not the fast_dedup feature is
enabled, and from what's available on disk. In this way, its possible to
support both old and new tables.
This also provides a migration path. A legacy setup can be upgraded to
FDT by creating the DDT root ZAP, moving the existing objects into it,
and setting version and flags appropriately. There's no support for that
here, but it would be straightforward to add later and allows the
possibility that newer features could be applied to existing dedup
tables.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2023-06-20 05:06:13 +03:00
|
|
|
count += tcount;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (count == 0) {
|
|
|
|
/*
|
|
|
|
* No entries left on the DDT, so reset the version for next
|
|
|
|
* time. This allows us to handle the feature being changed
|
|
|
|
* since the DDT was originally created. New entries should get
|
|
|
|
* whatever the feature currently demands.
|
|
|
|
*/
|
|
|
|
if (ddt->ddt_version == DDT_VERSION_FDT)
|
|
|
|
ddt_destroy_dir(ddt, tx);
|
|
|
|
|
|
|
|
ddt->ddt_version = DDT_VERSION_UNCONFIGURED;
|
|
|
|
ddt->ddt_flags = 0;
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
2022-02-25 16:26:54 +03:00
|
|
|
memcpy(&ddt->ddt_histogram_cache, ddt->ddt_histogram,
|
2010-05-29 00:45:14 +04:00
|
|
|
sizeof (ddt->ddt_histogram));
|
2016-12-03 02:59:35 +03:00
|
|
|
spa->spa_dedup_dspace = ~0ULL;
|
ddt: dedup table quota enforcement
This adds two new pool properties:
- dedup_table_size, the total size of all DDTs on the pool; and
- dedup_table_quota, the maximum possible size of all DDTs in the pool
When set, quota will be enforced by checking when a new entry is about
to be created. If the pool is over its dedup quota, the entry won't be
created, and the corresponding write will be converted to a regular
non-dedup write. Note that existing entries can be updated (ie their
refcounts changed), as that reuses the space rather than requiring more.
dedup_table_quota can be set to 'auto', which will set it based on the
size of the devices backing the "dedup" allocation device. This makes it
possible to limit the DDTs to the size of a dedup vdev only, such that
when the device fills, no new blocks are deduplicated.
Sponsored-by: iXsystems, Inc.
Sponsored-By: Klara Inc.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Signed-off-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Rob Wing <rob.wing@klarasystems.com>
Co-authored-by: Sean Eric Fagan <sean.fagan@klarasystems.com>
Closes #15889
2024-07-25 19:47:36 +03:00
|
|
|
spa->spa_dedup_dsize = ~0ULL;
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
ddt_sync(spa_t *spa, uint64_t txg)
|
|
|
|
{
|
2017-11-16 04:27:01 +03:00
|
|
|
dsl_scan_t *scn = spa->spa_dsl_pool->dp_scan;
|
2010-05-29 00:45:14 +04:00
|
|
|
dmu_tx_t *tx;
|
2017-11-16 04:27:01 +03:00
|
|
|
zio_t *rio;
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2024-02-15 11:37:38 +03:00
|
|
|
ASSERT3U(spa_syncing_txg(spa), ==, txg);
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
tx = dmu_tx_create_assigned(spa->spa_dsl_pool, txg);
|
|
|
|
|
2017-11-16 04:27:01 +03:00
|
|
|
rio = zio_root(spa, NULL, NULL,
|
OpenZFS 7614, 9064 - zfs device evacuation/removal
OpenZFS 7614 - zfs device evacuation/removal
OpenZFS 9064 - remove_mirror should wait for device removal to complete
This project allows top-level vdevs to be removed from the storage pool
with "zpool remove", reducing the total amount of storage in the pool.
This operation copies all allocated regions of the device to be removed
onto other devices, recording the mapping from old to new location.
After the removal is complete, read and free operations to the removed
(now "indirect") vdev must be remapped and performed at the new location
on disk. The indirect mapping table is kept in memory whenever the pool
is loaded, so there is minimal performance overhead when doing operations
on the indirect vdev.
The size of the in-memory mapping table will be reduced when its entries
become "obsolete" because they are no longer used by any block pointers
in the pool. An entry becomes obsolete when all the blocks that use
it are freed. An entry can also become obsolete when all the snapshots
that reference it are deleted, and the block pointers that reference it
have been "remapped" in all filesystems/zvols (and clones). Whenever an
indirect block is written, all the block pointers in it will be "remapped"
to their new (concrete) locations if possible. This process can be
accelerated by using the "zfs remap" command to proactively rewrite all
indirect blocks that reference indirect (removed) vdevs.
Note that when a device is removed, we do not verify the checksum of
the data that is copied. This makes the process much faster, but if it
were used on redundant vdevs (i.e. mirror or raidz vdevs), it would be
possible to copy the wrong data, when we have the correct data on e.g.
the other side of the mirror.
At the moment, only mirrors and simple top-level vdevs can be removed
and no removal is allowed if any of the top-level vdevs are raidz.
Porting Notes:
* Avoid zero-sized kmem_alloc() in vdev_compact_children().
The device evacuation code adds a dependency that
vdev_compact_children() be able to properly empty the vdev_child
array by setting it to NULL and zeroing vdev_children. Under Linux,
kmem_alloc() and related functions return a sentinel pointer rather
than NULL for zero-sized allocations.
* Remove comment regarding "mpt" driver where zfs_remove_max_segment
is initialized to SPA_MAXBLOCKSIZE.
Change zfs_condense_indirect_commit_entry_delay_ticks to
zfs_condense_indirect_commit_entry_delay_ms for consistency with
most other tunables in which delays are specified in ms.
* ZTS changes:
Use set_tunable rather than mdb
Use zpool sync as appropriate
Use sync_pool instead of sync
Kill jobs during test_removal_with_operation to allow unmount/export
Don't add non-disk names such as "mirror" or "raidz" to $DISKS
Use $TEST_BASE_DIR instead of /tmp
Increase HZ from 100 to 1000 which is more common on Linux
removal_multiple_indirection.ksh
Reduce iterations in order to not time out on the code
coverage builders.
removal_resume_export:
Functionally, the test case is correct but there exists a race
where the kernel thread hasn't been fully started yet and is
not visible. Wait for up to 1 second for the removal thread
to be started before giving up on it. Also, increase the
amount of data copied in order that the removal not finish
before the export has a chance to fail.
* MMP compatibility, the concept of concrete versus non-concrete devices
has slightly changed the semantics of vdev_writeable(). Update
mmp_random_leaf_impl() accordingly.
* Updated dbuf_remap() to handle the org.zfsonlinux:large_dnode pool
feature which is not supported by OpenZFS.
* Added support for new vdev removal tracepoints.
* Test cases removal_with_zdb and removal_condense_export have been
intentionally disabled. When run manually they pass as intended,
but when running in the automated test environment they produce
unreliable results on the latest Fedora release.
They may work better once the upstream pool import refectoring is
merged into ZoL at which point they will be re-enabled.
Authored by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Alex Reece <alex@delphix.com>
Reviewed-by: George Wilson <george.wilson@delphix.com>
Reviewed-by: John Kennedy <john.kennedy@delphix.com>
Reviewed-by: Prakash Surya <prakash.surya@delphix.com>
Reviewed by: Richard Laager <rlaager@wiktel.com>
Reviewed by: Tim Chase <tim@chase2k.com>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Approved by: Garrett D'Amore <garrett@damore.org>
Ported-by: Tim Chase <tim@chase2k.com>
Signed-off-by: Tim Chase <tim@chase2k.com>
OpenZFS-issue: https://www.illumos.org/issues/7614
OpenZFS-commit: https://github.com/openzfs/openzfs/commit/f539f1eb
Closes #6900
2016-09-22 19:30:13 +03:00
|
|
|
ZIO_FLAG_CANFAIL | ZIO_FLAG_SPECULATIVE | ZIO_FLAG_SELF_HEAL);
|
2017-11-16 04:27:01 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This function may cause an immediate scan of ddt blocks (see
|
|
|
|
* the comment above dsl_scan_ddt() for details). We set the
|
|
|
|
* scan's root zio here so that we can wait for any scan IOs in
|
|
|
|
* addition to the regular ddt IOs.
|
|
|
|
*/
|
|
|
|
ASSERT3P(scn->scn_zio_root, ==, NULL);
|
|
|
|
scn->scn_zio_root = rio;
|
|
|
|
|
2017-11-04 23:25:13 +03:00
|
|
|
for (enum zio_checksum c = 0; c < ZIO_CHECKSUM_FUNCTIONS; c++) {
|
2010-05-29 00:45:14 +04:00
|
|
|
ddt_t *ddt = spa->spa_ddt[c];
|
|
|
|
if (ddt == NULL)
|
|
|
|
continue;
|
|
|
|
ddt_sync_table(ddt, tx, txg);
|
|
|
|
ddt_repair_table(ddt, rio);
|
|
|
|
}
|
|
|
|
|
|
|
|
(void) zio_wait(rio);
|
2017-11-16 04:27:01 +03:00
|
|
|
scn->scn_zio_root = NULL;
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
dmu_tx_commit(tx);
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
2023-07-03 15:16:04 +03:00
|
|
|
ddt_walk(spa_t *spa, ddt_bookmark_t *ddb, ddt_lightweight_entry_t *ddlwe)
|
2010-05-29 00:45:14 +04:00
|
|
|
{
|
|
|
|
do {
|
|
|
|
do {
|
|
|
|
do {
|
|
|
|
ddt_t *ddt = spa->spa_ddt[ddb->ddb_checksum];
|
2024-02-01 03:05:18 +03:00
|
|
|
if (ddt == NULL)
|
|
|
|
continue;
|
2010-05-29 00:45:14 +04:00
|
|
|
int error = ENOENT;
|
|
|
|
if (ddt_object_exists(ddt, ddb->ddb_type,
|
|
|
|
ddb->ddb_class)) {
|
|
|
|
error = ddt_object_walk(ddt,
|
|
|
|
ddb->ddb_type, ddb->ddb_class,
|
2023-07-03 15:16:04 +03:00
|
|
|
&ddb->ddb_cursor, ddlwe);
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
|
|
|
if (error == 0)
|
|
|
|
return (0);
|
|
|
|
if (error != ENOENT)
|
|
|
|
return (error);
|
|
|
|
ddb->ddb_cursor = 0;
|
|
|
|
} while (++ddb->ddb_checksum < ZIO_CHECKSUM_FUNCTIONS);
|
|
|
|
ddb->ddb_checksum = 0;
|
|
|
|
} while (++ddb->ddb_type < DDT_TYPES);
|
|
|
|
ddb->ddb_type = 0;
|
|
|
|
} while (++ddb->ddb_class < DDT_CLASSES);
|
|
|
|
|
2013-03-08 22:41:28 +04:00
|
|
|
return (SET_ERROR(ENOENT));
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
2011-05-04 02:09:28 +04:00
|
|
|
|
2023-03-10 22:59:53 +03:00
|
|
|
/*
|
|
|
|
* This function is used by Block Cloning (brt.c) to increase reference
|
|
|
|
* counter for the DDT entry if the block is already in DDT.
|
|
|
|
*
|
|
|
|
* Return false if the block, despite having the D bit set, is not present
|
|
|
|
* in the DDT. Currently this is not possible but might be in the future.
|
|
|
|
* See the comment below.
|
|
|
|
*/
|
|
|
|
boolean_t
|
|
|
|
ddt_addref(spa_t *spa, const blkptr_t *bp)
|
|
|
|
{
|
|
|
|
ddt_t *ddt;
|
|
|
|
ddt_entry_t *dde;
|
|
|
|
boolean_t result;
|
|
|
|
|
|
|
|
spa_config_enter(spa, SCL_ZIO, FTAG, RW_READER);
|
|
|
|
ddt = ddt_select(spa, bp);
|
|
|
|
ddt_enter(ddt);
|
|
|
|
|
zdb: rework DDT block count and leak check to just count the blocks
The upcoming dedup features break the long held assumption that all
blocks on disk with a 'D' dedup bit will always be present in the DDT,
or will have the same set of DVA allocations on disk as in the DDT.
If the DDT is no longer a complete picture of all the dedup blocks that
will be and should be on disk, then it does us no good to walk and prime
it up front, since it won't necessarily match up with every block we'll
see anyway.
Instead, we rework things here to be more like the BRT checks. When we
see a dedup'd block, we look it up in the DDT, consume a refcount, and
for the second-or-later instances, count them as duplicates.
The DDT and BRT are moved ahead of the space accounting. This will
become important for the "flat" feature, which may need to count a
modified version of the block.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Allan Jude <allan@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15892
2024-06-18 07:11:11 +03:00
|
|
|
dde = ddt_lookup(ddt, bp);
|
ddt: dedup table quota enforcement
This adds two new pool properties:
- dedup_table_size, the total size of all DDTs on the pool; and
- dedup_table_quota, the maximum possible size of all DDTs in the pool
When set, quota will be enforced by checking when a new entry is about
to be created. If the pool is over its dedup quota, the entry won't be
created, and the corresponding write will be converted to a regular
non-dedup write. Note that existing entries can be updated (ie their
refcounts changed), as that reuses the space rather than requiring more.
dedup_table_quota can be set to 'auto', which will set it based on the
size of the devices backing the "dedup" allocation device. This makes it
possible to limit the DDTs to the size of a dedup vdev only, such that
when the device fills, no new blocks are deduplicated.
Sponsored-by: iXsystems, Inc.
Sponsored-By: Klara Inc.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Signed-off-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Co-authored-by: Rob Wing <rob.wing@klarasystems.com>
Co-authored-by: Sean Eric Fagan <sean.fagan@klarasystems.com>
Closes #15889
2024-07-25 19:47:36 +03:00
|
|
|
|
|
|
|
/* Can be NULL if the entry for this block was pruned. */
|
|
|
|
if (dde == NULL) {
|
|
|
|
ddt_exit(ddt);
|
|
|
|
spa_config_exit(spa, SCL_ZIO, FTAG);
|
|
|
|
return (B_FALSE);
|
|
|
|
}
|
2023-03-10 22:59:53 +03:00
|
|
|
|
|
|
|
if (dde->dde_type < DDT_TYPES) {
|
|
|
|
ASSERT3S(dde->dde_class, <, DDT_CLASSES);
|
|
|
|
|
2023-07-03 08:16:02 +03:00
|
|
|
int p = DDT_PHYS_FOR_COPIES(ddt, BP_GET_NDVAS(bp));
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ddt_phys_variant_t v = DDT_PHYS_VARIANT(ddt, p);
|
ddt_addref: remove unnecessary phys fill when refcount is 0
The previous comment wondered if this case could happen; it turns out
that it really can't.
This block can only be entered if dde_type and dde_class are "real";
that only happens when a ddt entry has been previously synced to a ddt
store, that is, it was created on a previous txg. Since its gone through
that sync, its dde_refcount must be >0.
ddt_addref() is called from brt_pending_apply(), which is called at the
beginning of spa_sync(), before pending DMU writes/frees are issued.
Freeing a dedup block is the only thing that can decrement dde_refcount,
so there's no way for it to drop to zero before applying the clone bumps
it.
Further, even if it _could_ go to zero, it wouldn't be necessary to fill
the entry from the block. The phys content is not cleared until the free
is issued, which happens when the refcount goes to zero, when the last
real free comes through. The cloned block should be identical to what's
in the phys already, so the fill should be a no-op anyway.
I've replaced this with an assertion because this is all very dependent
on the ordering in which BRT and DDT changes are applied, and that might
change in the future.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-By: Klara, Inc.
Closes #15004
2023-06-30 19:01:58 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This entry already existed (dde_type is real), so it must
|
|
|
|
* have refcnt >0 at the start of this txg. We are called from
|
|
|
|
* brt_pending_apply(), before frees are issued, so the refcnt
|
|
|
|
* can't be lowered yet. Therefore, it must be >0. We assert
|
|
|
|
* this because if the order of BRT and DDT interactions were
|
|
|
|
* ever to change and the refcnt was ever zero here, then
|
|
|
|
* likely further action is required to fill out the DDT entry,
|
|
|
|
* and this is a place that is likely to be missed in testing.
|
|
|
|
*/
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ASSERT3U(ddt_phys_refcnt(dde->dde_phys, v), >, 0);
|
ddt_addref: remove unnecessary phys fill when refcount is 0
The previous comment wondered if this case could happen; it turns out
that it really can't.
This block can only be entered if dde_type and dde_class are "real";
that only happens when a ddt entry has been previously synced to a ddt
store, that is, it was created on a previous txg. Since its gone through
that sync, its dde_refcount must be >0.
ddt_addref() is called from brt_pending_apply(), which is called at the
beginning of spa_sync(), before pending DMU writes/frees are issued.
Freeing a dedup block is the only thing that can decrement dde_refcount,
so there's no way for it to drop to zero before applying the clone bumps
it.
Further, even if it _could_ go to zero, it wouldn't be necessary to fill
the entry from the block. The phys content is not cleared until the free
is issued, which happens when the refcount goes to zero, when the last
real free comes through. The cloned block should be identical to what's
in the phys already, so the fill should be a no-op anyway.
I've replaced this with an assertion because this is all very dependent
on the ordering in which BRT and DDT changes are applied, and that might
change in the future.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Sponsored-By: Klara, Inc.
Closes #15004
2023-06-30 19:01:58 +03:00
|
|
|
|
ddt: add "flat phys" feature
Traditional dedup keeps a separate ddt_phys_t "type" for each possible
count of DVAs (that is, copies=) parameter. Each of these are tracked
independently of each other, and have their own set of DVAs. This leads
to an (admittedly rare) situation where you can create as many as six
copies of the data, by changing the copies= parameter between copying.
This is both a waste of storage on disk, but also a waste of space in
the stored DDT entries, since there never needs to be more than three
DVAs to handle all possible values of copies=.
This commit adds a new FDT feature, DDT_FLAG_FLAT. When active, only the
first ddt_phys_t is used. Each time a block is written with the dedup
bit set, this single phys is checked to see if it has enough DVAs to
fulfill the request. If it does, the block is filled with the saved DVAs
as normal. If not, an adjusted write is issued to create as many extra
copies as are needed to fulfill the request, which are then saved into
the entry too.
Because a single phys is no longer an all-or-nothing, but can be
transitioning from fewer to more DVAs, the write path now has to keep a
copy of the previous "known good" DVA set so we can revert to it in case
an error occurs. zio_ddt_write() has been restructured and heavily
commented to make it much easier to see what's happening.
Backwards compatibility is maintained simply by allocating four
ddt_phys_t when the DDT_FLAG_FLAT flag is not set, and updating the phys
selection macros to check the flag. In the old arrangement, each number
of copies gets a whole phys, so it will always have either zero or all
necessary DVAs filled, with no in-between, so the old behaviour
naturally falls out of the new code.
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <rob.norris@klarasystems.com>
Co-authored-by: Don Brady <don.brady@klarasystems.com>
Sponsored-by: Klara, Inc.
Sponsored-by: iXsystems, Inc.
Closes #15893
2023-06-20 04:09:48 +03:00
|
|
|
ddt_phys_addref(dde->dde_phys, v);
|
2023-03-10 22:59:53 +03:00
|
|
|
result = B_TRUE;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* At the time of implementating this if the block has the
|
|
|
|
* DEDUP flag set it must exist in the DEDUP table, but
|
|
|
|
* there are many advocates that want ability to remove
|
|
|
|
* entries from DDT with refcnt=1. If this will happen,
|
|
|
|
* we may have a block with the DEDUP set, but which doesn't
|
|
|
|
* have a corresponding entry in the DDT. Be ready.
|
|
|
|
*/
|
|
|
|
ASSERT3S(dde->dde_class, ==, DDT_CLASSES);
|
|
|
|
ddt_remove(ddt, dde);
|
|
|
|
result = B_FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
ddt_exit(ddt);
|
|
|
|
spa_config_exit(spa, SCL_ZIO, FTAG);
|
|
|
|
|
|
|
|
return (result);
|
|
|
|
}
|
|
|
|
|
2020-04-15 21:14:47 +03:00
|
|
|
ZFS_MODULE_PARAM(zfs_dedup, zfs_dedup_, prefetch, INT, ZMOD_RW,
|
2019-09-06 00:49:49 +03:00
|
|
|
"Enable prefetching dedup-ed blks");
|