toasters

toasters@lists.teaparty.net

1 participants
13528 discussions

CIFS NOT WORKING
by Camillo Gornati 11 Feb '15

11 Feb '15

Hi all! Yesterday everything was working fine, today in the morning, we can ping the share, but cannot open it on windows. Any ideas?

4 3

Motherboard replacement on FAS3270 caused fabric wide issue
by Momonth 11 Feb '15

11 Feb '15

Hi All, I hit the following bug on one of the filer (FAS3260) I manage: http://mysupport.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=659544 This filer (filer-prod-204) works in HA mode with filer-prod-203. They are connected to two redundant FC SAN fabrics (one connection from each filer per fabric). There are more HA pairs connected to the same fabrics, eg filer-prod-201 / filer-prod-202. All of the filers we have are running in 'single-image' mode. We run FC SAN fabrics in "hard zoning mode". NetApp support conclusion was to replace motherboard on the filer and we proceeded with that. Here is an issue we had and I have no explanation to that, I hope you guys can help me with that: Once the filer-prod-204 got the motherboard replaced, powered on and entered HW diagnostics mode I've seen the messages as below *on every other filer* (eg. filer-prod-201), connected to the same fabric, causing issues on hosts (CentOS 6.4 mainly) attached to them: Fri Jan 30 20:07:45 CET [filer-prod-201: scsitarget.ispfct.targetReset:notice]: FCP Target 0c: Target was Reset by the Initiator at Port Id: 0x11000 (WWPN 5001438021e071ec) Fri Jan 30 20:07:46 CET [filer-prod-201: scsitarget.ispfct.targetReset:notice]: FCP Target 0c: Target was Reset by the Initiator at Port Id: 0x10200 (WWPN 50014380186abac4) ... Fri Jan 30 20:08:14 CET [filer-prod-201: scsitarget.ispfct.portLogin:notice]: FCP login on Fibre Channel adapter '0c' from '50:01:43:80:21:e0:71:ec', address 0x11000. Fri Jan 30 20:08:14 CET [filer-prod-201: scsitarget.ispfct.portLogin:notice]: FCP login on Fibre Channel adapter '0c' from '50:01:43:80:18:6a:ba:c4', address 0x10200. So every single initiator on the filer *not involved* in the maintenance were reset, then tried to login back, reset again and it looped like that until I disabled filer-prod-204's target ports on the FC switches. Once the filer-prod-204 booted up with OnTAP, the issue was gone. I know it because when I tried to re-enabled the filer-prod-204's target ports, I didn't see any message like above and everything is running fine since then. Does anyone have an idea what was happing here and why? Cheers, Vladimir

3 10

Check config
by Camillo Gornati 11 Feb '15

11 Feb '15

Hi all, today in the morning we had a little issue with our time sync, causing the CIFS service to stop working. Now that everything is back to normal, i would like to check with you guys how can check if my filer is 100% ok? We hava a FAS2040 (dual head fully licensed) 2 DS4243 24 disks on it. I want to know if in case of a hardware failure my my system will still be online, redundant. I am kind of new to netapp and assumed this system recently, hasn’t been configured by me. Any help will do it.. Thanks C.

4 3

IOPS Planning for the Deswizzle Process?
by Philbert Rupkins 10 Feb '15

10 Feb '15

Hello Toasters, We've unfortunately had to reduce the frequency of our volume snapmirror updates in order to allow for our destination aggregate to deswizzle. We highly prefer hourly volume snapmirror updates but it turns our our source volumes are large enough and/or have enough snapshots that the deswizzle process never completes on the destination aggregate. Our volume snapmirror destination aggregate is a single tray of SATA. Prior to reducing the frequency of snapmirror updates, the SATA aggregate was running at 90-100% utilization 24x7 with little to no IO to the filer from active clients. Needless to say, serving data from said aggregate was VERY SLOW despite the light IO (<300 IOPS) required by the clients sourcing their primary data from the SATA aggregate. We've done what we can to reduce the impact of deswizzling. Namely, cutting down on snapshots and reducing the volume size. I understand reducing volume size doesnt reduce the maxfiles setting which believe ultimately impact the amount of deswizzling necessary on the destination. I'm still digging into other options we can try but reducing the frequency of snapmirror updates seems to have the most impact. How does one plan for IOPs or disk utilization resulting from the deswizzle process? If I recall correctly, during our planning sessions with NetApp, our Netapp SE never touched on IOPs or number of spindles required to handle deswizzling while serving data from the same aggregate. In fact, I think our aggregates were size purely based on the amount of IO generated from active clients (not active clients + deswizzle). Thanks, Phil

2 3

Re: IOPS Planning for the Deswizzle Process?
by Philbert Rupkins 10 Feb '15

10 Feb '15

Can you expand upon why QSM wouldn't be a good choice for a general DR use case? We currently do not use "vfiler dr" and have no immediate plans to use it in the future. On Thu, Feb 5, 2015 at 2:28 PM, Peter-Paul Witta <paul.witta(a)cubit.at> wrote: > Great! > Just keep in mind QSM might not be the best choice for DR or vfilerDR use > cases... > > kind regards, > Ing. Peter-Paul Witta > Chief Technology Officer www.CUBiT.at > Mobile +436644542287 > Office +4317189880-0 > > Am 05.02.2015 um 21:17 schrieb Philbert Rupkins <philbertrupkins(a)gmail.com > >: > > Just a quick update. We're generally a volume snapmirror shop. I think > I read somewhere that VSM is generally recommended in most cases. > > However, I also read that Qtree SnapMirror is not subject to the same > deswizzling process that runs on the destination when using VSM. My > understanding is this is because VSM is block based whereas QSM is not. > The SnapMirror TR goes through a fairly decent list of the differences > between VSM and QSM. Since QSM does not require deswizzling, I think > we are going to give QSM a shot for the volumes with many snapshots. > Sure, we'll need to dedupe the QSM destination and figure out how to manage > snapshots, but QSM sounds like something we need to consider given the high > disk utilization resulting from the deswizzle process. > > -Phil > > On Tue, Feb 3, 2015 at 10:44 AM, Philbert Rupkins < > philbertrupkins(a)gmail.com> wrote: > >> Paul, >> >> Thanks for this tip. I cant find much about the wafl.deswizzle.enable >> option on the support site. I did find a document that says "This is a >> diagnostic mode option that should only be used as part of an action plan >> under NetApp Global Support supervision." I guess I'll be giving them a >> call. >> >> Did you find this option mentioned in another document somewhere? >> Quarterly, we refresh an environment on the remote side which involves >> promoting a (volume) snapmirror replica to a primary copy of the data. >> I just want to make sure I am not going to shoot myself in the foot (from a >> performance perspective) with this option when we break a snapmirror >> replica and use the destination as a primary copy. >> >> Thanks, >> Phil >> >> On Tue, Jan 27, 2015 at 2:04 PM, Peter-Paul Witta <paul.witta(a)cubit.at> >> wrote: >> >>> if you do not plan to use the destination regularily tun the >>> deswziller off. >>> otherwise you'd deswizzle lots of snapshots you'll never use active on >>> the destination anyway... >>> >>> greets, >>> paul >>> >>> >>> Am 27.01.15 um 20:55 schrieb Philbert Rupkins: >>> >>> Hello Toasters, >>> >>> We've unfortunately had to reduce the frequency of our volume >>> snapmirror updates in order to allow for our destination aggregate to >>> deswizzle. We highly prefer hourly volume snapmirror updates but it turns >>> our our source volumes are large enough and/or have enough snapshots that >>> the deswizzle process never completes on the destination aggregate. Our >>> volume snapmirror destination aggregate is a single tray of SATA. Prior to >>> reducing the frequency of snapmirror updates, the SATA aggregate was >>> running at 90-100% utilization 24x7 with little to no IO to the filer from >>> active clients. Needless to say, serving data from said aggregate was >>> VERY SLOW despite the light IO (<300 IOPS) required by the clients sourcing >>> their primary data from the SATA aggregate. >>> >>> >>> We've done what we can to reduce the impact of deswizzling. Namely, >>> cutting down on snapshots and reducing the volume size. I understand >>> reducing volume size doesnt reduce the maxfiles setting which believe >>> ultimately impact the amount of deswizzling necessary on the destination. >>> I'm still digging into other options we can try but reducing the frequency >>> of snapmirror updates seems to have the most impact. >>> >>> How does one plan for IOPs or disk utilization resulting from the >>> deswizzle process? If I recall correctly, during our planning sessions >>> with NetApp, our Netapp SE never touched on IOPs or number of spindles >>> required to handle deswizzling while serving data from the same aggregate. >>> In fact, I think our aggregates were size purely based on the amount of >>> IO generated from active clients (not active clients + deswizzle). >>> >>> Thanks, >>> Phil >>> >>> >>> _______________________________________________ >>> Toasters mailing listToasters@teaparty.nethttp://www.teaparty.net/mailman/listinfo/toasters >>> >>> >>> >>> -- >>> kind regards, +43-664-4542287 >>> Ing. Peter-Paul Witta +43-1-7189880-0 >>> CTO/techn. Geschaeftsleitung www.CUBiT.at >>> >>> >> > _______________________________________________ > Toasters mailing list > Toasters(a)teaparty.net > http://www.teaparty.net/mailman/listinfo/toasters > >

2 1

"iscsi interface disable" Effect on Existing iSCSI Portals
by Philbert Rupkins 10 Feb '15

10 Feb '15

Hello Toasters, We have a client looking to limit iscsi services to a dedicated interface. It looks like, by default, ONTAP is running iSCSI portals on all interfaces in both the pfiler (vfiler0) and all vfilers. Is "iscsi interface disable" on vfiler0 (physical filer) the best way to get rid of all of the extraneous iscsi portals? Will running "iscsi interface disable" on the physical filer get rid of the iscsi portal(s) on the physical filers and vfilers? Not sure if I'll need to run a portal/tpgroup specific command or if "iscsi interface disable" will get rid of the portals. 8.1.3 7-Mode. Thanks, Phil

2 4

NT4 crypto ?
by Mark Flint 10 Feb '15

10 Feb '15

Anone seen this type of message in their AD logs:- The session setup from the computer NETAPP12B failed to authenticate. The name(s) of the account(s) referenced in the security database is NETAPP12B$. The following error occurred: The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you. And have an idea of why their appearing (all seems well with auth and CIFS ) and what I need to alter to make them stop, ‘cos my AD guy would;d like ti to atop, without him adding a new mail rule :) Thanks in advance, ~Mark

2 2

Re: nfsstat -l not in 8.1 ?
by Paul Letta 09 Feb '15

09 Feb '15

yep that was it.. thanks to you and the others that pointed that out. I knew it had to still be there.. Paul From: "Richard Payne" <richard.payne(a)amd.com> To: "Paul Letta" <letta(a)jlab.org>, "toasters" <toasters(a)teaparty.net> Sent: Monday, February 9, 2015 10:51:41 AM Subject: RE: nfsstat -l not in 8.1 ? You have multistore enabled/licensed. Instead run: vfiler run vfiler0 nfsstat –l --rdp From: toasters-bounces(a)teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Paul Letta Sent: Monday, February 09, 2015 10:48 AM To: toasters Subject: nfsstat -l not in 8.1 ? What happened to "nfsstat -l" on 8.1 ? I just tried to do this for the first time in a while.. "nfsstat -l" works fine on our 7.x and 8.2 filers.. Was it removed in 8.1..? I tried it with advanced commands turned on as well. I'm typing nfsstat dash ell... thanks, Paul xx> version NetApp Release 8.1.4P1 7-Mode: Tue Feb 11 23:23:31 PST 2014 xx> options nfs.per_client_stats.enable nfs.per_client_stats.enable on xx> nfsstat -l usage: nfsstat <interval> [ <count> ] usage: vfiler run <vfname> nfsstat -h [ -n [ <count> ] ] | [ [ <hostname or ip address> ] [ <interval> ] ] usage: vfiler run <vfname> nfsstat -l [ <count> ] usage: nfsstat -z usage: nfsstat -C usage: nfsstat [ -c ] [ -t ] xx> xx> priv set advanced Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel. xx*> xx*> nfsstat -l usage: nfsstat <interval> [ <count> ] usage: vfiler run <vfname> nfsstat -h [ -n [ <count> ] ] | [ [ <hostname or ip address> ] [ <interval> ] ] usage: vfiler run <vfname> nfsstat -l [ <count> ] usage: nfsstat -z usage: nfsstat -C usage: nfsstat [ -c ] [ -t ]

1 0

nfsstat -l not in 8.1 ?
by Paul Letta 09 Feb '15

09 Feb '15

What happened to "nfsstat -l" on 8.1 ? I just tried to do this for the first time in a while.. "nfsstat -l" works fine on our 7.x and 8.2 filers.. Was it removed in 8.1..? I tried it with advanced commands turned on as well. I'm typing nfsstat dash ell... thanks, Paul xx> version NetApp Release 8.1.4P1 7-Mode: Tue Feb 11 23:23:31 PST 2014 xx> options nfs.per_client_stats.enable nfs.per_client_stats.enable on xx> nfsstat -l usage: nfsstat <interval> [ <count> ] usage: vfiler run <vfname> nfsstat -h [ -n [ <count> ] ] | [ [ <hostname or ip address> ] [ <interval> ] ] usage: vfiler run <vfname> nfsstat -l [ <count> ] usage: nfsstat -z usage: nfsstat -C usage: nfsstat [ -c ] [ -t ] xx> xx> priv set advanced Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel. xx*> xx*> nfsstat -l usage: nfsstat <interval> [ <count> ] usage: vfiler run <vfname> nfsstat -h [ -n [ <count> ] ] | [ [ <hostname or ip address> ] [ <interval> ] ] usage: vfiler run <vfname> nfsstat -l [ <count> ] usage: nfsstat -z usage: nfsstat -C usage: nfsstat [ -c ] [ -t ]

3 2

Re: IOPS Planning for the Deswizzle Process?
by Philbert Rupkins 05 Feb '15

05 Feb '15

Paul, Thanks for this tip. I cant find much about the wafl.deswizzle.enable option on the support site. I did find a document that says "This is a diagnostic mode option that should only be used as part of an action plan under NetApp Global Support supervision." I guess I'll be giving them a call. Did you find this option mentioned in another document somewhere? Quarterly, we refresh an environment on the remote side which involves promoting a (volume) snapmirror replica to a primary copy of the data. I just want to make sure I am not going to shoot myself in the foot (from a performance perspective) with this option when we break a snapmirror replica and use the destination as a primary copy. Thanks, Phil On Tue, Jan 27, 2015 at 2:04 PM, Peter-Paul Witta <paul.witta(a)cubit.at> wrote: > if you do not plan to use the destination regularily tun the deswziller > off. > otherwise you'd deswizzle lots of snapshots you'll never use active on the > destination anyway... > > greets, > paul > > > Am 27.01.15 um 20:55 schrieb Philbert Rupkins: > > Hello Toasters, > > We've unfortunately had to reduce the frequency of our volume snapmirror > updates in order to allow for our destination aggregate to deswizzle. We > highly prefer hourly volume snapmirror updates but it turns our our source > volumes are large enough and/or have enough snapshots that the deswizzle > process never completes on the destination aggregate. Our volume > snapmirror destination aggregate is a single tray of SATA. Prior to > reducing the frequency of snapmirror updates, the SATA aggregate was > running at 90-100% utilization 24x7 with little to no IO to the filer from > active clients. Needless to say, serving data from said aggregate was > VERY SLOW despite the light IO (<300 IOPS) required by the clients sourcing > their primary data from the SATA aggregate. > > > We've done what we can to reduce the impact of deswizzling. Namely, > cutting down on snapshots and reducing the volume size. I understand > reducing volume size doesnt reduce the maxfiles setting which believe > ultimately impact the amount of deswizzling necessary on the destination. > I'm still digging into other options we can try but reducing the frequency > of snapmirror updates seems to have the most impact. > > How does one plan for IOPs or disk utilization resulting from the > deswizzle process? If I recall correctly, during our planning sessions > with NetApp, our Netapp SE never touched on IOPs or number of spindles > required to handle deswizzling while serving data from the same aggregate. > In fact, I think our aggregates were size purely based on the amount of > IO generated from active clients (not active clients + deswizzle). > > Thanks, > Phil > > > _______________________________________________ > Toasters mailing listToasters@teaparty.nethttp://www.teaparty.net/mailman/listinfo/toasters > > > > -- > kind regards, +43-664-4542287 > Ing. Peter-Paul Witta +43-1-7189880-0 > CTO/techn. Geschaeftsleitung www.CUBiT.at > >

1 1

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