toasters

toasters@lists.teaparty.net

1 participants
13532 discussions

Auto-export configuration.
by Jeff Cleverley 23 Apr '13

23 Apr '13

Greetings, I have some NearStores that I have upgraded to 8.1.2P3. I've found that since I've upgraded, when I create a new file system the auto-creation of the export string has changed. It is now incorrect and all the new exports are invalid. It isn't using what any of the others are using and it isn't tied into the vol0 export either. Where or how do I change what is uses for default export string when a new volume is created? Thanks, Jeff -- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611

3 3

Tivoli Storage Manager and netapp
by Andrew Curry 22 Apr '13

22 Apr '13

Hi Is anyone using Tivoli Storage Manager to backup a netapp. We've been struggling to get this working for some time now and would welcome advice from anyone who's got it working Andrew Andrew Curry Senior Technical Analyst - Servers & Storage Converged Infrastructure Information Technology & Media Services DE MONTFORT UNIVERSITY, LEICESTER, UK E: ajc(a)dmu.ac.uk<mailto:ajc@dmu.ac.uk> W: dmu.ac.uk

6 6

problem with moutning NFS share defines via NIS netgroup: permission dinied
by Iluhes 21 Apr '13

21 Apr '13

Dear Experts, Please help I am having problem with mount via NIS Is there anything wrong with this All IP and name are fake On server : bash-3.2# showmount -e 1.1.1.1 export list for 1.1.1.1 /vol/netapp1/vol1/X build /vol/netapp1/vol1/Y build Error on server mount 1.1.1.1:/vol/netapp1/vol1/X /testnetapp nfs mount: 1.1.1.1:/vol/netapp1/vol1/X: Permission denied On filer #ypmatch -k build netgroup build (1.1.1.2,-,-) (1.1.1.3,-,-) #ypcat -k netgroup build (1.1.1.2,-,-) (1.1.1.3,-,-) #exportfs /vol/netapp1/vol1/X -sec=sys,rw=@build /vol/netapp1/vol1/Y -sec=sys,rw=@build Errors of filer Fri Apr 12 10:14:41 CDT [netapp1: MNTPool00:info]: Client 1.1.1.2 (xid 1365436443), is sent the NULL reply Fri Apr 12 10:14:41 CDT [netapp1: MNTPool01:info]: Client 1.1.1.2 (xid 1365436444) in mount, does not have access rights to path /vol/netapp1/vol1/X

5 8

Reassigning vlan-interface to a vfiler
by Neis, Mark 19 Apr '13

19 Apr '13

Hi guys, I’m stuck with reassigning a different vlan-interface to an existing vfiler. What I did: - I created a new vlan interface vif1-123 - I downed the interface e0b-666, which was assigned to the vfiler’s ipspace and removed the ip by setting it to 0.0.0.0 - I reassigned vif1-123 to the vfiler’s ipspace - I reassigned the e0b-666 interface to the default ipspace - I brought vif1-123 up with the vfiler’s ip address using ifconfig - I stopped and started the vfiler Now the vfiler has the correct interface and ip address, but the default route still points to the old interface: | Routing tables | | Internet: | Destination Gateway Flags Refs Use Interface | default 172.17.113.66 UGS 0 1757931 e0b-666 | 172.17.113.64/26 link#23 UC 0 0 vif1-123 | foo.customer1 0:50:56:b9:1b:5c UHL 1 3 vif1-123 | bar.customer1 link#23 UHL 1 0 vif1-123 ifconfig on the host filer tells me, that the ip adress is correctly bound to vif1-123, nevertheless inside the vfiler this seems to have no effect regarding the default route. I'd rather not go through a vfiler setup, because this vfiler, although not productive yet, has already been configured for the customer and if possible I'd like to spare the overhead of redoing the configuration. What am I missing? Freundliche Grüße, Mark Neis -- Mark Neis Systemadministrator GISA GmbH Chemnitztalstr. 13 09114 Chemnitz Tel. +49.(0)371.482.996.7247 Vorsitzender des Aufsichtsrates: Ralf Hiltenkamp Geschäftsführung: Michael Krüger (Sprecher), Stephan Drescher Sitz der Gesellschaft: Halle/Saale Registergericht: Amtsgericht Stendal | Handelsregister-Nr. HRB 208414 UST-ID-Nr. DE 158253683 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Empfänger sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail oder des Inhalts dieser Mail sind nicht gestattet. Diese Kommunikation per E-Mail ist nicht gegen den Zugriff durch Dritte geschützt. Die GISA GmbH haftet ausdrücklich nicht für den Inhalt und die Vollständigkeit von E-Mails und den gegebenenfalls daraus entstehenden Schaden. Sollte trotz der bestehenden Viren-Schutzprogramme durch diese E-Mail ein Virus in Ihr System gelangen, so haftet die GISA GmbH - soweit gesetzlich zulässig - nicht für die hieraus entstehenden Schäden.

2 3

RE: Reassigning vlan-interface to a vfiler
by Neis, Mark 19 Apr '13

19 Apr '13

Hi Isidro, you wrote: > Vfiler run <vfiler name> route add .... Off course I did that (sorry for not mentioning it in my first mail). But 'route add default' seems to give me no options to name a specific interface which the vfiler should use: | route add [inet] default <gateway> <metric> Regards, Mark Vorsitzender des Aufsichtsrates: Ralf Hiltenkamp Geschäftsführung: Michael Krüger (Sprecher), Stephan Drescher Sitz der Gesellschaft: Halle/Saale Registergericht: Amtsgericht Stendal | Handelsregister-Nr. HRB 208414 UST-ID-Nr. DE 158253683 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Empfänger sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail oder des Inhalts dieser Mail sind nicht gestattet. Diese Kommunikation per E-Mail ist nicht gegen den Zugriff durch Dritte geschützt. Die GISA GmbH haftet ausdrücklich nicht für den Inhalt und die Vollständigkeit von E-Mails und den gegebenenfalls daraus entstehenden Schaden. Sollte trotz der bestehenden Viren-Schutzprogramme durch diese E-Mail ein Virus in Ihr System gelangen, so haftet die GISA GmbH - soweit gesetzlich zulässig - nicht für die hieraus entstehenden Schäden.

2 1

Mixing SAS speeds on 4-port SAS card
by Kevin Richards 17 Apr '13

17 Apr '13

Hi, Any issue with running two stacks off of the same 4-port SAS card, one at 3G the other at 6G? 3140 DOT 8.1SP2 DS4243 one stack DS2246 second stack Thank you. Kevin

1 0

SIS metadata issue
by Martin 16 Apr '13

16 Apr '13

We noticed several volumes used for VM datastores were showing decreasing sis savings. When we checked there was a significant amount of space being consumed by the sis metadata. Netapp told us this is due to bug 657692 which is likely to be fixed in 8.1.2P4. The bug mentions "Following certain sequence of operations, this metadata can become stale". The issue we have is the workaround is to run a "sis status -s" on each volume. When this is running it gradually removes the metadata which then causes the snapshots to increase rapidly. This means we can't automate the process as we need to kick it off and then increase the volume, snap reserve or remove snapshots. Has anyone else experienced this issue or found a way to avoid the metdata becoming stale? -- View this message in context: http://network-appliance-toasters.10978.n7.nabble.com/SIS-metadata-issue-tp… Sent from the Network Appliance - Toasters mailing list archive at Nabble.com.

3 2

head swap of Fabric Metro-Cluster?
by Jan-Pieter Cornet 16 Apr '13

16 Apr '13

Hi, Does anyone have experience doing a head swap of a FMC, from 6080 heads to 6290 heads? And hints beyond what's already in the "Upgrading a FAS60xx system in an HA pair to a FAS62xx system in an HA pair" document? Is there any reason why you can't do this, during a HA pair upgrade, to limit service downtime: - doing a failover of node 1 to node 2. - shut down and replace the hardware of node 1. - shutting down node 2. - bring up the now-replaced node 1, reassign disks, and takeover node 2 on the new node 1. - replacing the node 2 hardware - doing a giveback on node 1 to node 2. -- Jan-Pieter Cornet "Most seasonal greetings are sent by spammers and phishers."

4 6

Disk 6c.38 has exceeded the expected IO latency in the current window with average latency of 50 msecs and average utilization of 41 percent. Highest average IO latency
by Fletcher Cocquyt 15 Apr '13

15 Apr '13

Just migrated some volumes to a 3250 8.1.2 cluster and as expected when the snapmirrors were broken, the 64-bit upgrades began. How do I tell from the command line the progress and ETA of the 64-bit conversion status? I suspect they are causing IO issues - what is the diagnostic value of the per disk (high) latency reports with ~40% disk util? (are these bad disks??) thanks sysstat -x 1 CPU NFS CIFS HTTP Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk OTHER FCP iSCSI FCP kB/s iSCSI kB/s in out read write read write age hit time ty util in out in out 85% 7570 0 0 7573 271319 2395 9399 211896 0 0 12 97% 55% Ff 50% 3 0 0 0 0 0 0 93% 8871 0 0 8871 312456 2810 14858 219002 0 0 12 99% 100% :f 100% 0 0 0 0 0 0 0 63% 5527 0 0 5786 185636 1748 7456 276940 0 0 12 99% 100% Bn 88% 259 0 0 0 0 0 0 38% 2632 0 0 2632 103944 871 1112 244232 0 0 12 98% 100% :f 100% 0 0 0 0 0 0 0 21% 1105 0 0 1105 55646 415 4996 53596 0 0 12 96% 42% : 38% 0 0 0 0 0 0 0 9% 643 0 0 646 33061 253 16 32 0 0 12 94% 0% - 3% 3 0 0 0 0 0 0 10% 759 0 0 759 34509 275 28 0 0 0 12 96% 0% - 1% 0 0 0 0 0 0 0 12% 1041 0 0 1041 38390 397 20 0 0 0 12 97% 0% - 1% 0 0 0 0 0 0 0 Sun Apr 14 22:06:55 PDT [cci-na02:shm.threshold.ioLatency:debug]: Disk 6c.38 has exceeded the expected IO latency in the current window with average latency of 50 msecs and average utilization of 41 percent. Highest average IO latency: 6c.25: 52 msecs; next highest IO latency: 6c.38: 50 msecs Sun Apr 14 22:06:55 PDT [cci-na02:shm.threshold.ioLatency:debug]: Disk 6c.36 has exceeded the expected IO latency in the current window with average latency of 50 msecs and average utilization of 41 percent. Highest average IO latency: 6c.25: 52 msecs; next highest IO latency: 6c.38: 50 msecs Sun Apr 14 22:06:55 PDT [cci-na02:shm.threshold.ioLatency:debug]: Disk 6c.25 has exceeded the expected IO latency in the current window with average latency of 52 msecs and average utilization of 42 percent. Highest average IO latency: 6c.25: 52 msecs; next highest IO latency: 6c.38: 50 msecs 26% 658 0 0 670 30454 268 11576 202953 0 0 12 96% 46% Ff 37% 12 0 0 0 0 0 0 Sun Apr 14 22:06:55 PDT [cci-na02:shm.threshold.ioLatency:debug]: Disk 6c.17 has exceeded the expected IO latency in the current window with average latency of 50 msecs and average utilization of 41 percent. Highest average IO latency: 6c.25: 52 msecs; next highest IO latency: 6c.38: 50 msecs 22% 810 0 0 819 33288 326 12672 199088 0 0 12 96% 100% :f 100% 9 0 0 0 0 0 0 21% 973 0 0 977 50499 402 3268 102076 0 0 12 96% 59% : 57% 4 0 0 0 0 0 0 14% 1059 0 0 1059 56867 433 48 24 0 0 12 96% 0% - 3% 0 0 0 0 0 0 0

2 1

NVRAM weirdness
by Peta Thames 13 Apr '13

13 Apr '13

Hi all, Has anyone seen this pattern in a sysstat before? TOASTERa> sysstat -u 1 CPU Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk ops/s in out read write read write age hit time ty util 29% 36942 1 0 264 0 0 0 7s 91% 100% # 100% 29% 36896 1 0 1616 0 0 0 7s 90% 100% # 100% 28% 36658 1 0 32 24 0 0 7s 100% 100% # 100% 28% 36625 1 0 108 0 0 0 7s 97% 100% # 100% 27% 36318 1 0 136 8 0 0 7s 100% 100% # 100% 28% 36391 1 0 364 144 0 0 7s 97% 100% # 100% 25% 30387 1 0 88 0 0 0 7s 98% 100% # 100% 21% 24450 1 0 8 0 0 0 7s 100% 100% # 100% 20% 22042 1 0 24 672 0 0 7s 100% 100% # 100% 18% 19781 1 0 284 8 0 0 7s 69% 100% # 100% 18% 19636 1 0 0 0 0 0 7s 100% 100% # 100% 16% 18066 1 0 24 24 0 0 7s 100% 100% # 100% 15% 16999 1 0 56 0 0 0 7s 56% 100% # 100% 15% 16622 1 0 11040 6496 0 0 7s 46% 100% # 1824% 14% 15947 1 0 24 32 0 0 7s 100% 100% # 100% 14% 15448 0 0 0 0 0 0 7s 100% 100% # 100% 14% 15902 0 0 3304 4532 0 0 7s 88% 100% # 100% 14% 15800 0 0 32 24 0 0 7s 100% 100% # 100% 15% 16651 0 0 0 0 0 0 7s 100% 100% # 100% CPU Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk ops/s in out read write read write age hit time ty util 14% 15778 0 0 1520 2932 0 0 7s 100% 100% # 100% 13% 14311 0 1 28 24 0 0 7s 100% 100% # 100% 12% 12153 0 0 0 0 0 0 7s 100% 100% # 100% 12% 11993 0 0 8 0 0 0 7s 100% 100% # 100% 12% 12134 0 0 7368 5996 0 0 7s 18% 100% # 100% 13% 11981 0 0 20356 14956 0 0 7s 100% 100% # 100% 12% 11978 0 0 0 0 0 0 7s 100% 100% # 100% 11% 11617 0 0 24 24 0 0 7s 100% 100% # 100% 12% 11708 0 0 8 0 0 0 7s 100% 100% # 100% 11% 11630 0 0 11936 17872 0 0 7s 100% 100% # 100% 11% 11639 0 0 24 32 0 0 7s 100% 100% # 100% 12% 11791 0 0 12 0 0 0 7s 87% 100% # 100% 22% 11874 0 0 64452 92188 0 0 7s 100% 100% # 100% 12% 12015 0 0 32 24 0 0 7s 100% 100% # 100% 12% 11954 0 0 556 0 0 0 7s 85% 100% # 100% 12% 11899 0 0 0 8 0 0 7s 100% 100% # 100% 13% 13408 0 0 23816 35600 0 0 7s 91% 100% # 100% 13% 14610 0 0 0 0 0 0 7s 100% 100% # 100% 14% 15355 0 0 1248 0 0 0 7s 72% 100% # 100% 14% 15584 0 0 18652 15224 0 0 7s 98% 100% # 100% CPU Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk ops/s in out read write read write age hit time ty util 14% 15397 0 0 0 8 0 0 7s 100% 100% # 100% 15% 15859 0 1 0 0 0 0 7s 100% 100% # 100% 14% 15557 0 0 4944 4568 0 0 7s 100% 100% # 100% 14% 15559 0 0 8 0 0 0 7s 100% 100% # 100% 14% 15603 0 0 0 0 0 0 7s 100% 100% # 100% 14% 15507 0 0 3652 4724 0 0 7s 100% 100% # 100% 14% 15593 0 0 20 0 0 0 7s 75% 100% # 100% 12% 12571 0 0 268 0 0 0 7s 100% 100% # 100% 10% 9962 0 0 92 2072 0 0 7s 96% 100% # 100% 9% 8521 0 0 0 0 0 0 7s 100% 100% # 100% 8% 7680 0 0 4 8 0 0 7s 100% 100% # 100% 8% 7459 0 0 24 24 0 0 7s 100% 100% # 100% 8% 7050 0 0 2580 1600 0 0 7s 100% 100% # 100% 8% 6961 0 0 8 0 0 0 7s 100% 100% # 100% 8% 6954 0 0 24 24 0 0 7s 100% 100% # 100% 7% 6936 0 0 584 2400 0 0 7s 100% 100% # 100% 8% 7043 0 0 248 0 0 0 7s 0% 100% # 100% 7% 6946 0 0 24 24 0 0 7s 100% 100% # 100% 8% 7320 0 0 1860 7252 0 0 7s 100% 100% # 100% 55% 19882 2 2 89920 29733 0 0 1 86% 99% B 45% CPU Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk ops/s in out read write read write age hit time ty util 88% 17409 31 187 267319 196942 0 0 6s 83% 100% : 89% 87% 16064 11 249 304646 192912 0 0 1 78% 100% : 85% 85% 6274 70 86 322234 233245 0 0 1 81% 100% # 87% 85% 12486 18 340 236474 102383 0 0 3s 82% 100% B 73% 98% 13842 3 29 247937 255188 0 0 2s 85% 100% : 80% 99% 17878 1 1 348355 223367 0 0 3s 84% 100% # 86% 99% 4117 1 1 359628 269212 0 0 3s 78% 100% # 92% 83% 12622 10 31 252272 170064 0 0 2s 83% 100% B 73% 94% 19321 4 10 248864 249292 0 0 2s 88% 100% : 96% 99% 15893 0 0 318375 261482 0 0 2s 85% 100% : 89% 88% 13326 34 76 284960 194032 0 0 2s 82% 100% B 90% 86% 11106 73 104 267760 231524 0 0 2s 81% 100% : 100% 72% 11160 0 0 206927 128869 0 0 3s 75% 100% : 100% 63% 11304 0 0 220736 25276 0 0 3s 67% 100% : 100% 68% 11216 0 0 193324 15184 0 0 3s 66% 100% : 100% 65% 11343 0 0 175120 12588 0 0 3s 60% 100% : 100% 52% 7384 0 0 205780 104564 0 0 3s 61% 100% # 100% 83% 7205 0 0 261108 178256 0 0 3s 74% 100% B 90% 75% 11256 0 0 225164 96332 0 0 3s 76% 100% : 93% 99% 6279 0 0 296056 251191 0 0 2s 87% 100% : 90% CPU Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk ops/s in out read write read write age hit time ty util 65% 8616 0 0 220068 165749 0 0 2s 76% 73% : 71% 89% 5443 0 1 338684 239932 0 0 3s 80% 94% F 87% 95% 6726 0 0 379242 240750 0 0 3s 79% 100% : 91% 83% 8721 1 0 342940 113394 0 0 2s 82% 61% : 89% 77% 11971 1 0 314356 24 0 0 2s 85% 0% - 92% ... and back to normal. Looking in Perf Advisor, it was during an extremely short, sharp latency spike that impacted every volume on every aggregate at exact the same time. It was the fourth of four spikes that had happened a few minutes apart during the previous 20 mins. It looks like the NVRAM flush got stuck somehow but I have no idea what would cause that. We're running ONTAP 8.0.2 7-mode on a very busy FAS3170. Thanks, Peta

10 20

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters