toasters October 2016

toasters@lists.teaparty.net

14 participants
8 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

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

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 October 2016