ddt_addref: remove unnecessary phys fill when refcount is 0
commit61ab05cac74830f2658cd16138c5876b4b31b4fa
authorRob N <rob.norris@klarasystems.com>
Fri, 30 Jun 2023 16:01:58 +0000 (1 02:01 +1000)
committerGitHub <noreply@github.com>
Fri, 30 Jun 2023 16:01:58 +0000 (30 09:01 -0700)
tree2cfb389112ecee966363ceb1bdb3774bdab25ea1
parent233425a153af74b7d5ef9730684f3a1d61ff8f11
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
module/zfs/ddt.c