Data Backup and Recovery

snap list returns 0% for every snapshot, after LUN secondary(primary too?) restores from SMO/SMSAP

jakub_wartak
3,037 Views

I've think i've just hit a DataONTAP bug. Netapp 7.3.2 here. Snap list displays 0% everywhere, after several SMSAP(think SMO) snap restores from secondary (not Volume Restores but LUN restores directly in the FlexVol area), df reports this:

Filesystem               total       used      avail capacity  Mounted on
/vol/sap_XXX_sapdata/       53GB       43GB        9GB      83%  /vol/sap_XXX_sapdata/
/vol/sap_XXX_sapdata/.snapshot        0GB       19GB        0GB     ---%  /vol/sap_XXX_sapdata/.snapshot

LUN size is 15GB (really used is somehow ~9GB):

/vol/sap_XXX_sapdata/sapdata1/sapdata01.lun     15g (16106127360)   (r/w, online, mapped)

snap list for volume:

Volume sap_XYZ_sapdata
working......

  %/used       %/total  date          name
----------  ----------  ------------  --------
  0% ( 0%)    0% ( 0%)  Feb 01 01:30  stor1(0151703761)_smsap_host1_XYZ_mirror_stor1_sap_XYZ_sapdata_1.18 (snapmirror)
  0% ( 0%)    0% ( 0%)  Feb 01 01:01  smsap_XYZ_host1_XYZ_f_h_1_f_h_1_8a4a65ed2ddfcee3012ddfceec8e0001_0
  0% ( 0%)    0% ( 0%)  Jan 31 17:01  smsap_XYZ_host1_XYZ_f_h_1_f_h_1_8a4a65ed2dde176a012dde1773ee0001_0 (snapvault)
  0% ( 0%)    0% ( 0%)  Jan 31 01:01  smsap_XYZ_host1_XYZ_f_h_1_f_h_1_8a4a65ed2ddaa881012ddaa88ad50001_0

snap delta for volume:

Volume sap_XYZ_sapdata
working...

From Snapshot   To                   KB changed  Time         Rate (KB/hour)
--------------- -------------------- ----------- ------------ ---------------

stor1(0151703761)_smsap_host1_XYZ_mirror_stor1_sap_XYZ_sapdata_1.18 Active File System   10315488       0d 05:13  1974886.024

smsap_XYZ_host1_XYZ_f_h_1_8a4a65ed2ddfcee3012ddfceec8e0001_0 stor1(0151703761)_smsap_host1_XYZ_mirror_stor1_sap_XYZ_sapdata_1.18 15924          0d 00:28  33022.119

smsap_XYZ_host1_XYZ_f_h_1_8a4a65ed2dde176a012dde1773ee0001_0 smsap_XYZ_host1_XYZ_f_h_1_8a4a65ed2ddfcee3012ddfceec8e0001_0 339048         0d 07:59  42411.925

smsap_XYZ_host1_XYZ_f_h_1_8a4a65ed2ddaa881012ddaa88ad50001_0 smsap_XYZ_host1_XYZ_f_h_1_8a4a65ed2ddaa881012ddaa88ad50001_0 10389664       0d 16:00  649331.453


Summary...

From Snapshot   To                   KB changed  Time         Rate (KB/hour)
--------------- -------------------- ----------- ------------ ---------------


smsap_XYZ_host1_XYZ_f_h_1_8a4a65ed2ddaa881012ddaa88ad50001_0 Active File System   21060124       1d 05:42  709088.452


If you take 10315488 kB and do math it is 9.837 GB since last snapshots (compared to AFS). The LUN size is 15GB, fractional_reserve=100%, LUN space reservation = enabled, snap reserve = 0%. There is 20.084 GB in snapshots, which is pretty close to what df .snapshot reports.

At least for me this is : LUN+LUN*fractional_reserve+space_used_by_snapshots= 15GB + 15GB + 20.084GB =~ 50 GB. Not sure how much of it is in fractional_reserver(BTW: how to check this?), i guess that at least: 19GB - (53GB - 43GB) = 19GB - 10GB = 9GB is in fractional_reserve, and this leaves me with 50GB-9GB = 41GB (pretty close value to the used space for Vol , as reported by df).

So why the hell snap list reports 0% everywhere? It looks like it doesn't support LUN snap restores "overwrite semantics"? Is this known "feature" ? In which version has this been patched?

-Jakub.

5 REPLIES 5

aborzenkov
3,037 Views

Where does 7.3.5 come from? Three of these bugs should be fixed in version you have and fourth (237378) is not fixed in any (released) version. Looks like you really hit it; even more, looks like everyone doing SFSR should see this bug. I have to check ☺

jakub_wartak
3,037 Views

Hi,

Data ONTAP 7.3.5 (GA) - Fixed ; here http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=142292

And yes, actually it would be interesting to see adoption of those products on the market...

-Jakub.

aborzenkov
3,037 Views

142292 is fixed in 6.5.3H1P4 ☺

jakub_wartak
3,037 Views

Haha, i guess you meant "fixed" I'm on 7.3.2, which was released before 7.3.5 and they backported the fix into 7.3.5 - that's how i understand it.

-J.

Public