toasters

toasters@lists.teaparty.net

2 participants
13520 discussions

FDMI reporting with qla2xxx driver on Linux
by Momonth 09 Dec '16

09 Dec '16

Hi, I recently noticed that qla2xxx (Qlogic HBAs) driver on Linux is capable of reporting FDMI. By default it sends "Linux-default", and I'm failing to see how to change it to actual host name as it becomes way more handy then =) Any ideas? Cheers, Vladimir

2 3

SP Image Downloads?
by Alexander Griesser 05 Dec '16

05 Dec '16

Hi there, I'm looking for SP firmware 3.1.2P1 for an AFF8040, but am only able to download 3.2.1 on the support site which is not compatible to my currently running version of OnTap. Does anyone have a deep link for this image or knows of a way to find download links for specific versions like the method used for downloading patch releases etc. for all other software shipments from NetApp? Thanks, Alexander Griesser Head of Systems Operations ANEXIA Internetdienstleistungs GmbH E-Mail: AGriesser(a)anexia-it.com<mailto:AGriesser@anexia-it.com> Web: http://www.anexia-it.com<http://www.anexia-it.com/> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

4 12

ONTAP9 NFSv4 + CentOS 6.8 does not work
by Momonth 29 Nov '16

29 Nov '16

Hi All, We upgraded our 6 nodes cluster to ONTAP9 yesterday. Today I discovered some freshly installed CentOS 6.8 hosts not being able to mount file shares via NFS v4 protocol. The mount command just kind of hangs. I verified it's not a connectivity issue, ie connections to the filer's port 2049 are possible. Also NFS v3 works just fine. Did anyone experience anything like that? Cheers, Vladimir

7 11

CDOT snapmirror -forground
by Rhodes, Richard L. 28 Nov '16

28 Nov '16

Hello I am starting to look into a possible rollover of our 7-mode IBM N-Series systems to new NetApp CDOT systems. I run backups with snapmirror and snapvault that are controlled by a AIX ksh script. The ksh script runs the following cmds to perform the data transfers: snapmirror update -S ${filerpri}:${vol} -w ${filerdr}:${vol} snapvault snap create -w $vol $vol Note the '-w' parm. I run these cmds in forground, so all backups are single threaded and return a response back to the script. I'm looking at CDOT cmds manual for an equivalent '-w' parm. I find the following for the "snapmirror update" cmd: [-foreground | -w [true]] - Foreground Process This specifies whether the operation runs as a foreground process. If this parameter is specified, the default setting is true (the operation runs in the foreground). When set to true, the command will not return until the process completes. This parameter is only applicable to relationships with "Relationship Capability" of "Pre 8.2". Q) What does "applicable to relationships with "Relationship Capability" of "Pre 8.2" mean? Does this mean that a CDOT>8.2 system doesn't support this parm? Thanks! Rick ----------------------------------------- The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.

2 1

Flash Cache older 3020c??
by Chris hansen 26 Nov '16

26 Nov '16

I saw a few threads talking about flash cache and it made me think of my old 3020c that continues to chug along in my lab running 7.3.7. (568 days) Do any of these PAM II flash modules (111-00525+D0 for example) work in this FAS model or was there no flash option? I did some googling but there wasn’t much data on some of these older modules. -Chris

2 1

NFS V4 and nobody
by John Adams 16 Nov '16

16 Nov '16

I am mounting an export via NFS V4. At first, I saw that mounted clients showed user/group as nobody:nobody. But then I configured the nfs.v4.id.domain option on the filer to be the client machines DNS domain name. Then the username:groups were correct.. mostly... We use NIS on the client machines and the filer. For files that are owned by users or groups that are not in our NIS, the clients now shows nobody. Under NFS V3... this shows the UID/GID numbers (if they are not in NIS, and have no mappings). Anybody know how to make NFS V4 just show the UID/GID of entries that have no mapping instead of converting them to nobody? (UID's are no longer in our NIS after the account is deleted...) RHEL6/7. OnTap 8.2.4-7 Mode. Thanks.

3 3

Problems with SMB and macOS Sierra?
by James Andrewartha 09 Nov '16

09 Nov '16

Hi, We're testing macOS Sierra at the moment, and are seeing some weird problems connecting to SMB shares on our 8.2.4 7-mode filer. Listing directories is super-slow, and then after a while all the files get the no permissions icon and you can't open anything. Has anyone seen anything similar? Thanks, -- James Andrewartha Network & Projects Engineer Christ Church Grammar School Claremont, Western Australia Ph. (08) 9442 1757 Mob. 0424 160 877

4 7

Troubleshooting 'unreachable' on a CDOT port
by Edward Rolison 08 Nov '16

08 Nov '16

Hello fellow NetApp admins. Over the weekend, I hit a really quite "interesting" sort of a problem. One of those weekends that ... no one really wants to have. It involved a firmware upgrade on a switch going catastrophically wrong. causing chaos for several hours. And off the back of that - one of our two CDOT nodes, it's primary 'data' interface LACP group has .. seemingly died. I say "seemingly" because: - Snooping the interfaces sees packets going in and out. (Mostly "arp"). - But the switch side "snoop" doesn't see the ARP replies. And thus never 'learns' the mac, and doesn't route traffic to it. This happens on both ports of a LACP group, and even moving it to another switch entirely hasn't helped. Manually offlining the ports doesn't help (Except if I do both, it migrates the lif automatically). But switching the lifs over onto the other head - has fixed it, for now. (although obviously, we're failed over, and have reduced resilience). Has anyone run into anything similar? Or can give me some insight as to what could explain this perplexing behaviour? The 'source' of the problem was - probably - some serious network strangeness. Loops, vlans going up and down, all sorts of chaos. I haven't (yet) rebooted the failed node, as the vservers are running quite merrily. I'm wondering if there's some sort of DOS/arp flood protection that might be tripping us up. Thanks, Ed.

4 4

Re: sas.adapter.debug messages
by Mike Thompson 25 Oct '16

25 Oct '16

yeah it's supported per hardware universe gear isn't on support because money i could upgrade it, i'm just not going to, without support - had too many upgrades go sideways in the past, requiring intervention from support On Tue, Oct 25, 2016 at 10:55 AM, gene <genec220(a)verizon.net> wrote: > Then it is very possible that the gear isn’t supported by your older ONTAP > version. It might not even know about your gear and/or versions. Why > isn’t the gear on support? If you have a valid support account, can’t > you download a more current ONTAP version and use it regardless of the > non-support on the controllers? > > > > g > > > > *From:* toasters-bounces(a)teaparty.net [mailto:toasters-bounces@ > teaparty.net] *On Behalf Of *Mike Thompson > *Sent:* Tuesday, October 25, 2016 1:51 PM > *To:* NGC-tmacmd-gmail.com > *Cc:* toasters(a)teaparty.net Lists > *Subject:* Re: sas.adapter.debug messages > > > > gear isn't on support, so i'm not updating Ontap. > > all the SAS shelves brand new though, so should have latest firmware, but > i'll double check. > > >

2 1

sas.adapter.debug messages
by Mike Thompson 25 Oct '16

25 Oct '16

Hey all, Recently hooked up a ton of DS2246 w 900g drives to some 6080s and 6280s running (ancient) cDOT 8.0.5, and am seeing a lot of sas.adapter.debug messages when the aggregates in question are under heavy write load. Seeing this on multiple filers, multiple adapters, so I'm guessing it's a bug of some sort, which was likely fixed years ago? These don't appear to be impacting performance as far as I can tell, but I'm not certain (gear was just onlined, and using this as staging area for shuffling lots of volumes around). Are these particularly evil? Can't find much online about them, but they don't look very appealing: Oct 24 18:17:47 filer1a pmcsas_intrd_1: sas.adapter.debug: adapterName="5a", debug_string="OPEN timeout (0x13): dev 5b.13.13 (5:000039:7385204:66), cdb 0x2a:236f16d8:0200 (0/29311), NDU 0x0" Oct 24 18:17:51 filer1a pmcsas_intrd_1: sas.adapter.debug: adapterName="5a", debug_string="Bad device state completion: status 0x39, dev 5b.13.13, cdb 0x2a:236f16d8:0200" Oct 24 18:17:51 filer1a pmcsas_intrd_1: sas.adapter.debug: adapterName="5a", debug_string="Bad device state completion: status 0x39, dev 5b.13.13, cdb 0x2a:236f18d8:0200" Oct 24 18:17:51 filer1a pmcsas_intrd_1: sas.adapter.debug: adapterName="5a", debug_string="Bad device state completion: status 0x39, dev 5b.13.13, cdb 0x28:236f3620:0010" Oct 24 18:17:51 filer1a pmcsas_intrd_1: sas.adapter.debug: adapterName="5a", debug_string="Bad device state completion: status 0x39, dev 5b.13.13, cdb 0x28:1555e6f8:0080" Oct 24 18:17:51 filer1a pmcsas_intrd_1: sas.adapter.debug: adapterName="5a", debug_string="Bad device state completion: status 0x39, dev 5b.13.13, cdb 0x2a:236f1ad8:0200" Oct 24 18:17:51 filer1a pmcsas_intrd_1: sas.adapter.debug: adapterName="5a", debug_string="Bad device state completion: status 0x39, dev 5b.13.13, cdb 0x2f:041a4800:0400" Oct 24 19:21:46 filer1a pmcsas_intrd_2: sas.adapter.debug: adapterName="1a", debug_string="OPEN timeout (0x13): dev 1a.15.22 (5:000039:73850ad:19), cdb 0x2a:2368ed60:0200 (0/18656), NDU 0x0" Oct 24 19:21:49 filer1a pmcsas_intrd_2: sas.adapter.debug: adapterName="1a", debug_string="Bad device state completion: status 0x39, dev 1a.15.22, cdb 0x2a:2368ed60:0200" Oct 24 19:21:49 filer1a pmcsas_intrd_2: sas.adapter.debug: adapterName="1a", debug_string="Bad device state completion: status 0x39, dev 1a.15.22, cdb 0x2f:04dd0800:0400" Oct 24 19:24:01 filer1a pmcsas_intrd_2: sas.adapter.debug: adapterName="1a", debug_string="OPEN timeout (0x13): dev 1a.15.0 (5:000039:7481142:e5), cdb 0x2a:2382c048:0200 (0/33634), NDU 0x0" Oct 24 19:24:01 filer1a pmcsas_intrd_2: sas.adapter.debug: adapterName="1a", debug_string="Bad device state completion: status 0x39, dev 1a.15.0, cdb 0x2a:2382bc48:0200" Oct 24 19:24:01 filer1a pmcsas_intrd_2: sas.adapter.debug: adapterName="1a", debug_string="Bad device state completion: status 0x39, dev 1a.15.0, cdb 0x2a:2382c248:0200" Oct 24 19:30:02 filer1a pmcsas_intrd_2: sas.adapter.debug: adapterName="1a", debug_string="OPEN timeout (0x13): dev 1a.16.19 (5:000039:7480858:65), cdb 0x2a:23ca4d38:0200 (0/74568), NDU 0x0" Oct 24 19:30:02 filer1a pmcsas_intrd_2: sas.adapter.debug: adapterName="1a", debug_string="Bad device state completion: status 0x39, dev 1a.16.19, cdb 0x2a:23ca4f38:0200" Oct 24 19:31:21 filer1a pmcsas_intrd_2: sas.adapter.debug: adapterName="1a", debug_string="OPEN timeout (0x13): dev 1a.15.0 (5:000039:7481142:e5), cdb 0x2a:23f9dd80:0200 (0/439), NDU 0x0" Oct 24 19:31:21 filer1a pmcsas_intrd_2: sas.adapter.debug: adapterName="1a", debug_string="Bad device state completion: status 0x39, dev 1a.15.0, cdb 0x2a:23f9df80:0200" Oct 24 19:31:34 filer1a pmcsas_intrd_2: sas.adapter.debug: adapterName="1a", debug_string="OPEN timeout (0x13): dev 1a.15.2 (5:000039:7480859:bd), cdb 0x28:0871dd38:0008 (0/74660), NDU 0x0" Oct 24 19:31:34 filer1a pmcsas_intrd_2: sas.adapter.debug: adapterName="1a", debug_string="Bad device state completion: status 0x39, dev 1a.15.2, cdb 0x2a:23fca318:00e8" Oct 24 19:33:40 filer1a pmcsas_intrd_2: sas.adapter.debug: adapterName="1a", debug_string="OPEN timeout (0x13): dev 1a.16.6 (5:000039:7481143:01), cdb 0x2a:24176530:0198 (0/74786), NDU 0x0" Oct 24 19:33:40 filer1a pmcsas_intrd_2: sas.adapter.debug: adapterName="1a", debug_string="Bad device state completion: status 0x39, dev 1a.16.6, cdb 0x2a:241766c8:0200"

2 2

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