toasters

toasters@lists.teaparty.net

3 participants
13514 discussions

RE: Net Stats, where from?
by rbonine＠millermartin.com 11 Jan '01

11 Jan '01

This would be very handy for our site as well. (I get the feeling that not many people with NT-only sites such as ours buy filers.) --Roger "Todd C. Merrill" <tmerrill(a)mathworks.com> on 01/11/2001 09:36:44 AM Please respond to "Todd C. Merrill" <tmerrill(a)mathworks.com> To: toasters(a)mathworks.com cc: (bcc: Roger Bonine/M&M) Subject: RE: Net Stats, where from? On Thu, 11 Jan 2001, Witham, John wrote: > http://now.netapp.com/NOW/download/tools/ntaptop/ > > Display Top NFS Clients (netapp-top.pl) > Note: This tool is unsupported - NetApp offers no support for it May I implore NetApp to make available similar capability to that of `nfsstat -l` for CIFS clients? Maybe some hook into the pktt capability to show per host packet/byte counts? These filers, after all, are multi-protocol fileservers. Half the time for me it's one or more Windows hosts that give me headaches in terms of filer load. I'd love to be able to do ALL these functions: nfsstat -z <wait> nfsstat -l cifsstat -z <wait> cifsstat -l opsstat -z <wait> opsstat -l Until next time... The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

1 0

RE: Net Stats, where from?
by Witham, John 11 Jan '01

11 Jan '01

Not to skin a dead horse... http://now.netapp.com/NOW/download/tools/ntaptop/ Display Top NFS Clients (netapp-top.pl) Note: This tool is unsupported - NetApp offers no support for it If you would like to see a per-client summary of NFS activity on a NetApp filer, this Unix Perl script utility will help. Here's some sample output: NFS/s total NFS/s = 708 | interval = 60 ------ ---------------------------------------- 323 mercury.netapp.com 156 venus.netapp.com 113 earth.netapp.com 61 mars.netapp.com 48 jupiter.netapp.com 3 saturn.netapp.com 3 uranus.netapp.com 1 neptune.netapp.com HTH -john John Witham MCSE, MCP+i, A+ Senior Systems Engineer Takeda Pharmaceuticals America, Inc. V://847.383.3304 F://847.383.3205 mailto://jwitham@takedapharm.com -----Original Message----- From: Collins, Brian [mailto:brian.collins@netapp.com] Sent: Wednesday, January 10, 2001 7:51 AM To: 'Martin Hannigan'; BrianH(a)dice.com; toasters(a)mathworks.com Subject: RE: Net Stats, where from? You might want to look at http://now.netapp.com/NOW/download/tools/filer-mrtg/ as well. bc -----Original Message----- From: Martin Hannigan [mailto:hannigan@fugawi.net] Sent: Wednesday, January 10, 2001 7:54 AM To: BrianH(a)dice.com; toasters(a)mathworks.com Subject: Re: Net Stats, where from? Try MRTG. Do a google search. It's an SNMP tool that allows you to script "things" reported by SNMP. At the minimum, run it against the filer and the switch for the office, if it's SNMP'able, and you should be able to see the port it's coming from..at a minimum. But also, using stats on the filter to track down the file set is useful. I haven't had to do this in awhile, so I can't help you there. -M At 09:06 PM 1/9/2001 -0600, BrianH(a)dice.com wrote: >Does anyone know a nice easy way to tell where network traffic is coming >from? Something like nfssat -l where you can see that x% of your traffic >comes from xxx.xxx.xxx.xxx or something like that? I have tons and tons of >writes happending on my 740, which is killing the CPU. The problem is it >just started the other day and it is killing the overall performance of the >filer. nfsstat -l shows me the number of NFS ops, and none of them seem out >of line at all. > >Ideas? > >--Brian

2 1

RE: Net Stats, where from?
by Krause, Oliver 11 Jan '01

11 Jan '01

Sorry, i forgot to mention that is was based on the config files which you can find at the previous mentioned link, but i modified it a lot. > -----Original Message----- > From: Jeffrey Krueger [mailto:jkrueger@qualcomm.com] > Sent: Mittwoch, 10. Januar 2001 21:23 > To: Quentin Fennessy > Cc: Manny Kaiser; toasters(a)mathworks.com > Subject: Re: Net Stats, where from? > > > On Wed, Jan 10, 2001 at 11:56:07AM -0600, Quentin Fennessy wrote: > > > > mkaiser(a)mmcnet.com said: > > > Touching on the subject of MRTG, I suggest using it's successor - > > > cricket: > > > > > http://cricket.sourceforge.net > > > > I'll second that comment -- we are using cricket to help > > manage 28 filers in 3 buildings in 2 states. About 15TB. > > We're using FILER-MRTG as distributed by NetApp. Could > anyone donate some > functional (and hopefully documented) cricket configurations > for filers? > > -- Jeff > > -- > -------------------------------------------------------------- > -------------- > Jeff Krueger, NetApp CA E-Mail: > jeff(a)qualcomm.com > Senior Engineer Phone: 858-651-6709 > NetApp Filers / UNIX Infrastructure Fax: 858-651-6627 > QUALCOMM, Inc. IT Engineering Web: > www.qualcomm.com >

1 0

RE: Net Stats, where from?
by Krause, Oliver 11 Jan '01

11 Jan '01

Attached you can find a config i made some weeks ago. It is still work in progress, especially the interface part is not satisfying yet. Oliver > -----Original Message----- > From: Jeffrey Krueger [mailto:jkrueger@qualcomm.com] > Sent: Mittwoch, 10. Januar 2001 21:23 > To: Quentin Fennessy > Cc: Manny Kaiser; toasters(a)mathworks.com > Subject: Re: Net Stats, where from? > > > On Wed, Jan 10, 2001 at 11:56:07AM -0600, Quentin Fennessy wrote: > > > > mkaiser(a)mmcnet.com said: > > > Touching on the subject of MRTG, I suggest using it's successor - > > > cricket: > > > > > http://cricket.sourceforge.net > > > > I'll second that comment -- we are using cricket to help > > manage 28 filers in 3 buildings in 2 states. About 15TB. > > We're using FILER-MRTG as distributed by NetApp. Could > anyone donate some > functional (and hopefully documented) cricket configurations > for filers? > > -- Jeff > > -- > -------------------------------------------------------------- > -------------- > Jeff Krueger, NetApp CA E-Mail: > jeff(a)qualcomm.com > Senior Engineer Phone: 858-651-6709 > NetApp Filers / UNIX Infrastructure Fax: 858-651-6627 > QUALCOMM, Inc. IT Engineering Web: > www.qualcomm.com >

1 0

Net Stats, where from?
by BrianH＠dice.com 10 Jan '01

10 Jan '01

Does anyone know a nice easy way to tell where network traffic is coming from? Something like nfssat -l where you can see that x% of your traffic comes from xxx.xxx.xxx.xxx or something like that? I have tons and tons of writes happending on my 740, which is killing the CPU. The problem is it just started the other day and it is killing the overall performance of the filer. nfsstat -l shows me the number of NFS ops, and none of them seem out of line at all. Ideas? --Brian

6 5

RE: Net Stats, where from?
by Collins, Brian 10 Jan '01

10 Jan '01

You might want to look at http://now.netapp.com/NOW/download/tools/filer-mrtg/ as well. bc -----Original Message----- From: Martin Hannigan [mailto:hannigan@fugawi.net] Sent: Wednesday, January 10, 2001 7:54 AM To: BrianH(a)dice.com; toasters(a)mathworks.com Subject: Re: Net Stats, where from? Try MRTG. Do a google search. It's an SNMP tool that allows you to script "things" reported by SNMP. At the minimum, run it against the filer and the switch for the office, if it's SNMP'able, and you should be able to see the port it's coming from..at a minimum. But also, using stats on the filter to track down the file set is useful. I haven't had to do this in awhile, so I can't help you there. -M At 09:06 PM 1/9/2001 -0600, BrianH(a)dice.com wrote: >Does anyone know a nice easy way to tell where network traffic is coming >from? Something like nfssat -l where you can see that x% of your traffic >comes from xxx.xxx.xxx.xxx or something like that? I have tons and tons of >writes happending on my 740, which is killing the CPU. The problem is it >just started the other day and it is killing the overall performance of the >filer. nfsstat -l shows me the number of NFS ops, and none of them seem out >of line at all. > >Ideas? > >--Brian

1 0

RE: Net Stats, where from?
by Bailey, Jourdan 10 Jan '01

10 Jan '01

A similar case I had a couple days ago it was necessary to get a pktt trace to see a client which was running a script against a volume which did not have permissions set. The nfsstat -l command was not very helpful in finding the "Bad" client. It was in the top few of the busy clients, but the filer had a several clients running builds. The pktt converted to a snoop trace showed one client with many permission denied errors. Using top on that client found the program killing the filer performance. Jourdan > -----Original Message----- > From: Mike Smith [mailto:mikesmit@netapp.com] > Sent: Tuesday, January 09, 2001 11:00 PM > To: Sims, Aaron; BrianH(a)dice.com; toasters(a)mathworks.com > Subject: Re: Net Stats, where from? > > > Or you could use the option > > options nfs.per_client_stats.enable on > > Wait a while (say 20 minutes during the time when > the system is being written to heavily - you should be > able to see if it is being written to heavily by running > sysstat 1 for a bit). > > After a period of time you can run the following commands > to see which client/ip is doing what: > > nfsstat -l shows output like the following: > tattoo> nfsstat -l > tattoo> nfsstat -l > 10.32.16.87 cousinit.hq.netapp.com NFSOPS = 172079 (94%) > 10.32.16.88 pugsley.hq.netapp.com NFSOPS = 10580 ( 6%) > > and nfsstat -h will show more detailed output for each > client that is hitting the filer. > > To turn the option off type: > options nfs.per_client_stats.enable off > > There is a small performance penalty for turning on per client > stats. > > Hope that helps. > ~~~~~~~~~~~~~~~ > Mike Smith > Network Appliance > Escalations Engineer > 408-822-4755 > mikesmit(a)netapp.com > Get your answers on > http://now.netapp.com > ~~~~~~~~~~~~~~~~~ > > > > ----- Original Message ----- > From: Sims, Aaron <Aaron.Sims(a)netapp.com> > To: <BrianH(a)dice.com>; <toasters(a)mathworks.com> > Sent: Tuesday, January 09, 2001 7:39 PM > Subject: RE: Net Stats, where from? > > > > Use 'pktt' on the filer to collect > > a packet trace. It's in tcpdump format. > > You can use ethereal (www.ethereal.org) to > > read the trace. From that you should > > be able to find the culprit. > > > > You can use pktt as such: (my comments are in {}) > > > > pktt start e0 { this starts tracing e0 } > > pktt dump { this causes a file to be created with > the content of > the > > dump} > > pktt stop e0 { stops capturing packets on e0 } > > > > THe interface name can be changed to 'all'. > > There are some other options to pktt. > > -d <dir> /* Specifies the directory to put trace in */ > > -b <buffersize> /* How big a buffer to use to capture packets... > > don't make this too large... never more than 1m */ > > -i <ipaddr> /* Self explanitory */ > > > > There are some other options. You can > > search for 'pktt' on NOW to get more info. > > > > Aaron > > > > > > > > > -----Original Message----- > > > From: BrianH(a)dice.com [mailto:BrianH@dice.com] > > > Sent: Tuesday, January 09, 2001 10:07 PM > > > To: toasters(a)mathworks.com > > > Subject: Net Stats, where from? > > > > > > > > > Does anyone know a nice easy way to tell where network > > > traffic is coming > > > from? Something like nfssat -l where you can see that x% of > > > your traffic > > > comes from xxx.xxx.xxx.xxx or something like that? I have > > > tons and tons of > > > writes happending on my 740, which is killing the CPU. The > > > problem is it > > > just started the other day and it is killing the overall > > > performance of the > > > filer. nfsstat -l shows me the number of NFS ops, and none > > > of them seem out > > > of line at all. > > > > > > Ideas? > > > > > > --Brian > > > > > >

1 0

RE: Net Stats, where from?
by Sims, Aaron 10 Jan '01

10 Jan '01

Use 'pktt' on the filer to collect a packet trace. It's in tcpdump format. You can use ethereal (www.ethereal.org) to read the trace. From that you should be able to find the culprit. You can use pktt as such: (my comments are in {}) pktt start e0 { this starts tracing e0 } pktt dump { this causes a file to be created with the content of the dump} pktt stop e0 { stops capturing packets on e0 } THe interface name can be changed to 'all'. There are some other options to pktt. -d <dir> /* Specifies the directory to put trace in */ -b <buffersize> /* How big a buffer to use to capture packets... don't make this too large... never more than 1m */ -i <ipaddr> /* Self explanitory */ There are some other options. You can search for 'pktt' on NOW to get more info. Aaron > -----Original Message----- > From: BrianH(a)dice.com [mailto:BrianH@dice.com] > Sent: Tuesday, January 09, 2001 10:07 PM > To: toasters(a)mathworks.com > Subject: Net Stats, where from? > > > Does anyone know a nice easy way to tell where network > traffic is coming > from? Something like nfssat -l where you can see that x% of > your traffic > comes from xxx.xxx.xxx.xxx or something like that? I have > tons and tons of > writes happending on my 740, which is killing the CPU. The > problem is it > just started the other day and it is killing the overall > performance of the > filer. nfsstat -l shows me the number of NFS ops, and none > of them seem out > of line at all. > > Ideas? > > --Brian >

2 1

following unix soft links
by Coder, James (STP) 09 Jan '01

09 Jan '01

I recently moved users from a Solaris home server to our 760 (6.0.1.r1). filer. The users had created soft links (ln -s) to directories (either within their home directory or to other points via the automounter). Previously the Unix home shares were shared via samba and Unix users in the Windows environment could follow a soft link to the directory. With the data moved to the NetApp, this is no longer available when using CIFS. I opened a case with NetApp and basically the answer was - that's right - the filer won't follow the link to a directory. I have toyed with the idea of using samba on a box and letting the user point to it, thus letting samba provide the share service. Have not tried this, but was wondering if anyone has? Does anyone know of a work-around for this? Thx in advance for any replies. JCC James C. Coder UNIX Administrator Guidant Corporation Phone: 651-582-4797 Email: james.coder(a)guidant.com <mailto:james.coder@guidant.com>

4 4

RE: following unix soft links
by Muhlestein, Mark 09 Jan '01

09 Jan '01

Thanks for posting the good comments, Steve. The name of the config file is /etc/symlink.translations, and it's used to map "rooted" symlinks (i.e. they start with "/"). This is all covered in the documentation. We are developing a solution to this that allows you to securely follow links that leave a share. We'll let folks know when that becomes available. Or watch for bug 15808 to be fixed :-) Mark Muhlestein -- mmm(a)netapp.com > -----Original Message----- > From: Steve Losen [mailto:scl@sasha.acc.virginia.edu] > Sent: Tuesday, January 09, 2001 8:33 AM > To: Coder, James (STP) > Cc: toasters(a)mathworks.com > Subject: Re: following unix soft links > > > > The filer does indeed understand and follow symlinks. Just be > sure the symlink "makes sense" from the filer's perspective. > > Note that under NFS, the filer simply sends the value of the > symlink to the client and the client actually follows it. > So under NFS the filer acts just like any other NFS server with > regard to symlinks. > > Under CIFS, however, the client does not know what a symlink is, > so the filer itself must follow it. So the symlink must "make sense" > to the filer. > > Check out these options in the man pages and Sys. Admin. Guide > > options cifs.home_dir > options cifs.symlinks.enable > options cifs.symlinks.cycleguard > > There is also a file you can create (forgot the name) that the > filer uses to translate symlinks so that they make sense to > the filer. > > To prevent users from circumventing security using symlink tricks, > the filer will not follow all symlinks. But it should follow > any symlink that refers back to the same share, provided the > user has permissions to follow it. And the symlink must make > sense to the filer, so relative symlinks are better than absolute > ones, eg, foo -> ../bar/baz > > Obviously, any symlink that triggers an automount is not going > to work unless the data is on the same filer and you can come up > with a translation that works. > > The cifs.home_dir option is very handy if you have a lot of users. > It allows you to automatically create a share for each user's > home directory. That way a user can attach to \\FILER\loginid > and get straight into their home directory. All the home > directories must have the same name as the loginid and must > be directly beneath the cifs.home_dir directory. You can get > around this restriction by using a directory of symlinks instead. > The symlinks can cross volumes, but not filers. For example, > set up the option like this: > > options cifs.home_dir /vol/vol0/shares > > Assume user bill's home directory is in /vol/vol0/h1/b/bi/bill > > Set up this symlink on the filer: > > /vol/vol0/shares/bill -> /vol/vol0/h1/b/bi/bill > > Now bill can simply attach to \\FILER\bill to get into his > home directory. > > > > I recently moved users from a Solaris home server to our > 760 (6.0.1.r1). > > filer. The users had created soft links (ln -s) to > directories (either > > within their home directory or to other points via the automounter). > > Previously the Unix home shares were shared via samba and > Unix users in the > > Windows environment could follow a soft link to the directory. > > > > With the data moved to the NetApp, this is no longer > available when using > > CIFS. I opened a case with NetApp and basically the answer > was - that's > > right - the filer won't follow the link to a directory. > > > > I have toyed with the idea of using samba on a box and > letting the user > > point to it, thus letting samba provide the share service. > Have not tried > > this, but was wondering if anyone has? Does anyone know of > a work-around > > for this? > > > > Thx in advance for any replies. > > > > JCC > > > > > > > > > > James C. Coder > > UNIX Administrator > > Guidant Corporation > > Phone: 651-582-4797 > > Email: james.coder(a)guidant.com <mailto:james.coder@guidant.com> > > > > Steve Losen scl(a)virginia.edu phone: 804-924-0640 > > University of Virginia ITC Unix Support >

1 0

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