2011-03-30 03:11 PM
I have a 30 gig volume which was previously deduped but I set it to manual for a while and now have set it back to scheduled again.
Rather than wait for the schedule to kick in I clicked start within system manager and the 14 gig of free space in that volume almost vanished while it was scanning. It is currently upto 'Status active [1.41 TB searched]'.
Why on earth has a 30 gig volume required almost 1.5 TB of searching so far ?
The actual contents of the volume are 4 luns which contain the vsphere boot from san installs so they really don't have much data in them at all.
I also have a volume which is sat at 0% merged for the last hour.
Anyone able to give some urgent advice on this as im in the middle of a change window.
2011-03-30 11:58 PM
I saw the same issue on a VMware NFS volume last week: dedup was already running 4 days, and had searched 5.4TB (volume is 800GB).
This volume used to take a couple of hours.
I ran a full deduplication, instead of a partial one, and after a couple of hours it had finished.
Now scheduled dedup runs like a charm again (couple of hours instead of 4+ days).
This is the command to run a full deduplication: sis start -s /vol/volume_name
During a deduplication run, it's normal to see a temporarily drop in free space.
This is because it creates a fingerprint database of all 4kb blocks, which it uses to search for duplicate blocks.