Of course, f you know the right people...you can get the Ontap API software. I am able to query 8 different filers, collect info on about 200 volumes (volume info, aggr info, qtree info--> which there are 1000's of qtrees) in about 3-4 seconds and no SSH involved at all.
perl library, jar file, .NET, c++...lots of different ways to plug into ONTAP.
I believe it comes in on the http admin route.
--tmac Tim McCarthy Principal Consultant
RedHat Certified Engineer 804006984323821 (RHEL4) 805007643429572 (RHEL5)
On Thu, Jun 9, 2011 at 8:10 PM, A Darren Dunham ddunham@taos.com wrote:
On Wed, Jun 08, 2011 at 08:24:54AM +0200, Sander Klein wrote:
Maybe it's related to the ssh client you're using?
Pretty sure it's not a network or SSH issue.
I just got a nice reproduction, and the data I got really surprised me. (BTW, the filer I'm hitting below is running 8.0.1P2).
I have a script that checks "qtree stats" periodically. And to save on SSH setup/teardown costs, it runs a sysstat in the same command. But the script then works through the data and hands back a summary. I don't have a copy of the raw stuff coming back. But I saw some oddities that made it appear that it was not getting all the data.
So I ran the following command and was going to put it in a crontab to run mutliple times so I could see if it went off. "qtree stats; sysstat -c 1 5"
Well, while testing the script, on the 4th time I ran it I got "short" output. On this filer, that command should return 179 lines. On the last try it only returned 10, but not simply the first 10. Here's a (slightly obfuscated) version of what I got back:
-----BEGIN No qtrees are in use in Volume vol0 Volume Tree NFS ops CIFS ops -------- -------- ------- -------- perf [user]perf 1773 0 Volume Tree NFS ops CIFS ops -------- -------- ------- -------- test_vm_volume vm_vol 0 0 CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 77% 28350 0 0 290677 82179 194167 415548 0 0 6s -----END
In reality, the "perf" volume has over 100 qtrees. The one shown above is the first line in the list when the command is complete. So it's not simply truncating the total output, it has managed to drop a portion of the output of one command.
If it were a network or SSH problem, I wouldn't expect a gap in the middle of a command, nor would I expect it exactly on a nice line boundary.
Looks like I can open a ticket now.
-- Darren