topic Re: Volume takes much more space than expected in ONTAP Discussions

Volume takes much more space than expected

axsys — Thu, 05 Jun 2025 05:04:55 GMT

Hi Guys,

So I've got this volume called "volddevprod" and it's taking double of what the actual size of the data is and I hoped you guys would be able to help me out on the case.
I get that different file systems show different sizes but the actual data that is used on this volume is around 800GB and I see almost 1.5TB used. So there needs to be some kind of misconfiguration.

Below you can see some output from the general sizing / deduplication commands. I've only came across the vol status -S command and found it strange that there's deduplicated data but it's not showing up on my df -s. We do not run any snapshots on this volume but have a snapmirror on it every 30 minutes. Has anyone got an idea what this is about?

aggr show_space

Space allocated to volumes in the aggregate
volddevprod 1797GB 1451GB volume

df -Vg

Filesystem               total       used      avail capacity Mounted on
/vol/volddevprod/       1787GB     1430GB      357GB      80% /vol/volddevprod/
snap reserve               0GB        0GB        0GB       0% /vol/volddevprod/..

vol status -S

Volume : volddevprod

      Feature                                           Used      Used%
      --------------------------------      ----------------      -----
      User Data                                        782GB        44%
      Filesystem Metadata                             1.50GB         0%
      Inodes                                          72.5MB         0%
      Deduplication                                    645GB        36%
      Snapshot Spill                                  1.29MB         0%
      Quota Metafiles                                 24.0KB         0%

      Total                                           1.39TB        80%

df -s -g

Filesystem used saved %saved
/vol/volddevprod/ 1430GB 0GB 0%

sis status

Path State Status Progress
/vol/volddevprod Enabled Idle Idle for 13:33:32

We run Data Ontap 8.2.2P2 7-mode since late January 2015 but had the same issue on Data Ontap 8.1.2P3 7-mode already.

Thanks!

Re: Volume takes much more space than expected

paulstringfellow — Sun, 15 Feb 2015 16:19:03 GMT

have you had a look to see if there is a baseline snapmirror snapshot in place?

Re: Volume takes much more space than expected

ekashpureff — Mon, 16 Feb 2015 02:22:21 GMT

Axsys -

As Paul mentioned, it's probably a snapshot issue.

I didn't see any 'snap list' output for the volume.

It may be SnapMirror, or any other Snapshot copies causing the space usage.

I hope this response has been helpful to you.

At your service,

Eugene E. Kashpureff, Sr.
Independent NetApp Consultant http://www.linkedin.com/in/eugenekashpureff
Senior NetApp Instructor, IT Learning Solutions http://sg.itls.asia/netapp
(P.S. I appreciate 'kudos' on any helpful posts.)

Re: Volume takes much more space than expected

axsys — Wed, 18 Feb 2015 09:49:13 GMT

Sorry guys, Thanks for the reply, been away the last 2 days!

There's a snapmirror in place. Every 30 minutes to be exact. But to my knowledge you'd clearly see that in the df -Vg in the snap reserve which is stating 0 GB.

snap list volddevprod
Volume volddevprod
working...

%/used %/total date name
---------- ---------- ------------ --------
0% ( 0%) 0% ( 0%) Feb 18 10:30 fil-01-dr(2014870175)_volddevprod.17505 (snapmirror)

Re: Volume takes much more space than expected

axsys — Mon, 23 Feb 2015 13:21:01 GMT

*BUMP*

Anyone has any idea?

Cheers!

Re: Volume takes much more space than expected

axsys — Thu, 26 Feb 2015 13:39:23 GMT

We were just helped via NetApp case. If anyone ever runs into the issue re-run sis with "sis start -s /vol/volname".

We had stale fingerprints and due to a bug in ontap 8.1.2 http://mysupport.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=657692 the space has never been freed. With running the above -s command sis dedup's the whole volume and all existing files again. After that the space was freed. Make sure to run that outside peak times as that operation will consume lot of system ressources.