toasters

toasters@lists.teaparty.net

1 participants
13515 discussions

stats list instances disk output format
by Jordan Slingerland 07 Apr '14

07 Apr '14

Why does "stats list instances disk" show the disk instance name as what looks like hex but so far I have not been able to translate to anything meaningful. Example: 5000CCA0:0F91CAAC:00000000:00000000:00000000:00000000:00000000:00000000:00000000:00000000 Can anyone tell me how an easy way to map this to the disk name format I have grown to know and love. --Jordan For the seventh consecutive year, Independent Health was named one of the best companies to work for in New York State. Go to www.independenthealth.com to view careers and available positions. We are an Equal Opportunity Employer. CONFIDENTIALITY NOTICE: This e-mail and its attachments (collectively referred to as "e-mail") may contain confidential information that is privileged and protected from disclosure by Federal and State confidentiality laws, rules or regulations. This e-mail is intended for the designated addressee only. If you are not the designated addressee, you are notified that any disclosure, copying or distribution of this e-mail may be unlawful and may subject you to legal consequences. If you have received this e-mail in error, please contact me immediately by telephone at (716) 631 - 3001 and delete the e-mail from your computer immediately. Thank you for your attention.

6 9

LACP oddness
by Peter D. Gray 04 Apr '14

04 Apr '14

We have 2 3270 filers, each using a LACP portchannel over 2 1G interfaces to a CISCO 6500. When we enable LACP debugging, we get this. Apr 1 14:08:04 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4b) Mux state change: (MUX_COLLECT_DISTRIBUTE) to (MUX_COLLECTING) Apr 1 14:08:04 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4b) Mux state change: (MUX_COLLECTING) to (MUX_ATTACHED) Apr 1 14:08:04 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4b) Mux state change: (MUX_ATTACHED) to (MUX_DETACHED) Apr 1 14:08:04 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4b) Mux state change: (MUX_DETACHED) to (MUX_WAITING) Apr 1 14:09:04 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4b) Mux state change: (MUX_WAITING) to (MUX_ATTACHED) Apr 1 14:09:04 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4b) Mux state change: (MUX_ATTACHED) to (MUX_COLLECTING) Apr 1 14:09:04 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4b) Mux state change: (MUX_COLLECTING) to (MUX_COLLECT_DISTRIBUTE) Apr 1 14:16:25 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4a) Mux state change: (MUX_COLLECT_DISTRIBUTE) to (MUX_COLLECTING) Apr 1 14:16:25 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4a) Mux state change: (MUX_COLLECTING) to (MUX_ATTACHED) Apr 1 14:16:25 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4a) Mux state change: (MUX_ATTACHED) to (MUX_DETACHED) Apr 1 14:16:25 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4a) Mux state change: (MUX_DETACHED) to (MUX_WAITING) Apr 1 14:16:25 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4a) Mux state change: (MUX_WAITING) to (MUX_ATTACHED) Apr 1 14:16:25 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4a) Mux state change: (MUX_ATTACHED) to (MUX_COLLECTING) Apr 1 14:16:25 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4a) Mux state change: (MUX_COLLECTING) to (MUX_COLLECT_DISTRIBUTE) Apr 1 14:18:26 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4a) Mux state change: (MUX_COLLECT_DISTRIBUTE) to (MUX_COLLECTING) Apr 1 14:18:26 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4a) Mux state change: (MUX_COLLECTING) to (MUX_ATTACHED) Apr 1 14:18:26 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4a) Mux state change: (MUX_ATTACHED) to (MUX_DETACHED) Apr 1 14:18:26 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4a) Mux state change: (MUX_DETACHED) to (MUX_WAITING) Apr 1 14:18:26 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4a) Mux state change: (MUX_WAITING) to (MUX_ATTACHED) Apr 1 14:18:26 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4a) Mux state change: (MUX_ATTACHED) to (MUX_COLLECTING) Apr 1 14:18:26 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4a) Mux state change: (MUX_COLLECTING) to (MUX_COLLECT_DISTRIBUTE) Apr 1 14:08:04 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4b) Mux state change: (MUX_COLLECT_DISTRIBUTE) to (MUX_COLLECTING) Apr 1 14:08:04 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4b) Mux state change: (MUX_COLLECTING) to (MUX_ATTACHED) Apr 1 14:08:04 kudan.its.uow.edu.au netapp: [ID 702911 daemon.info] (e4b) Mux state change: (MUX_ATTACHED) to (MUX_DETACHED) The settings on the switch and the netapp seem to agree. If our understanding of this is correct, there is a LACP packet every 30 seconds (active setting). If 3 are missed in a row, the netapp downs that leg of the portchannel. Later, a packet arrives and the netapp ups the leg of the portchannel. Does anybody with a deep understanding of this know why we get these messages and why it appears the netapp is uping and downing the interface and if this is serious. Any help appreciated. Regards, pdg Peter Gray Ph (direct): +61 2 4221 3770 Information Technology Services Ph (switch): +61 2 4221 3555 University of Wollongong Fax: +61 2 4229 1958 Wollongong NSW 2522 Email: pdg(a)uow.edu.au Australia URL: http://pdg.uow.edu.au

2 1

FAS3240c SAS Cabling Question
by Carl Howell 04 Apr '14

04 Apr '14

I have a FAS3240c that has been running for years. I noticed today, while putting in some new shelves, that the IOM modules in the last shelf of a stack of DS4243's are both cabled to the wrong nodes. Filer1 SAS port 3a goes to the circle port on IOM B instead of IOM A and visa versa. Do I have to take the entire cluster down to fix this? Thanks, --Carl

2 1

simulator 8.2 doesn't appear to be running NFS?
by Rue, Randy 28 Mar '14

28 Mar '14

Hello Again All, Trying to set up an 8.2 simulator to test the nfs.authsys.extended_groups_ns.enable option (more on that in yesterday's thread). Got it running in VMware player, can reach it from the real network, can manage it in OnCommand. Added the volume, qtree, export, etc >From the CLI "exportfs" shows the export as available with access to the specified netgroup. From the GUI the export is visible and the netgroup enumerates to its members. Added the simulator license for the correct serial number and the NFS stack is licensed (although its "State" is "-NA-" on the license page). But if I try to "showmount -e" the filer from any client (CentOS or Solaris) I get "mount clntudp_create: RPC: Program not registered" as if NFS wasn't actually running. If I run "rpcinfo -p" against the filer I get a long list of ports but nothing related to mountd. "options nfs" from the CLI shows v2 and v3 enabled. What did I miss? Thanks in advance... Randy in Seattle

2 3

NFS fails?
by Mark Flint 28 Mar '14

28 Mar '14

Hi all, I have an issue with a FAS3170 and NFS. Seems that hosts are being disconnected and the only thing I can find is a strange message that would seem to point at TOE? :- Tue Mar 4 21:13:49 GMT [netapp5a: nfsd.tcp.close.idle.notify:warning]: Shutting down idle connection to client (172.17.82.34) where transmit side flow control has been enabled. There are 22 outstanding replies queued on the transmit buffer However, TOE is turned off. If someone could point me in the right direction, it would be much appreciated :) ~Mark -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.

4 8

DOT 8.1 disk in a DOT 7.3 filer
by R M 27 Mar '14

27 Mar '14

Gents, My Google-fu is exhausted. I am trying to use disks from an 8.1.3 system in a 7.3.7 filer. I am aware of the disk label problem and I have tried the half-dozen step process (documented in several places) for re-labeling the drives. I'm not able to wipe the label from the drives due to the following: *> label wipe 0a.17Error: label wipe not permitted as the disk has a bad RAID version. *>label makespare 0a.17*********************************************************Label editing is highly dangerous and should be attemptedONLY by NetApp Customer Support Engineers.Misuse can cause ALL data to be permanently lost.*********************************************************'Label save': Error while trying to save Label 1 on disk 0a.17: error 15. I get this in both diag mode and when booted into maintenance mode. Any ideas? RM

4 5

High CPU usage after upgrade to 8.1.4
by Marcus Nilsson 27 Mar '14

27 Mar '14

Hi, I have a FAS3160 7-mode system where CPU usage has increased by around 5x over all cores since after upgrade from 8.0.3P3 to 8.1.4P1. NetApp support is claiming the increase is due to different multicore behavior, but I find that a little hard to believe since the increase it happening on all cores and on both nodes in the HA pair. We have since the upgrade noticed longer running dedupe jobs and more sluggish ssh prompt. Has anyone else seen this? > sysstat -m ANY AVG CPU0 CPU1 CPU2 CPU3 100% 55% 54% 52% 58% 56% 100% 56% 55% 54% 59% 57% 100% 57% 55% 54% 59% 59% 100% 58% 56% 56% 59% 60% 100% 62% 61% 60% 64% 65% 100% 56% 54% 54% 59% 58% 100% 62% 61% 60% 65% 64% 100% 67% 65% 65% 69% 68% 100% 62% 60% 60% 64% 65% 100% 69% 67% 68% 72% 71% 100% 68% 65% 66% 70% 70% 100% 56% 54% 54% 58% 60% 100% 50% 49% 47% 52% 54% 100% 59% 55% 56% 60% 63% BR Marcus

1 0

CDOT 8.2p5, NFS w/ Win2012 or Win 7?
by Michael Garrison 26 Mar '14

26 Mar '14

We recently migrated a bunch of NFS volumes from 7mode to a cdot system. The CDot cluster has only NFSv3 enabled. We have some Windows 7 and Windows 2012 machines that can no longer mount the NFS volumes. No matter how they try it, they receive the following error: C:\Windows\system32>mount -o nolock \\server\share Z: > Network Error - 53 > Type 'NET HELPMSG 53' for more information. Yet, the exact same mount parameters work fine on the 7mode share. They've rebooted, tried multiple computers, and it's consistent behavior. Is anyone else out there running CDot 8.2p5 and have any success with Win7 or Win2012 machines? Thanks, Mike Garrison University of Michigan

4 6

auth_sys group limit override ?
by Mark Flint 26 Mar '14

26 Mar '14

Does anyone know how this translates into C-Mode world from 7-mode? Thanks, `Mark -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.

3 2

Re: NFS Datastore Disconnect
by Philbert Rupkins 18 Mar '14

18 Mar '14

Thanks for the response! Yes. We are running 10g. I know flow control is enabled on the 10g adapters on the NetApps. Not sure if it is enabled on the switches. I'll have to check with our networking team. Do you know if a pause frame would show up somewhere in the port statistics? The switches are Nexus 5K's. We have been examining TCP Window Sizes during packet traces but have not found anything interesting. Of course, whenever we run a packet capture the problem never occurs so TCP Window Sizes could still be an issue. On Tue, Mar 18, 2014 at 12:04 AM, Wilkinson, Brent < Brent.Wilkinson(a)netapp.com> wrote: > Are you running 10g? If so what are the flow control settings end to end? > > Sent from mobile device. > > On Mar 17, 2014, at 10:55 PM, "Philbert Rupkins" < > philbertrupkins(a)gmail.com> wrote: > > I'll also mention that I received a response from a gentleman at NetApp > who pointed out the following KB article the recommends reducing the NFS > Queue depth. > > > http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=di… > > We noticed this KB article but have yet to try it. We are considering > other options at the moment because the article says this issue is fixed in > the version of ONTAP (8.1.2P4) we are running. However, if nothing else > pans out, we will give it a shot. > > Another note - this is also a highly shared environment in which we > service FCP, CIFS and NFS clients from the same filers (and vfilers) we > service the NFS datastores from. We have yet to show evidence of high > utilization from the other clients on the same array contributing to the > problem but it is on the radar. > > Also worth noting, we are running VSC 4.2.1. It reports all of the ESX > hosts to be in compliance with the recommended settings. > > > > > On Mon, Mar 17, 2014 at 8:30 PM, Philbert Rupkins < > philbertrupkins(a)gmail.com> wrote: > >> Hello Toasters, >> >> Anybody have any issues with seemingly random ESXi 5.5 NFS datastore >> disconnects during heavy load? >> >> Our Environment: >> >> ESXi 5.5 >> F3240 ONTAP 8.1.2P4 >> >> It doesn't happen all the time. Only during heavy load but even then >> there is no guarantee that it will happen. We have yet to find a >> consistent trigger. >> >> Datastores are mounted via shortname. We are planning to mount via IP >> address to rule out any name resolution issues but that will take some >> time. DNS is generally solid so we are doubtful DNS has anything to do >> with it but we should align ourselves with best practices. >> >> We serve all of our NFS through vfilers. Some of our vfilers host 5 >> NFS datastores from a single IP address. I mention this because I have >> come across documentation recommending a 1:1 ratio of datastores to IP >> addresses. >> >> vmkernel.log just shows that the connection was lost to the NFS server. >> It recovers w/in 10 seconds. We have 11 nodes in this particular ESX >> cluster. >> >> Not all 11 ESXi nodes lose connectivity to the datastore at the same >> time. I've seen it affect just one ESXi node's connectivity to a single >> datastore. I've also seen it affect more than one ESXi node and multiple >> datastores on the same filer. >> >> Until recently, it was only observed during storage vmotions. We >> recently discovered it happening during vmotion activity managed by DRS >> after a node was brought out of maintenance mode. As I said before, it is >> generally a rare occurrence so it is difficult to trigger on our own. >> >> Thanks in advance for any insight/experiences. >> >> Phil >> >> >> > _______________________________________________ > Toasters mailing list > Toasters(a)teaparty.net > http://www.teaparty.net/mailman/listinfo/toasters > >

5 8

Jump to page:

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