aboutsummaryrefslogtreecommitdiffstats
path: root/man/man4/zfs.4
diff options
context:
space:
mode:
authorRob N <[email protected]>2023-07-01 02:01:58 +1000
committerGitHub <[email protected]>2023-06-30 09:01:58 -0700
commit61ab05cac74830f2658cd16138c5876b4b31b4fa (patch)
tree2cfb389112ecee966363ceb1bdb3774bdab25ea1 /man/man4/zfs.4
parent233425a153af74b7d5ef9730684f3a1d61ff8f11 (diff)
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 <[email protected]> Signed-off-by: Rob Norris <[email protected]> Sponsored-By: Klara, Inc. Closes #15004
Diffstat (limited to 'man/man4/zfs.4')
0 files changed, 0 insertions, 0 deletions