I have read a lot of information about planning RAM requirements forZFS deduplication. I've just upgraded my file server's RAM to support some very limited dedupe on ZFS zvols which I cannot use snapshots and clones on (as they're zvols formatted as a different filesystem) yet will contain much duplicated data.
I want to make sure that the new RAM I added will support the limited deduplication I intend to be doing. In planning, my numbers look good but I want to be sure.
How can I tell the current size of the ZFS dedupe tables (DDTs) on my live system? I read this mailing list thread but I'm unclear on how they're getting to those numbers. (I can post the output of zdb tank if necessary but I'm looking for a generic answer which can help others)
You can use the
zpool status -D poolnamecommand.The output would look similar to:
The important fields are the Total allocated blocks and the Total referenced blocks. In the example above, I have a low deduplication ratio. 40.2G is stored on disk in 37.5G of space. Or 2.51 million blocks in 2.35 million block's worth of space.
To get the actual size of the table, see:
DDT entries 2459286, size 481 on disk, 392 in core
2459286*392=964040112 bytes Divide by 1024 and 1024 to get: 919.3MB in RAM.
After reading the original email thread and @ewwhite's answer which clarified it, I think this question needs an updated answer, as the answer above only covers half of it.
As an example, let's use the output on my pool. I used the command
zdb -U /data/zfs/zpool.cache -bDDD My_pool. On my system I needed the extra-Uarg to locate the ZFS cache file for the pool, which FreeNAS stores in a different location from normal; you may or may not need to do that. Generally tryzdbwithout-Ufirst, and if you get a cache file error, then usefind / -name "zpool.cache"or similar to locate the file it needs.This was my actual output and I've interpreted it below:
What it all means, and working out the actual dedup table size:
The output shows two sub-tables, one for blocks where a duplicate exists (DDT-sha256-zap-duplicate) and one for blocks where no duplicate exists (DDT-sha256-zap-unique)/. The third table below them gives an overall total across both of these, and there's a summary row below that. Looking only at the "total" rows and the summary gives us what we need:
Let's do some number crunching.
The block count works like this: Number of entries related to duplicate blocks = 771295, number of entries related to unique blocks = 4637966, total entries in DDT table should be 771295+4637966 = 5409261. So the number of blocks in millions (binary millions that is!) would be 5409261 / (1024^2) = 5.158 million. In the summary we find there are 5.16M blocks total.
RAM needed works like this: The 771295 entries for duplicate blocks each occupy 165 bytes in RAM, and the 4637966 entries for unique blocks each occupy 154 bytes in RAM, so the total RAM needed for the dedup table right now = 841510439 bytes = 841510439 / (1024^2) MBytes = 803 MB = 0.78 GB of RAM.
(The on-disk size used can be worked out the same way, using the "size on disk" figures. Clearly ZFS is trying to use disk I/O efficiently and taking advantage of the fact that disk space taken up by the DDT isn't normally an issue. So it looks like ZFS is simply allocating a complete 512 byte sector for each entry, or something along those lines, instead of just 154 or 165 bytes, to keep it efficient. This might not include any allowance for multiple copies held on disk, which ZFS usually does.)
The total amount of data stored, and the benefit from deduping it: From the total DDT statistics, 715 Gbytes ("715G") of data is stored using just 578 GBytes ("578G") of allocated storage on the disks. So our dedup space saving ratio is (715 GB of data) / (578 GB space used after deduping it) = 1.237 x, which is what the summary is telling us ("dedup = 1.24").