Skip to main content
NetApp Knowledgebase

The output of snap list reports 0 percent used space while the command snap status reports non-zero used space

 

Applies to

  • ONTAP

Answer

  Various reasons can cause the snap list reports 0% while the snap status command reports non-zero values for 'used space' as below:


filer1*> snap list my_datavol
Volume my_datavol
working......
 
  %/used       %/total  date          name
----------  ----------  ------------  --------
  0% ( 0%)    0% ( 0%)  Jul 21 02:40  filer1(0123456789)_my_datavol-base.0 (busy,snapvault)
  0% ( 0%)    0% ( 0%)  Jul 21 01:30  2015-07-21_0130+0200_daily_backup_filer1_my_datavol
  0% ( 0%)    0% ( 0%)  Jul 20 01:30  2015-07-20_0130+0200_daily_backup_filer1_my_datavol

filer1*>

filer1*> snap status my_datavol
Volume my_datavol
snapid  status     date           ownblks release fsRev name
------  ------     ------------   ------- ------- ----- --------
180     complete   Jul 18 02:42    568520     8.2 23589 filer1(0536901363)_my_datavol-base.0
178     complete   Jul 18 01:30    740390     8.2 23589 2015-07-18_0130+0200_daily_backup_filer1_my_datavol
175     complete   Jul 17 01:30    738643     8.2 23589 2015-07-17_0130+0200_daily_backup_filer1_my_datavol

filer1*>

 

 

  1. The snapshot used space is really 0%, as there is no deletion of data after the snapshot is taken.
  2. The snapshot used space is very small in comparison to the active blocks in the volume.For more information, see BUG 908831
  3. If the number of blocks used by the snapshot are lesser than 1% of the blocks in active file system, then the command snap list is rounded to 0% ,while the snap status reports non-zero values.
  4. When the snapshots are in re-computing phase for snapmirror source controllers, the snap list will report 0% and will clear off when the computation is done.
  5. The WAFL scanner  (own_block) does not run to completion, that results in the snap list output reporting as 0% utilized.

The following four conditions can affect the WAFL scan ownblock scanner from completing:

  1. BUG 142292: This issue is fixed in almost all current versions of Data ONTAP, Data ONTAP 6.5 onwards.
  2. BUG 192652: Snapshot deletion fails to update the ownblock scanner. This issue is fixed through the fix of BUG 226848 and is available in almost all the current versions of Data ONTAP, Data ONTAP 7.2.2 onwards.
  3. BUG 495114 The ownblock scanner stuck at fbn 0 for volumes with large number of snapshots. This issue is fixed Data ONTAP 8.0.2 onwards.
  4. BUG 934737: The ownblock scanner times out due to a large number of sparse trails while attempting to find the next valid fbn.
    This issue happens if the flexible volume was originally created with large size and then it shrinks to a small size. The container file will still be large, causing the ownblock scanner to timeout.

 
 

 

Additional Information