Dedupe causing INCREASE in disk usage?

[andrewimi]

We wanted to see how well our PACS data (dicom files primarily) deduplicates. Two separtate n3400 systems each had nearly identical 3TB LUNs carved out of 12TB flexvols. Nothing else existed on the volume. The 3TB LUN was approx 80% full. I took one of the two systems, and deduped it. The results left me perplexed. Before running the dedupe, df -h showed the volume as ~3085GB used (that is also what the 2nd, untouched system is still showing). However, after the dedupe, it is reporting 5290GB used. There has been only minimal new data written to the LUN on that volume. When I run df -h -s, I again see 5290GB used, with 838GB saved (14%). That ratio is good, but the end result is I haven't apparently saved any space, instead I've lost space, approximately 2TB of space!

Can anyone shed light as to why the numbers are showing what they are showing?

[christoph_reeg]

Do you have space guarantee enabled on this volume?

[andrewimi]

I'm not familiar with space guarantee (just getting my feet wet with ontap), but I do not think so... vol status outputs:

volume online raid_dp, flex nosnap=on, no_i2p=on, sis

[christoph_reeg]

That looks IMHO for guarentee=volume.

Can you do a "vol status -v"?

I observed something similar a few years ago and AFAIR it was a combination of volume space guarentee and space reservation for the lun.

[billshaffer]

Most likely it's tied up in snapshots.  When ASIS reclaims the deduped blocks, it's just like any other block-change operation - even though the block is technically free, it's still allocated to snapshots.

Does df show a lot of snapshot usage for the volume?

Bill

[andrewimi]

We do not use snapshots on this volume. DF does show a .snapshot volume, but it reports as 0 bytes.

[billshaffer]

Interesting.  Will you post the df output (df -h and df -h -s), as well and lun show -v <lun>?