toasters

toasters@lists.teaparty.net

13515 discussions

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

Culprit...
by Carl Howell 21 Oct '16

21 Oct '16

I've got an aggregate on a FAS2554c, running ONTAP 9, that runs at over 4500 read IOPS constantly. All of the volumes in the aggregate don't generate near that many IOPS and SnapMirror doesn't look like the cause either. I've used OCUM, statistics show...., etc, and haven't been able to find out what's causing this. Any suggestions? Thanks, --Carl

4 3

SnapMirror policy clarification
by Ehrenwald, Ian 17 Oct '16

17 Oct '16

Hello I'm trying to understand the differences between the snapshot policies included in cDOT 8.3, namely DPDefault and MirrorAllSnapshots. The documentation really isn't clear and apparently I can't see it myself. The behavior I'm seeing with a DP relationship using the DPDefault policy looks like it mirrors all snapshots and the active filesystem, which the MirrorAllSnapshots policy sounds like it should do. If I delete a snapshot on the source side and do an SM update, the snapshot is gone on the destination side too. I created a test to try and understand the differences between the policies, but maybe I'm looking at the wrong things because the results of the tests were identical: - Created testvolA on the source and SM_testvolA on the destination - Created testvolB on the source and SM_testvolB on the destination - Created SnapMirror relationship between testvolA and SM_testvolA with a SM policy of MirrorAllSnapshots - Created SnapMirror relationship between testvolB and SM_testvolB with a SM policy of DPDefault - Created a snapshot on each source volume - Initialized SnapMirror relationships - Examined output of snap list SM_testvol*, identical - Created another snapshot on each source volume - Updated SnapMirror relationships - Examined output of snap list SM_testvol*, identical - Deleted first snapshot on each source volume - Updated SnapMirror relationships - Examined output of snap list SM_testvol*, identical So, I'm having a difficult time understanding what the point of these policies are. Can someone enlighten me? Ian Ehrenwald Hachette Book Group, Inc. This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.

3 3

IOM3 and IOM6 on same loop
by John Adams 10 Oct '16

10 Oct '16

Hello, I currently have 3 DS4243's with IOM3 connected to my 8020 HA pair. I also have DS2246 with IOM6 as the last shelf on the loop. I want to add a another DS2246 with IOM6 to the loop. I know that IOM3 and IOM6 can exist on the same loop as long as there was only one IOM3 to IOM6 transition. Will there be any issue adding the 2nd shelf with IOM6 to this loop? i.e.: current: IOM3 -> IOM3 -> IOM3 -> IOM6 new: IOM3 -> IOM3 -> IOM3 -> IOM6 -> IOM6 Thanks.

5 5

RE: Frame discards on Brocade with 7-Mode FMC using 8G HBA and DS14
by andrei.borzenkov＠ts.fujitsu.com 04 Oct '16

04 Oct '16

Hi, Yes, UTA2 do not support direct connection of DS14 because they do not support FC-AL. They are supported in FMC though for connection to backend switches and that is what we have here. It is clear that setting HBA to 8G won’t make DS14 faster. Still customer has also ATTO 6500N and any future storage extension will go over ATTO as well so it is still beneficial to use full available speed. --- With best regards Andrei Borzenkov Senior system engineer FTS WEMEAI RUC RU SC TMS FOS [cid:image001.gif@01CBF835.B3FEDA90] FUJITSU Zemlyanoy Val Street, 9, 105 064 Moscow, Russian Federation Tel.: +7 495 730 62 20 ( reception) Mob.: +7 916 678 7208 Fax: +7 495 730 62 14 E-mail: Andrei.Borzenkov(a)ts.fujitsu.com<mailto:Andrei.Borzenkov@ts.fujitsu.com> Web: ru.fujitsu.com<http://ts.fujitsu.com/> Company details: ts.fujitsu.com/imprint<http://ts.fujitsu.com/imprint.html> This communication contains information that is confidential, proprietary in nature and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) or the person responsible for delivering it to the intended recipient(s), please note that any form of dissemination, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender and delete the original communication. Thank you for your cooperation. Please be advised that neither Fujitsu, its affiliates, its employees or agents accept liability for any errors, omissions or damages caused by delays of receipt or by any virus infection in this message or its attachments, or which may otherwise arise as a result of this e-mail transmission. From: gene [mailto:genec220@verizon.net] Sent: Monday, October 03, 2016 8:51 PM To: 'Tim McCarthy'; Borzenkov, Andrei Subject: RE: Frame discards on Brocade with 7-Mode FMC using 8G HBA and DS14 Just making sure you got this since my post bounced from toasters… <assuming you were talking about DS14 connections and not FC SAN targets> The DS14 shelves are supported on the UTA2 ports. You would need FC HBAs such as the X1132, or X2054. “The FAS80x0 onboard UTA2 ports and X1143A UTA2 ports are not supported for connectivity to DS14 shelves. To connect to DS14 shelves, use the X1132A-R6 or X2054A-R6 Fibre Channel adapters.” Also, unless your complete path is 8Gb, you won’t get the 8Gb. The 8Gb links would auto-negotiate down to 4Gb. Shouldn’t error though. You won’t get any better perf out of the DS14’s by setting the path links to 8Gb either since the fastest the DS14MK4 can run is 4Gb. {good seeing you, although a mere glance, at Insight, Tim. I continue to learn from your posts. Hope you are well.} Good luck, gene From: gene [mailto:genec220@verizon.net] Sent: Monday, October 03, 2016 11:34 AM To: 'Tim McCarthy'; NGC-andrei.borzenkov-ts.fujitsu.com; NGC-andrei.borzenkov-ts.fujitsu.com Cc: toasters(a)teaparty.net<mailto:toasters@teaparty.net> Subject: RE: Frame discards on Brocade with 7-Mode FMC using 8G HBA and DS14 Hi Andrei, I do not want to assume even though you say “backend switches” so are you trying to use the UTA2 ports to connect to the DS14’s or as FC SAN target ports? gene From: toasters-bounces(a)teaparty.net<mailto:toasters-bounces@teaparty.net> [mailto:toasters-bounces@teaparty.net] On Behalf Of Tim McCarthy Sent: Monday, October 03, 2016 7:47 AM To: NGC-andrei.borzenkov-ts.fujitsu.com; NGC-andrei.borzenkov-ts.fujitsu.com Cc: toasters(a)teaparty.net<mailto:toasters@teaparty.net> Subject: Re: Frame discards on Brocade with 7-Mode FMC using 8G HBA and DS14 You would not believe the silly stuff I have seen customers do. Get Outlook for iOS<https://aka.ms/o0ukef> On Mon, Oct 3, 2016 at 7:40 AM -0400, "andrei.borzenkov(a)ts.fujitsu.com<mailto:andrei.borzenkov@ts.fujitsu.com>" <andrei.borzenkov(a)ts.fujitsu.com<mailto:andrei.borzenkov@ts.fujitsu.com>> wrote: What FC ports are you using on the FAS8040 (onboard/PCIe Card)? [Borzenkov, Andrei] onboard how about the sysconfig -a for the FC ports involved (not the whole thing!)? [Borzenkov, Andrei] slot 0: FC Host Adapter 0e (QLogic 8324 rev. 2, N-port, <UP>) Firmware rev: 7.5.0 Host Port Id: 0x10100 FC Node Name: 5:00a:098003:8826d0 FC Port Name: 5:00a:098003:8826d0 SFP Vendor: AVAGO SFP Part Number: AFBR-57F5MZ-NA1 SFP Serial Number: AC1609J00D5 SFP Capabilities: 4, 8 or 16 Gbit Others are the same Do you have the correct SFP+s in the FAS8040? [Borzenkov, Andrei] Whatever NetApp ships with FAS8040. Where did they come from? [Borzenkov, Andrei] NetApp Did you take them from the FAS3140 (X6539 -> 4Gb)? [Borzenkov, Andrei] Of course, not. You seriously expect link to come up at 8G with 4G SFPs? (if so, those are likely 4Gb) The supported ones on the FAS8040 are X6596->16Gb [Borzenkov, Andrei] Yes, I know. Of course, if you are using a PCIe crad, that would be different too. --tmac Tim McCarthy, Principal Consultant Proud Member of the #NetAppATeam<https://twitter.com/NetAppATeam> I Blog at TMACsRack<https://tmacsrack.wordpress.com/> [NetApp - In partnership with Alpine Testing Solutions][NetApp Certified Data Administrator, ONTAP]<https://www.certmetrics.com/netapp/public/badge.aspx?t=c&d=2012-11-05&i=35&…>[NetApp Certified Implementation Engineer - SAN Specialist, ONTAP]<https://www.certmetrics.com/netapp/public/badge.aspx?t=c&d=2012-11-08&i=36&…>[NetApp Certified Storage Installation Engineer, ONTAP]<https://www.certmetrics.com/netapp/public/badge.aspx?t=c&d=2015-10-13&i=38&…>[NetApp Certified Implementation Engineer - Data Protection Specialist]<https://www.certmetrics.com/netapp/public/badge.aspx?t=c&d=2015-10-15&i=11&…>[https://dl.dropboxusercontent.com/u/6874230/FlexPod2.jpg][http://dl.dropbox…] NetApp Candidate ID: NETAPP00041276 FlexPod Design: Oct 2015 - Jan 2018, S0N62WE1BMVEYF3M FlexPod Implementation: Oct 2015 - Jan 2018, JH3QJT4KLEQ41HPH RHCE6 110-107-141<https://www.redhat.com/wapps/training/certification/verify.html?certNumber=…> On Mon, Oct 3, 2016 at 5:32 AM, andrei.borzenkov(a)ts.fujitsu.com<mailto:andrei.borzenkov@ts.fujitsu.com> <andrei.borzenkov(a)ts.fujitsu.com<mailto:andrei.borzenkov@ts.fujitsu.com>> wrote: This weekend I did head swap from FAS3140 to FAS8040 in 7-Mode FMC. Storage is DS14mk4 and one DS2246 that was added later. Backend switches are Brocade 300 so we tried to change HBA ports from 4G to 8G hoping to boost overall performance. But almost immediately I observed intermittent Sat Oct 1 23:00:08 YEKT [netapp2:cf.fsm.takeoverOfPartnerDisabled:error]: Failover monitor: takeover of netapp1 disabled (status of backup mailbox is uncertain). Sat Oct 1 23:00:14 YEKT [netapp2:cf.fsm.takeoverOfPartnerEnabled:notice]: Failover monitor: takeover of netapp1 enabled On both heads. There was no load, all applications were still stopped at this point. There were no other errors visible in logs. Looking on switches, the only errors reported for ports were c3 discards. They were most frequent on DS14 ports, but also happened for HBA and even ATTO ports (1 and 13 in this example). Statistic is collected several minutes after resetting counters. netapp2_fcsw1:admin> porterrshow frames enc crc crc too too bad enc disc link loss loss frjt fbsy c3timeout tx rx in err g_eof shrt long eof out c3 fail sync sig tx rx ======================================================================================================================= 0: 124.5k 90.9k 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1: 327.5k 290.8k 0 0 0 0 0 0 0 3 0 0 0 0 0 0 3 2: 278.4k 244.0k 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3: 27.0k 29.1k 0 0 0 0 0 0 0 102 0 0 0 0 0 0 102 4: 426.5k 474.3k 0 0 0 0 0 0 0 324 0 0 0 0 0 324 0 5: 41.9k 48.9k 0 0 0 0 0 0 0 120 0 0 0 0 0 0 120 6: 98.8k 109.8k 0 0 0 0 0 0 0 6 0 0 0 0 0 0 6 7: 111.4k 133.1k 0 0 0 0 0 0 0 2 0 0 0 0 0 0 2 8: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9: 56.2k 64.0k 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 10: 13.4k 14.9k 0 0 0 0 0 0 0 52 0 0 0 0 0 0 52 11: 46.4k 50.4k 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 12: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 13: 22.0k 23.8k 0 0 0 0 0 0 0 38 0 0 0 0 0 0 38 14: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 15: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 16: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 17: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 18: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 19: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 20: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 21: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 22: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 23: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 I could not find any best practice or recommendation regarding port speeds in such configuration (actually, documentation recommends setting port speed to maximum supported by connected device, which in this case means 8G). After forcing HBA back to 4G the above messages and c3 discards went away. So I'm looking for practical experience in this area. May be there are some settings we missed. Switches are running 7.0.2b (minimal version matching IMT). Shelf firmware is the latest. Data ONTAP is 8.2.4P4. --- With best regards Andrei Borzenkov Senior system engineer FTS WEMEAI RUC RU SC TMS FOS FUJITSU Zemlyanoy Val Street, 9, 105 064 Moscow, Russian Federation Tel.: +7 495 730 62 20 ( reception) Mob.: +7 916 678 7208 Fax: +7 495 730 62 14 E-mail: Andrei.Borzenkov(a)ts.fujitsu.com<mailto:Andrei.Borzenkov@ts.fujitsu.com> Web: ru.fujitsu.com<http://ru.fujitsu.com> Company details: ts.fujitsu.com/imprint<http://ts.fujitsu.com/imprint> This communication contains information that is confidential, proprietary in nature and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) or the person responsible for delivering it to the intended recipient(s), please note that any form of dissemination, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender and delete the original communication. Thank you for your cooperation. Please be advised that neither Fujitsu, its affiliates, its employees or agents accept liability for any errors, omissions or damages caused by delays of receipt or by any virus infection in this message or its attachments, or which may otherwise arise as a result of this e-mail transmission. _______________________________________________ Toasters mailing list Toasters(a)teaparty.net<mailto:Toasters@teaparty.net> http://www.teaparty.net/mailman/listinfo/toasters

1 0

Frame discards on Brocade with 7-Mode FMC using 8G HBA and DS14
by andrei.borzenkov＠ts.fujitsu.com 03 Oct '16

03 Oct '16

This weekend I did head swap from FAS3140 to FAS8040 in 7-Mode FMC. Storage is DS14mk4 and one DS2246 that was added later. Backend switches are Brocade 300 so we tried to change HBA ports from 4G to 8G hoping to boost overall performance. But almost immediately I observed intermittent Sat Oct 1 23:00:08 YEKT [netapp2:cf.fsm.takeoverOfPartnerDisabled:error]: Failover monitor: takeover of netapp1 disabled (status of backup mailbox is uncertain). Sat Oct 1 23:00:14 YEKT [netapp2:cf.fsm.takeoverOfPartnerEnabled:notice]: Failover monitor: takeover of netapp1 enabled On both heads. There was no load, all applications were still stopped at this point. There were no other errors visible in logs. Looking on switches, the only errors reported for ports were c3 discards. They were most frequent on DS14 ports, but also happened for HBA and even ATTO ports (1 and 13 in this example). Statistic is collected several minutes after resetting counters. netapp2_fcsw1:admin> porterrshow frames enc crc crc too too bad enc disc link loss loss frjt fbsy c3timeout tx rx in err g_eof shrt long eof out c3 fail sync sig tx rx ======================================================================================================================= 0: 124.5k 90.9k 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1: 327.5k 290.8k 0 0 0 0 0 0 0 3 0 0 0 0 0 0 3 2: 278.4k 244.0k 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3: 27.0k 29.1k 0 0 0 0 0 0 0 102 0 0 0 0 0 0 102 4: 426.5k 474.3k 0 0 0 0 0 0 0 324 0 0 0 0 0 324 0 5: 41.9k 48.9k 0 0 0 0 0 0 0 120 0 0 0 0 0 0 120 6: 98.8k 109.8k 0 0 0 0 0 0 0 6 0 0 0 0 0 0 6 7: 111.4k 133.1k 0 0 0 0 0 0 0 2 0 0 0 0 0 0 2 8: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9: 56.2k 64.0k 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 10: 13.4k 14.9k 0 0 0 0 0 0 0 52 0 0 0 0 0 0 52 11: 46.4k 50.4k 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 12: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 13: 22.0k 23.8k 0 0 0 0 0 0 0 38 0 0 0 0 0 0 38 14: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 15: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 16: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 17: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 18: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 19: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 20: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 21: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 22: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 23: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 I could not find any best practice or recommendation regarding port speeds in such configuration (actually, documentation recommends setting port speed to maximum supported by connected device, which in this case means 8G). After forcing HBA back to 4G the above messages and c3 discards went away. So I'm looking for practical experience in this area. May be there are some settings we missed. Switches are running 7.0.2b (minimal version matching IMT). Shelf firmware is the latest. Data ONTAP is 8.2.4P4. --- With best regards Andrei Borzenkov Senior system engineer FTS WEMEAI RUC RU SC TMS FOS FUJITSU Zemlyanoy Val Street, 9, 105 064 Moscow, Russian Federation Tel.: +7 495 730 62 20 ( reception) Mob.: +7 916 678 7208 Fax: +7 495 730 62 14 E-mail: Andrei.Borzenkov(a)ts.fujitsu.com Web: ru.fujitsu.com Company details: ts.fujitsu.com/imprint This communication contains information that is confidential, proprietary in nature and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) or the person responsible for delivering it to the intended recipient(s), please note that any form of dissemination, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender and delete the original communication. Thank you for your cooperation. Please be advised that neither Fujitsu, its affiliates, its employees or agents accept liability for any errors, omissions or damages caused by delays of receipt or by any virus infection in this message or its attachments, or which may otherwise arise as a result of this e-mail transmission.

4 5

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