Sounds like an RFE for me.
Richard D Borders CPR Escalations Engineer RTP, North Carolina USA - NetApp, Inc. Email: rborders@netapp.com Phone:(919) 476-5236 Cell: (919) 757 3727
-----Original Message----- From: John Stoffel [mailto:john.stoffel@taec.toshiba.com] Sent: Thursday, November 12, 2009 10:34 AM To: Leimann, Olaf Cc: John Stoffel; toasters@mathworks.com Subject: RE: Determining the current 'snapmirror throttle' value?
Leimann> Perhaps a silly question, but if "you" are doing the throttle Leimann> change, then why are you not logging that yourself for future Leimann> reference ? Script the thing (perl, sh, whatever).
Yeah, it is a silly question. Let me push back on you, why can't NetApp *tell* me what the current limit is? What's so hard about:
snapmirror throttle -q [<dest>]or something like that? My issue is that if sysadmin A makes a change, then script B makes another change, then sysadmin C want's to confirm the settings... it's just not possible. The only current answer is to just re-do your 'snapmirror throttle N <dest>' commands to force things to be what you expect.
Leimann> Another thing to look at: divide amount transferred by Leimann> current transfer time.
Sure, I guess I could pull that out with a perl script to parse the snapmirror status -v output and do the math. But that only gives the number over the lifetime of that transfer. And if the throttle will work on on-going transfers, it doesn't help me because I could have a multi-day transfer that gets throttled during work hours, then un-throttled at night, and throttled again the next time.
So the transfer rate will change and the number you propose I use won't help.
Thanks, John John Stoffel - Senior Staff Systems Administrator - System LSI Group Toshiba America Electronic Components, Inc. - http://www.toshiba.com/taec john.stoffel@taec.toshiba.com - 508-486-1087