Well, you said SAN, so I'm assuming you have VMFS datastores in LUNs in the volume(s)?
And taking a wild guess: They're not thin provisioned either ("space reserve")?
Then you will not "see" the effect of the deduplication within the volume(s)!
You can however see the effect at the aggregate level, e.g. "storage aggregate show-efficiency".
If you want to see the savings at the volume level, you'll have to thin provision the LUNs:
"lun modify -space-reserve disabled"
No adverse effects as far as I can see, since you said, you're not using snapshots (which could use up the space within the volume).
dedupe pro:
- more physical space in the aggregate (not necessarily logical, depends on if the volumes are thin provisioned or not)
- more performance (higher probability for cache hits, more free blocks for writes)
dedupe con:
- less performance (see above)
- impact on controller while dedupe is running (do it during off-hours)
In contrast to your plans, I'd even evaluate, if you can switch on "inline-dedupe".
It's opportunistic, i.e. only executed if it doesn't get in the way of your primary workload.
It takes load off your backend if it succeeds, since then only pointers have to be written instead of also data blocks.
Depends on the overall utilization of your system, though. But generally speaking with a virtualization workload it should improve your performance, even with a small system like yours (provided you don't have stupid things in your VMDKs like mis-alignment or databases - which generally don't dedupe at all)
Hope that helps
Sebastian
