Re: snapshot-list-info hangs

janosch_rohdewald · ‎2012-02-29

Hi all

Running the SDK (using 4.1) command 'snapshot-list-info' on some volumes (always the same ones) either hangs forever or returns the following error after some time:

'<results reason="Cannot get snapshot list info" status="failed" errno="13001"/>'

I tested it with Perl (on linux) and with the NetApp provided tool ZExplore (on Windows), so it doesn't seem to be a language spec. problem. I used the following snippet in ZExplore:

<?xml version="1.0" encoding="UTF-8"?>

<snapshot-list-info>

<target-name>testVol1</target-name>

<target-type>volume</target-type>

</snapshot-list-info>

</netapp>

Running 'snap list' on the same volume - even while the SDK command hangs - works as it should.

The error is reproducible always on the same volumes. snapshot-list-info on other volumes and/or on the same filers runs without a problem.

Thanks for helping and regards

Janosch

rle · ‎2012-02-29

Janosch -

What version of the DataONTAP are you running?

Regards,

- Rick -

janosch_rohdewald · ‎2012-03-05

Sorry for the late response! We're using the version 8.0.2P2 in 7-mode.

rle · ‎2012-03-05

Janosch -

Try setting terse to true.

<?xml version="1.0" encoding="UTF-8"?>

<snapshot-list-info>

<target-name>testVol1</target-name>

<target-type>volume</target-type>

</snapshot-list-info>

</netapp>

Regards,

- Rick -

janosch_rohdewald · ‎2012-03-06

Rick,

It works with terse, but then the used size is omitted. That's actually what I'm looking for. If there is another way to get the used size of all snapshots of a volume I'd be happy as well!

Regards,

Janosch

rle · ‎2012-03-06

Janosch -

Are there more snapshots on the volumes that are not responding than the volumes that are responding?

Regards,

- Rick -

janosch_rohdewald · ‎2012-03-07

Hi Rick

Do you ask if there are more volumes responding than not? If so: no, from about 80% of all volumes (hundreds) on all filers I get a response.

Regards

Janosch

rle · ‎2012-03-07

Hi Janosch -

That's great that 80% of all the volumes are responding. I'm trying to figure out why some of the volumes are not responding to returning total and cumulative-total. Are these unresponsive volumes in a restricted or offline state, are they in a SnapMirror of SnapVault transfer, or do they have a lot more snapshots than the succeeding volumes?

Regards,

- Rick -

janosch_rohdewald · ‎2012-03-07

Hi Rick

Unfortunately I have to answer no to all of your questions, their neither restricted nor offline, not in SnapMirror or SnapVault transfer (it also occurs on source vols) and they have as many snapshots as the other volumes. I got a sample volume for you:

vol status renamedVol

Volume State Status Options

renamedVol online raid_dp, flex create_ucode=on,

convert_ucode=on

Volume UUID: c321ff2c-6207-11df-96d7-00aaaa000bb

Containing aggregate: 'renamedAggr'

Volinfo mode: 7-mode

Thanks,

Janosch

rle · ‎2012-03-07

Hi Janosch -

Sorry, I'm out of ideas for the moment. Please attach snap list, and I will ask around.

Regards,

- Rick -

janosch_rohdewald · ‎2012-03-08

Hi Rick,

I hope the snap list helps you finding the problem:

*> snap list renamedVol

Volume renamedVol

working......

%/used %/total date name

---------- ---------- ------------ --------

0% ( 0%) 0% ( 0%) Mar 08 08:59 snapMirrorFiler(0118054782)_renamedVol.81394 (snapmirror)

0% ( 0%) 0% ( 0%) Mar 08 08:56 snapMirrorFiler(0118054782)_renamedVol.81393

0% ( 0%) 0% ( 0%) Mar 08 08:01 hourly.0

0% ( 0%) 0% ( 0%) Mar 08 07:01 hourly.1

0% ( 0%) 0% ( 0%) Mar 08 00:06 nightly.0

0% ( 0%) 0% ( 0%) Mar 07 17:03 hourly.2

0% ( 0%) 0% ( 0%) Mar 07 16:02 hourly.3

0% ( 0%) 0% ( 0%) Mar 07 15:02 hourly.4

0% ( 0%) 0% ( 0%) Mar 07 14:03 hourly.5

0% ( 0%) 0% ( 0%) Mar 07 13:02 hourly.6

0% ( 0%) 0% ( 0%) Mar 07 12:02 hourly.7

0% ( 0%) 0% ( 0%) Mar 07 11:02 hourly.8

0% ( 0%) 0% ( 0%) Mar 07 10:03 hourly.9

0% ( 0%) 0% ( 0%) Mar 07 09:03 hourly.10

0% ( 0%) 0% ( 0%) Mar 07 08:01 hourly.11

0% ( 0%) 0% ( 0%) Mar 07 07:01 hourly.12

0% ( 0%) 0% ( 0%) Mar 07 00:05 nightly.1

0% ( 0%) 0% ( 0%) Mar 06 17:02 hourly.13

0% ( 0%) 0% ( 0%) Mar 06 00:05 nightly.2

0% ( 0%) 0% ( 0%) Mar 05 00:05 weekly.0

0% ( 0%) 0% ( 0%) Mar 04 10:07 dfm_sv_backup(destvFiler)destVol.0 (snapvault,acs)

0% ( 0%) 0% ( 0%) Mar 04 00:05 nightly.3

0% ( 0%) 0% ( 0%) Mar 03 00:05 nightly.4

1% ( 0%) 1% ( 0%) Mar 02 00:06 nightly.5

1% ( 0%) 1% ( 0%) Mar 01 00:05 nightly.6

1% ( 0%) 1% ( 0%) Feb 29 00:06 nightly.7

1% ( 0%) 1% ( 0%) Feb 28 00:06 nightly.8

1% ( 0%) 1% ( 0%) Feb 27 00:05 weekly.1

1% ( 0%) 1% ( 0%) Feb 26 00:07 nightly.9

1% ( 0%) 1% ( 0%) Feb 25 00:04 nightly.10

1% ( 0%) 1% ( 0%) Feb 24 00:06 nightly.11

2% ( 0%) 1% ( 0%) Feb 20 00:08 weekly.2

2% ( 0%) 1% ( 0%) Feb 19 10:08 dfm_sv_backup(destvFiler)destVol.2 (acs)

2% ( 0%) 1% ( 0%) Feb 13 00:07 weekly.3

Regards,

Janosch

janosch_rohdewald · ‎2012-03-15

Hi Rick

What's the actual state of your analysis?

Regards

Janosch

rle · ‎2012-03-19

Hi Janosch -

I don't know why some of the volumes are having problems, especially if one of the volumes' snapshot list is above. There doesn't seem to be a lot of churn. I have forward this thread around to see if I can get some answers.

Regards,

- Rick -