Data ONTAP Discussions


Re: NFS Volume Showing Incorrect Provisioned Space.

do an "aggr show_space -h" and post that here.

Could it be that the volume has been very large (say, 16TB or bigger) and has been resized down to 1TB?

Re: NFS Volume Showing Incorrect Provisioned Space.

Hi I do run into same issue, moving VM to different datastore and deleting volume free up the space..


Re: NFS Volume Showing Incorrect Provisioned Space.


Have the same problem. The problem is a Dedup Bug. The fingerprint database fills up the place in the volume.

Solution from Netapp Support:



    A cleanup of the fingerprint database on a volume impacted by this issue is accomplished by running the following command:

    >  s <vol>

Note: Potential exists for storage efficiency to be decreased after executing this manual work-around. Consult NetApp Technical Support before executing 'sis start -s' on the affected volume. This is a very long-running process as it is building a new copy of the Fingerprint Database (FPDB) and then purging the old to reclaim the volume space.

    If the workload on the storage system imposed by running sis start -s is extremely large, a support engineer can guide the customer to use the following advanced-mode command on the impacted volume:

    >  sis check –d <vol>

Note: Dedupe operations for new data will not be performed while 'sis check -d' is running, expect when additional volume space is to be consumed while running this command.

Free volume space equal to the size of the fingerprint database file is needed to run the sis check command. Ensure that there is sufficient free space prior to running sis check. Additionally, the -d option should always be used to clear any existing SIS checkpoints on the volume. The presence of a checkpoint will delay the results of the workaround and could also result in an out-of-space condition.

    If possible, upgrade to a fixed release of Data ONTAP instead of executing the above commands/work-arounds. The FPDB's will be purged of stale records without having to run the above commands during the volume's next scheduled deduplication job. A maximum of 8 deduplication jobs can be executed at one time; subsequent jobs will be put in queue.


4.     Solution

5.      Users should upgrade to Data ONTAP release 8.1.2P4 or later.

6.      After upgrading to Data ONTAP release 8.1.2P4 or later, the first time deduplication is run on each volume it will automatically remove these stale fingerprints. During this time you may experience deduplication taking longer than expected. Subsequent operations will complete at normal operating times. This process of removing the stale fingerprints will temporarily consume additional space in both the deduplication enabled FlexVol volumes and their containing aggregates.

7.      If your FlexVol volume or the aggregate containing the FlexVol volume is 70% full or more it is recommended to run the "sis start -s /vol/<volname>" command for systems that are on 7-Mode or "volume efficiency start -vserver <vservername> -volume <volname> -scan-old-data true" command for systems that are running clustered Data ONTAP. This command will delete the existing fingerprint database and build a new one on the volumes and aggregates. This may be a long running operation; however it will not require additional space and will resolve any pre-existing issues with stale fingerprints. Deleting the deduplication metadata does not affect the savings already on disk or the access to the logical data.



Re: NFS Volume Showing Incorrect Provisioned Space.

I guess you didn't read the OP's post. He specifically said

justin.smith wrote:

the Datastore is empty. No snaps,no dedupe.

Also, the dedup bug you mentioned doesn't occupy that much space in the volume (75% in this case!). But without any info on the OnTap version of the OP, and/or the output of "aggr show_space", we cannot do any more debugging here I think...

It could also be that the volume was once thin-provisioned and resized to a ridiculously large size (16TB or even bigger); if you do that, your metadata grows a *lot* and the space used by the metadata will not be freed when the volume is being shrunk again, which can result in something like what the OP sees



Re: NFS Volume Showing Incorrect Provisioned Space.

Yes you are right; i didnt read that properly.

Regarding the Dedup Bug: In my case the Dedup Bug consumed about 900gb in a 1TB Volume, so 90 %. After i've done a "sis start -s /volname" only 100gb of the 1 TB Volume were filled..


Try the NEW Support Site!
NetApp Support Site