Exabyte dedup_table_size reported on ZFS 2.3 without fast dedup.

[IvanVolosyuk]

System information

Type	Version/Name
Distribution Name	Gentoo
Distribution Version	Live
Kernel Version	6.12.12-gentoo
Architecture	x86_64
OpenZFS Version	2.3.0
ECC RAM	Yes

Describe the problem you're observing

I tried to make sense of new pool properties before migrating to fast dedup. The output puzzled me:

zpool list -o dedup_table_size net
DDTSIZE
  15.9E

zpool list -p -o dedup_table_size net
             DDTSIZE
18338641226299867136

Describe how to reproduce the problem

I didn't do anything special, I have updated to ZFS-2.3.0 from ZFS-2.2.7 and didn't do any feature upgrades (carefully considering migrating to fast dedup). I'm pretty sure ZFS 2.2.7 had reasonable value for size on disk.

  pool: net
 state: ONLINE
status: Some supported and requested features are not enabled on the pool.
        The pool can still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(7) for details.
  scan: scrub repaired 0B in 00:43:16 with 0 errors on Fri Jan 17 04:43:16 2025
config:

        NAME                                       STATE     READ WRITE CKSUM
        net                                        ONLINE       0     0     0
          ata-ST10000VN0008-2PJ103_ZS5131ST-part4  ONLINE       0     0     0

errors: No known data errors

 dedup: DDT entries 1920038, size 15.9E on disk, 306M in core

bucket              allocated                       referenced          
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     1    1.14M   99.6G   53.9G   54.3G    1.14M   99.6G   53.9G   54.3G
     2     485K   57.1G   54.4G   54.5G    1.04M    125G    119G    119G
     4     207K   24.6G   24.3G   24.3G     992K    117G    116G    116G
     8    7.90K   66.0M   35.1M   47.8M    82.5K    649M    348M    483M
    16    12.0K   38.3M   23.2M   49.7M     309K    947M    575M   1.25G
    32       84    426K    230K    464K    3.57K   18.8M   9.04M   19.3M
    64       23    149K     24K     92K    2.10K   10.2M   2.04M   8.39M
   128        7   3.50K   3.50K     28K    1.34K    686K    686K   5.36M
   256        4   5.50K   5.50K     16K    1.33K   1.59M   1.59M   5.30M
   512        3   1.50K   1.50K     12K    1.97K   1008K   1008K   7.88M
 Total    1.83M    181G    133G    133G    3.54M    344G    290G    292G

Looks like reporting is off for legacy dedup, which makes it kinda scary to upgrade the pool and try the new feature.

For comparison the output from zpool status -D net on ZFS 2.2.7.

  pool: net
 state: ONLINE
  scan: scrub repaired 0B in 00:43:16 with 0 errors on Fri Jan 17 04:43:16 2025
config:

	NAME                                       STATE     READ WRITE CKSUM
	net                                        ONLINE       0     0     0
	  ata-ST10000VN0008-2PJ103_ZS5131ST-part4  ONLINE       0     0     0

errors: No known data errors

 dedup: DDT entries 1920038, size 283 on disk, 167 in core

bucket              allocated                       referenced          
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     1    1.14M   99.6G   53.9G   54.3G    1.14M   99.6G   53.9G   54.3G
     2     485K   57.1G   54.4G   54.5G    1.04M    125G    119G    119G
     4     207K   24.6G   24.3G   24.3G     992K    117G    116G    116G
     8    7.90K   66.0M   35.1M   47.8M    82.5K    649M    348M    483M
    16    12.0K   38.3M   23.2M   49.7M     309K    947M    575M   1.25G
    32       84    426K    230K    464K    3.57K   18.8M   9.04M   19.3M
    64       23    149K     24K     92K    2.10K   10.2M   2.04M   8.39M
   128        7   3.50K   3.50K     28K    1.34K    686K    686K   5.36M
   256        4   5.50K   5.50K     16K    1.33K   1.59M   1.59M   5.30M
   512        3   1.50K   1.50K     12K    1.97K   1008K   1008K   7.88M
 Total    1.83M    181G    133G    133G    3.54M    344G    290G    292G

[IvanVolosyuk]

I think the issues goes away after I do some writes using the same hash algorithm, but I'm not 100% sure if that what triggered the correct numbers to appear. It definitely stayed broken before that when I was writting new data using different dedup hash function.