when using the disk-list-info API command, we sometimes get inconsistent info - some disks missing from the list. Seems to happen more on systems with more disks. (e.g. happens semi-regularly on a system running 8.0.2 7-Mode with 60 odd disks; doesn't happen on systems with less disks.)
Found one reference to this before: http://communities.netapp.com/thread/1959
It's inconsistent enough that it's a pain to troubleshoot, so wondered if anyone had any solutions already: - is this a known issue? resolved in any OnTap version? - ways to avoid it? (does limiting the attributes returned in the result set help?) -does using perf-object-instance-list-info disk to get the disks, then looping through them via disk-list-info avoid the issue?
Steve Francis
LogicMonitor Inc
sfrancis@logicmonitor.com www.logicmonitor.com Ph: 1 888 41 LOGIC x500 Ph: 1 805 698 0770 NetApp monitoring made easy.
On Aug 26, 2011, at 9:06 AM, Steve Francis wrote:
Seems to happen more on systems with more disks. (e.g. happens semi-regularly on a system running 8.0.2 7-Mode with 60 odd disks; doesn't happen on systems with less disks.)
Any feel for the frequency? Just ran through a couple dozen iterations on a mix of systems, both DS4243 and DS14mk*'s with 336 to 1152 disks (mostly running 8.0.1P5, though some still back on 7.3.x) and it all came back as expected.
when using the disk-list-info API command, we sometimes get inconsistent info - some disks missing from the list.
Are they missing altogether? Test I ran was just counting size of array from child_get('disk-details')->children_get.
Thanks for the datapoints.
Yes, the missing disks are missing altogether - e.g. for one filer, most runs report 65 disks, but some report 58. Always seems to the same ones missing.
Frequency wise - it seems to occur about one run in 10 on the system in question. But, we've not seen it elsewhere, even on systems with over 500 disks. And more interestingly, the partner head of the system that does it, that is running the same OnTap version, with a similar number of disks, never exhibits the issue.
So something specific to that particular head - but as it's not ours (but one of our customers, just using LogicMonitor to monitor it), we have to rely on him to open a case with netApp.
Thanks
Steve Francis * * LogicMonitor Inc
sfrancis@logicmonitor.com www.logicmonitor.com Ph: 1 888 41 LOGIC x500 Ph: 1 805 698 0770 My blog: LogicMonitor’s Hosted Monitoring – best support just got betterhttp://blog.logicmonitor.com/2011/08/29/logicmonitors-hosted-monitoring-better-support-just-got-better/ [image: Twitter] http://twitter.com/logicmonitor Latest tweet: LogicMonitor wins another award: http://t.co/0JzMizx. Thanks! Follow @logicmonitor http://twitter.com/logicmonitor http://twitter.com/?status=@logicmonitor%20&in_reply_to_status_id=109689207169097730&in_reply_to=logicmonitor Replyhttp://twitter.com/?status=@logicmonitor%20&in_reply_to_status_id=109689207169097730&in_reply_to=logicmonitor http://twitter.com/?status=RT%20%40logicmonitor%3A%20LogicMonitor%20wins%20another%20award%3A%20http%3A%2F%2Ft.co%2F0JzMizx.%20Thanks! Retweethttp://twitter.com/?status=RT%20%40logicmonitor%3A%20LogicMonitor%20wins%20another%20award%3A%20http%3A%2F%2Ft.co%2F0JzMizx.%20Thanks! 11:08 Sep-02http://twitter.com/logicmonitor/statuses/109689207169097728 Get this email app! http://www.wisestamp.com/apps/twitter?utm_source=extension&utm_medium=email&utm_term=twitter&utm_campaign=apps
Signature powered by http://r1.wisestamp.com/r/landing?u=1d25d9ba0c4ca423&v=2.7.2.0&t=1314996616923&promo=5&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_5 WiseStamphttp://r1.wisestamp.com/r/landing?u=1d25d9ba0c4ca423&v=2.7.2.0&t=1314996616923&promo=5&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_5
On Wed, Aug 31, 2011 at 8:29 PM, Kevin Graham < kgraham@industrial-marshmallow.com> wrote:
On Aug 26, 2011, at 9:06 AM, Steve Francis wrote:
Seems to happen more on systems with more disks. (e.g. happens semi-regularly on a system running 8.0.2 7-Mode with 60 odd disks; doesn't happen on systems with less disks.)
Any feel for the frequency? Just ran through a couple dozen iterations on a mix of systems, both DS4243 and DS14mk*'s with 336 to 1152 disks (mostly running 8.0.1P5, though some still back on 7.3.x) and it all came back as expected.
when using the disk-list-info API command, we sometimes get inconsistent info - some disks missing from the list.
Are they missing altogether? Test I ran was just counting size of array from child_get('disk-details')->children_get.