VMware and ZFS Deduplication

[David Paquette]

Dell PowerEdge with 32gb RAM and 6 x 600gb 15k drives, iSCSI connectivity. I know in our production environment (NetApp) dedupe is somewhere around 50% savings, but I am reading that FreeNAS ZFS dedupe is a resource hog. What are your thoughts? Do I have enough horsepower for it? I would love to realize even 30-40% savings with dedupe.

 

[cyberjock]

dedup is a memory hog. It's like walking up to the cliff. You can stand there and look over the canyon at the beauty. But, one nudge and you're dead meat. You might be okay with only 3.6TB of hard drive space. But keep in mind that if something goes wrong and you need more than 32GB of RAM for your dedup table you will lose complete access to your data until you build a system with more than 32GB of RAM. In the event of insufficient RAM for the dedup tables the consequence is the zpool will not mount. There is no fix except more RAM if your zpool locks you out.

Some people recommend as little as 2GB of RAM per TB, others recommend as much as 10GB of RAM per TB.

Personally, if I were in a production environment and downtime was unacceptable I wouldn't take the risk with dedup. For most users I explain it as "borderline irresponsible". For you, its a matter of how much risk you are willing to take.

Also keep in mind that your dedup tables will take away memory that will otherwise be used for ARC and temporary write cache, so performance may suffer from using dedup.

 

[jgreco]

I'm going to take a slightly less pessimistic point of view. At 32GB-to-3.6TB, the ratio is sufficient that I haven't seen anyone report catastrophes in that range. cyberjock is being appropriately paranoid in guiding you away from a feature that can be playing with fire. The FreeNAS developers have seen situations where pool import takes about 5GB RAM per TB of disk, so my guess would be that you'd be unlikely to wreck.

From a practical point of view, I seem to recall that WAFL uses fixed block sizes of 4K and that NetApp deduplication works on that basis. If that is true, it is worth considering that ZFS uses a variable block size, and that the resulting dedup savings would be likely to be at least a bit lower.

Since you've given us nothing to work with on the horsepower side of things, I'll mostly avoid that question. Dedup reduces write performance somewhat, but the reduced number of blocks improves ARC/L2ARC performance and responsiveness, so it is a tradeoff.

Do note that filling a ZFS pool results in bad things. Normally it is advised not to exceed 80%. ZFS and iSCSI are good at causing CoW fragmentation, so for iSCSI I feel that might be more like 60% (but it is very dependent on workload etc). dedup can help create free space, but you probably shouldn't be anxious to go filling modest amounts of generated free space with other new content.