toasters

toasters@lists.teaparty.net

2 participants
13529 discussions

Permission denied
by Jennifer Armenta 25 Feb '02

25 Feb '02

Have a mixed share with a folder that I can't delete. I keep getting "permission denied" from unix NFS and mapping cifs share. Any idea how to remove this folder?

2 1

FS: [UK] spares kit
by chris＠g2.nu 23 Feb '02

23 Feb '02

I have the following surpluss items: F760 spares kit £1500 FC storage shelf spares kit, including 1 18GB drive £750 Items are currently locate in the UK. Contact me if interested or for further details. Chris --

1 0

Re: Permission denied
by Rune Bakken 23 Feb '02

23 Feb '02

Jennifer Armenta <ArmentaJ(a)mascorp.com> writes: > Have a mixed share with a folder that I can't delete. I keep getting > "permission denied" from unix NFS and mapping cifs share. Any idea how to > remove this folder? Is this folder shared? I have seen this when a folder itself is shared - and I was unable to delete the folder before removing the share. There may also be obscure problems with the mixed security setting, on my site I have stopped using mixed settings as none of the applications required mixed setting - and I could choose either unix or ntfs according to the users what platform the users was using. In my case I got rid of most of my troubles with ownerships etc. >>>>>>>>>>.rune -- Rune Bakken Senior System Administrator Telenor Business Company (Nextra), IP-Services Ph: +47 22 77 03 93

1 0

RE: set read and write to 8K; was Slow writes
by Mike Sphar 22 Feb '02

22 Feb '02

Here is some numbers I'm seeing from an nfsstat -d on one of my filers: num msg=0, too many mbufs=3631, rpcErr=3532, svrErr=0 I can see from the man page that the too many mbufs error means that there are udp packets being dropped because there are not enough mbufs available. What I can't find out is what if anything I can or should do about it. I've searched around on now but haven't found a specific mention of this for some reason (possibly just because I haven't had my coffee yet). Anyone have any advice one whether those numbers should be a cause for concern? -- Mike Sphar - Sr Systems Administrator - Engineering Support Peregrine Systems, Inc.

1 0

netapp filer mib and spectrum
by neil lehrer 22 Feb '02

22 Feb '02

has anyone imported the filer mib into spectrum netwk mgmt sw? if so, can you tell me what you had to do? thanks

1 0

set read and write to 8K; was Slow writes
by Jim Harm 22 Feb '02

22 Feb '02

I have heard this from NetApp technicians and on this list, but The only thing I found on the NetApp web page search was a reference to a switch that would overflow the buffer when translating from gigabit ethernet to fast ethernet. Someone please, point me to the bug description. We have seen the improvement, but we run GigE from client to server. None of the switches show errors or severe packet loss. The server shows packet loss, but how is that decreased by smaller read and write sizes on clients? Our switch software is supposed to be up to date. We see the problem alot and run UDP strictly, so, I need a bug number or a better description of this thing, please. I'm not complaining, I know you are correct; it does improve performance. It's measurable and significant. When I buy new equipment, I want to pinpoint this and avoid it. When fast ethernet is faster that GigE, something is bad. > >From: "Magnus Swenson" <magnuss(a)cadence.com> >Edward, > >Try to disable TCP over NFS and only enable UDP. >Also in a switched environment 10/100/1000 BT keep the xfersizes to 8192 >this has proven to improve performance (at least for us). >This is a known bug on certain switches, it's also listed on now.netapp.com. > >Re, >Magnus Swenson > >Subject: Re: Slow writes -- }}}===============>> LLNL James E. Harm (Jim); jharm(a)llnl.gov System Administrator Compaq Clusters (925) 422-4018 Page: 423-7705x57152

2 3

Mirror target filer config question
by Joe Luchtenberg 22 Feb '02

22 Feb '02

Couldn't find documentation on NOW to answer this. If you are running SnapManager on a mirrored filer, but you are not mirroring the Exchange volume, do you have to license SnapManager on the target filer? I thought the answer was yes, but I can't find the documentation, and intuitively it seems that the answer should be no. The same question applies for SnapDrive and SQL Server volumes that you may not wish to mirror. TIA. Joe Joe Luchtenberg Dataline, Inc. Email: <mailto:joe.luchtenberg@data-line.com> Phone: 757-457-0504 (direct line) 757-858-0600 (front desk) 757-285-1223 (mobile) Fax: 757-858-0606 Please visit us at <http://www.data-line.com/>

1 0

Re: Slow writes
by FPS France 22 Feb '02

22 Feb '02

> Well we are actually getting better writes from tcp, which is weird > due to the small overhead that tcp would have. Here is what I have > currently set on a 2.8 client: if you obtain better perf on tcp, i guess u perhaps lost packets on udp and u should then check ur network : check route from one machine to another with traceroute for example and try to examine where it could possibly cogestion or missroute beetween filer and solaris station (if u have a really wide network, it is normal to loose packets on udp so u were right to be on tcp) > The nfs ops have increased, the only thing I do see if I do a large > cvs checkout the writes are intermitent. I see zeros and then I see a > large write, below is an example. Now is this due to the filer > flushing what it has on memory to disk? yes this is normal, the filer cache writes in the nvram then writes in a singlke shoot on disks

1 0

RE: Slow writes
by Magnus Swenson 21 Feb '02

21 Feb '02

Edward, Try to disable TCP over NFS and only enable UDP. Also in a switched environment 10/100/1000 BT keep the xfersizes to 8192 this has proven to improve performance (at least for us). This is a known bug on certain switches, it's also listed on now.netapp.com. Re, Magnus Swenson Cadence Design Systems Inc. Addison, TX -----Original Message----- From: FPS France [mailto:fpsfrance@fps.fr] Sent: Thursday, February 21, 2002 3:59 AM To: edward valencia; toasters(a)mathworks.com Subject: Re: Slow writes just an idea : did u well check on 100Mb machines (solaris) that they all are in full dupleix or all in half , as - as u may know as u look a guru - mixing the two types can greatlly disturb network performance. Check that in both solaris machines, on the switch, and on other machines in the same subnet. U could try to switch a machine in half dupleix just to c what happend. In any case, make sure u avoid auto negoiciation for 100Mb nic - it's ok for the giga. Hope u will turn around this problem. Fanku to let me know. ----- Original Message ----- From: "edward valencia" <edjv(a)corp.earthlink.net> To: <toasters(a)mathworks.com> Sent: Wednesday, February 13, 2002 2:14 PM Subject: Slow writes > > Hi all, > > I hope that someone has gone through this as I have been trying to > figure this out and its making me go nuts. On our solaris(2.8, 2.6) we > usually do small file writes, our users do cvs checkouts to thier home > directories and compile software that they are working on in that > directory also. The problems is not the reads but the writes, I have > changed the client machines to nfs3/tcp with rsize and wsize or 32k. The > avg time todo a cvs checkout has been about 24 seconds, if this is done > to local disk we are seeing the avg. of 4 seconds. The size of the > module they are checking out is 4mb, this is what I have been doing > tests with, but other cvs modules are also slow while being written to > the nfs mount home directory. The filers also have the nfs.tcp.xfersize > of 32k. Here are the configs of the filer: > > F760 NetApp Release 6.0.1R3: Fri Feb 16 02:42:49 PST 2001 > > e0: flags=8042<BROADCAST,RUNNING,MULTICAST> mtu 1500 > inet 10.174.32.67 netmask 0xffffff80 broadcast 10.174.32.127 > ether 00:a0:98:00:56:a3 (auto-100tx-down) > e4: flags=900042<BROADCAST,RUNNING,TCPCKSUM> mtu 1500 > inet 10.174.32.126 netmask 0xffffff80 broadcast 10.174.32.127 > ether 00:60:cf:20:31:fb (1000fx) > e6: flags=848043<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 > inet 10.174.32.7 netmask 0xffffff80 broadcast 10.174.32.127 > ether 00:90:27:f4:5b:0e (auto-1000sx-fd-up) flowcontrol full > lo: flags=948049<UP,LOOPBACK,RUNNING,MULTICAST,TCPCKSUM> mtu 9188 > inet 127.0.0.1 netmask 0xff000000 broadcast 127.0.0.1 > > We currently only use e6. > > > nfs.mount_rootonly on > nfs.per_client_stats.enable off > nfs.tcp.enable on > nfs.tcp.xfersize 32768 > nfs.udp.xfersize 8192 > nfs.v2.df_2gb_lim off > nfs.v3.enable on > nfs.webnfs.enable off > nfs.webnfs.rootdir XXX > nfs.webnfs.rootdir.set off > > malibu> sysconfig -r > Volume vol0 (root, zoned checksums) > > RAID group 0 > > RAID Disk HA.ID HA SHELF BAY CHAN Used (MB/blks) Phys (MB/blks) > --------- ----- ------------ ---- -------------- -------------- > parity 7.13 7 1 5 FC:A 8600/17612800 8683/17783112 > data 7.14 7 1 6 FC:A 8600/17612800 8683/17783112 > data 7.1 7 0 1 FC:A 8600/17612800 8683/17783112 > data 7.12 7 1 4 FC:A 8600/17612800 8683/17783112 > > Volume vol1 (zoned checksums) > > RAID group 0 > > RAID Disk HA.ID HA SHELF BAY CHAN Used (MB/blks) Phys (MB/blks) > --------- ----- ------------ ---- -------------- -------------- > parity 7.3 7 0 3 FC:A 8600/17612800 8683/17783112 > data 7.2 7 0 2 FC:A 8600/17612800 8683/17783112 > data 7.4 7 0 4 FC:A 8600/17612800 8683/17783112 > data 7.5 7 0 5 FC:A 8600/17612800 8683/17783112 > data 7.6 7 0 6 FC:A 8600/17612800 8683/17783112 > data 7.8 7 1 0 FC:A 8600/17612800 8683/17783112 > data 7.9 7 1 1 FC:A 8600/17612800 8683/17783112 > data 7.10 7 1 2 FC:A 8600/17612800 8683/17783112 > > Here is a copy of sysstat when doing the write to the nfs dir: > > malibu> sysstat -x 1 > CPU NFS CIFS HTTP Total Net kB/s Disk kB/s Tape kB/s Cache > Cache CP CP Disk > in out read write read write > age hit time ty util > 2% 0 0 0 0 0 0 0 0 0 0 > >60 100% 0% - 0% > 2% 0 0 0 0 0 0 0 0 0 0 > >60 100% 0% - 0% > 2% 0 0 0 0 0 0 0 0 0 0 > >60 - 0% - 0% > 2% 0 0 0 0 0 0 0 0 0 0 > >60 100% 0% - 0% > 2% 0 0 0 0 0 0 0 0 0 0 > >60 100% 0% - 0% > 2% 0 0 0 0 0 0 0 0 0 0 > >60 - 0% - 0% > 3% 74 0 0 74 27 15 0 0 0 0 > >60 100% 0% - 0% > 10% 244 0 0 244 341 59 825 973 0 0 > >60 100% 31% T 23% > 8% 252 0 0 252 1145 74 0 0 0 0 > >60 100% 0% - 0% > 6% 240 0 0 240 537 61 8 0 0 0 > >60 100% 0% - 2% > 6% 272 0 0 272 205 62 0 0 0 0 > >60 100% 0% - 0% > 5% 276 0 0 276 154 62 0 0 0 0 > >60 100% 0% - 0% > 6% 280 0 0 280 153 63 8 0 0 0 > >60 100% 0% - 3% > 5% 273 0 0 273 260 63 0 0 0 0 > >60 100% 0% - 0% > 5% 255 0 0 255 163 58 8 0 0 0 > >60 100% 0% - 2% > 5% 270 0 0 270 185 61 8 0 0 0 > >60 100% 0% - 2% > 6% 270 0 0 270 202 61 8 0 0 0 > >60 100% 0% - 2% > 6% 274 0 0 274 362 65 0 0 0 0 > >60 100% 0% - 0% > 13% 271 0 0 271 146 61 272 3860 0 0 > >60 100% 32% T 22% > CPU NFS CIFS HTTP Total Net kB/s Disk kB/s Tape kB/s Cache > Cache CP CP Disk > in out read write read write > age hit time ty util > 5% 270 0 0 270 105 60 0 0 0 0 > >60 100% 0% - 0% > 6% 257 0 0 257 278 60 8 0 0 0 > >60 100% 0% - 2% > 7% 267 0 0 267 567 67 0 0 0 0 > >60 100% 0% - 0% > 6% 287 0 0 287 236 66 0 0 0 0 > >60 100% 0% - 0% > 5% 271 0 0 271 180 61 8 0 0 0 > >60 100% 0% - 2% > 5% 240 0 0 240 168 55 0 0 0 0 > >60 100% 0% - 0% > 5% 269 0 0 269 233 62 8 0 0 0 > >60 100% 0% - 3% > 6% 272 0 0 272 208 62 0 0 0 0 > >60 100% 0% - 0% > 5% 275 0 0 275 148 62 8 0 0 0 > >60 100% 0% - 2% > 5% 229 0 0 229 70 51 40 0 0 0 > >60 99% 0% - 5% > 11% 267 0 0 267 89 59 280 2627 0 0 > >60 100% 29% T 20% > 3% 32 0 0 32 12 7 0 0 0 0 > >60 100% 0% - 0% > 2% 0 0 0 0 0 0 0 0 0 0 > >60 100% 0% - 0% > 2% 0 0 0 0 0 0 0 0 0 0 > >60 100% 0% - 0% > 2% 0 0 0 0 0 0 0 0 0 0 > >60 - 0% - 0% > 2% 0 0 0 0 0 0 0 0 0 0 > >60 100% 0% - 0% > 2% 0 0 0 0 0 0 0 0 0 0 > >60 100% 0% - 0% > > malibu> nfsstat 1 > getattr lookup readlink read write create remove > readdir{plus} > 38878962 17285524 51726 2550544 6300249 2724487 2282134 > 2642512 > 0 0 0 0 0 0 > 13 6 > 0 0 0 0 0 0 > 0 0 > 0 0 0 0 0 0 > 0 0 > 0 0 0 0 0 0 > 0 0 > 0 0 0 0 0 0 > 0 0 > 29 8 0 0 2 4 > 0 0 > 68 72 0 0 38 21 > 1 0 > 60 60 0 0 61 15 > 0 0 > 68 68 0 0 47 17 > 0 0 > 72 72 0 0 36 18 > 0 0 > 72 72 0 0 36 18 > 0 0 > 72 72 0 0 36 18 > 0 0 > 70 76 0 0 37 18 > 0 0 > 76 76 0 0 38 19 > 0 0 > 72 72 0 0 36 18 > 0 0 > 72 72 0 0 36 18 > 0 0 > 72 72 0 0 40 18 > 0 0 > 72 72 0 0 37 18 > 0 0 > 72 72 0 0 36 18 > 0 0 > getattr lookup readlink read write create remove > readdir{plus} > 38879981 17286532 51726 2550544 6300803 2724743 2282148 > 2642518 > 66 68 0 0 45 17 > 0 0 > 68 72 0 0 36 17 > 0 0 > 76 76 0 0 38 19 > 0 0 > 71 74 0 0 36 18 > 0 0 > 72 72 0 0 36 18 > 0 0 > 72 72 0 0 37 18 > 0 0 > 57 77 0 0 30 18 > 1 0 > 73 83 0 0 34 24 > 2 0 > 48 57 0 0 24 15 > 2 0 > 0 0 0 0 0 0 > 0 0 > > > > > Client settings for nfs: > > /nfs/home from malibu:/vol/vol1/home > Flags: > vers=3,proto=tcp,sec=sys,hard,intr,link,symlink,rsize=32768,wsize=32768,retr ans=5 > > /nfs/dpkg from malibu:/vol/vol1/dpkg > Flags: > vers=3,proto=tcp,sec=sys,hard,intr,link,symlink,acl,rsize=32768,wsize=32768, retrans=5 > > The /dev/tcp settings have been left as default, and the /dev/hme > settings have been changed to do fdx/non-auto. The filers are on fiber, > and the clients are on 100mb, we are using a foundry bigiron 8000 to > connect all the clients to the netapps. > > > I hope you all can help. > > > cheers, > > > edwardv- >

2 1

RE: Upgrading firmware
by Noll, Kevin 21 Feb '02

21 Feb '02

We have a 2 x F820 clustered. We have experienced 2 hardware failures on one of our F820 is the space of 1 week. During these hardware failures, the filer didnt manage to do a failover automatically. We had to do a force take over. All configs are identical as per cluster options. The only thing I see is that time clock is out of sync, which was caused during an upgrade in DataOnTap. (Known Bug) What I would like to know is if this is normal behaivour with clusters and hardware failure, and can the time sync be the problem that is stopping the live Netapp from automatically taking over the failed Netapp. Kevin -----Original Message----- From: Coatney, Sue [mailto:Sue.Coatney@netapp.com] Sent: 21 February 2002 02:25 To: 'Daniel Jung'; toasters(a)mathworks.com Subject: RE: Upgrading firmware > Also, I've heard that you "can" upgrade disk firmware while > having both > filers ON-LINE and clustered. Is this true? Yes. With DOT 6.0.3 and 6.1.2 and later. However, the drives are unresponsive while firmware is being downloaded, which will impact client access, so caution is needed. For prior releases, you should really follow the directions of having one of the filers halted, as documented on the NOW site. Sue =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Sue Coatney Network Appliance Clustering Team > Hi Fellow toasters, > > I need to upgrade OnTap on the couple of F840s that is clustered. > According to the NOW site, it is recommended that I should bring down > both filers and do disk firmware upgrade on one while the other filer > is halted. Is this really necessary? What I planned to do was > to upgrade OnTap on one of the filers (while clustering is disabled) > first before I bring down the second one. Is this more dangerous than > what NOW site recommends? > > Also, I've heard that you "can" upgrade disk firmware while > having both > filers ON-LINE and clustered. Is this true? > > > Thanks > > Daniel Jung > > System Administrator GMO inc > ******************************************************************************************** " This message contains information that may be privileged or confidential and is the property of the Cap Gemini Ernst & Young Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message ". ********************************************************************************************

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