enabled dedupe again but the volume space is rapidly vanishing

[darren_hedges]

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.

thanks

[vmsjaak13]

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.

Regards,

Niek