toasters January 2001

toasters@lists.teaparty.net

135 participants
157 discussions

RE: 72 Gig disks
by Klinkner, Steve 05 Jan '01

05 Jan '01

> -----Original Message----- > From: Thomas Heffron [mailto:theffron@wisedata.com] > 2) They are not listed in the drop down when creating a generic volume in > the GUI (at least in 5.3.6 - don't know about 6.x). This is fixed in a 6.x point release that should ship in the next few months (bug is 28306). In a future release, the pull-down will display only a list of spare sizes which actually appear on the system (which in all cases makes more sense than the canned list it currently displays). ---------------------------------------------------------------------- steve klinkner klink(a)netapp.com

1 0

72 Gig disks
by Geoff Hardin 05 Jan '01

05 Jan '01

Anyone hear anything about the status of the 72 gig disks? We're trying to plan for the upcoming year whether we want to get more disks (18's & 36's), new disks (72's), more filers, etc. A quick search of NOW didn't turn anything up. -- Geoff Hardin Dallas Semiconductor MIS UNIX geoff.hardin(a)dalsemi.com

4 3

RE: 72 Gig disks
by Kitch, David 05 Jan '01

05 Jan '01

They're available on the new systems, but they don't recommend them for performance reasons. Regards, David Kitch Texas Instruments Incorporated IS dkitch(a)ti.com -----Original Message----- From: Geoff Hardin [mailto:geoff.hardin@dalsemi.com] Sent: Friday, January 05, 2001 1:29 PM To: toasters(a)mathworks.com Subject: 72 Gig disks Anyone hear anything about the status of the 72 gig disks? We're trying to plan for the upcoming year whether we want to get more disks (18's & 36's), new disks (72's), more filers, etc. A quick search of NOW didn't turn anything up. -- Geoff Hardin Dallas Semiconductor MIS UNIX geoff.hardin(a)dalsemi.com

1 0

RE: Slooow SGI Challenge
by Fox, Adam 04 Jan '01

04 Jan '01

Personally, I'm a big fan of packet traces. They can tell you alot. In this case, you have one good performing client, and one bad one. Take a packet trace of each and compare them. What sizes are the clients requesting? What calls are they using? Is the client just not generating requests very quickly? Just some thoughts.. -- Adam Fox NetApp Professional Services, NC adamfox(a)netapp.com > -----Original Message----- > From: Link, Bill (OTS-EDH) [mailto:Bill_Link@billing.com] > Sent: Thursday, January 04, 2001 4:57 PM > To: 'toasters(a)mathworks.com' > Subject: Slooow SGI Challenge > > > > Has anyone had any experience with netapp on an SGI Challenge system? > > I have an F760 attached through a cisco 4000 switch to an sgi > challenge and > an IBM S7A. I have this arrangement on a dedicated subnet with all > interfaces set manually to 100tx. (The vme controller in the > SGI will not > abide full duplex). The netapp is running 5.3.6R1, the SGI is > running IRIX > 6.5.5, and the RS6K is running AIX4.3.3. > > The IBM will create a 128M file in under 30 sec. If I mount > the filer on the > SGI box and specify tcp it takes about 2 min 45 sec to write > the same file. > If I let the mount on the SGI default to udp it won't write > more that 15 or > 20 mb before it starts getting nfs timeouts. The filer seems > oblivious to > any trouble that the sgi is having. The sgi will work > (slowly) at 10mb half > duplex with udp. > > Any suggestions would be much appreciated. > > Bill Link > SysAdmin > Output Technology Solutions > bill_link(a)billing.com > >

1 0

RE: Slooow SGI Challenge
by Miller, James 04 Jan '01

04 Jan '01

Hi Bill: I spent 7 years field service for SGI. You have 2 problems, neither can be fixed. 1)The VME 100Mb (C8-100BT)interface turned out to be a piece of junk even before IRIX 6.5 got hold of it. The board, as you said is only half duplex, a seven year old design that never got a major rework because it's on a long time dead product line. I had several sites that were never able to exceed 65Mb simplex. 2) IRIX 6.5 has made problems and performance worse that under IRIX 6.2 For systems under SGI support, GPS would swap out the C8-100BT board for a FDDI (SAS/DAS) of their choice and Customer would use a CISCO, or alike, to run a FDDI Fibre connection into a 100Mb switch. There are some kernel parameters to tweak for this that I cannot remember for MTU. We did this for 2 customers just in the Phila area alone because of the additional problems IRIX 6.5.x created. FIX, Replace your Challenge with a O2100 and get reliable 100 & 1000Mb FDX interfaces. ... All is my humble opinion, and not that of my previous employer ..jim -----Original Message----- From: Link, Bill (OTS-EDH) [mailto:Bill_Link@billing.com] Sent: Thursday, January 04, 2001 4:57 PM To: 'toasters(a)mathworks.com' Subject: Slooow SGI Challenge Has anyone had any experience with netapp on an SGI Challenge system? I have an F760 attached through a cisco 4000 switch to an sgi challenge and an IBM S7A. I have this arrangement on a dedicated subnet with all interfaces set manually to 100tx. (The vme controller in the SGI will not abide full duplex). The netapp is running 5.3.6R1, the SGI is running IRIX 6.5.5, and the RS6K is running AIX4.3.3. The IBM will create a 128M file in under 30 sec. If I mount the filer on the SGI box and specify tcp it takes about 2 min 45 sec to write the same file. If I let the mount on the SGI default to udp it won't write more that 15 or 20 mb before it starts getting nfs timeouts. The filer seems oblivious to any trouble that the sgi is having. The sgi will work (slowly) at 10mb half duplex with udp. Any suggestions would be much appreciated. Bill Link SysAdmin Output Technology Solutions bill_link(a)billing.com

1 0

Slooow SGI Challenge
by Link, Bill (OTS-EDH) 04 Jan '01

04 Jan '01

Has anyone had any experience with netapp on an SGI Challenge system? I have an F760 attached through a cisco 4000 switch to an sgi challenge and an IBM S7A. I have this arrangement on a dedicated subnet with all interfaces set manually to 100tx. (The vme controller in the SGI will not abide full duplex). The netapp is running 5.3.6R1, the SGI is running IRIX 6.5.5, and the RS6K is running AIX4.3.3. The IBM will create a 128M file in under 30 sec. If I mount the filer on the SGI box and specify tcp it takes about 2 min 45 sec to write the same file. If I let the mount on the SGI default to udp it won't write more that 15 or 20 mb before it starts getting nfs timeouts. The filer seems oblivious to any trouble that the sgi is having. The sgi will work (slowly) at 10mb half duplex with udp. Any suggestions would be much appreciated. Bill Link SysAdmin Output Technology Solutions bill_link(a)billing.com

1 0

Dump dies around 13G bytes
by Fred Ab 04 Jan '01

04 Jan '01

I get DUMP IS ABORTED when trying to dump a 39G byte volume to a DLT 7000 drive directly connected to the NetApp. I know that it is 35G native and 70G compressed but it looks like it dies around 13G. DUMP: creating "/vol/vol1/.snapshot/snapshot_for_backup.109" snapshot. DUMP: Using Partial Volume Dump DUMP: Date of this level 0 dump: Fri Dec 22 23:05:09 2000. DUMP: Date of last level 0 dump: the epoch. DUMP: Dumping /vol/vol1/proj to /dev/nrst0a DUMP: mapping (Pass I)[regular files] DUMP: mapping (Pass II)[directories] DUMP: estimated 38916473 tape blocks on 0.97 tapes DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: We have written 1585525 KB to tape. DUMP: We have written 3465622 KB to tape. DUMP: We have written 5328897 KB to tape. DUMP: We have written 7627776 KB to tape. DUMP: We have written 10240766 KB to tape. DUMP: DUMP IS ABORTED ultra119# pwd /america/vol1/proj ultra119# df -k . Filesystem kbytes used avail capacity Mounted on america:/vol/vol1 53766696 39259976 14506720 74% /america/vol1 sysconfig -t output: nrst0a - no rewind device, format is: 85937 bpi 70 GB (w/comp) Dump Command = dump 0ubBf 63 39845869 /dev/nrst0a Any ideas why?

1 0

Gotcha on multiple network interfaces
by Brian L. Brush 04 Jan '01

04 Jan '01

If you have multiple network interfaces on your filers, this information may be useful to you. If you're thorough about reading the documentation and clever about checking your results, you may have discovered it for yourself. While testing our new F760 cluster, we have discovered that if the filer has two interfaces on the same subnet and the default gateway resides on that subnet, the default route in the filer's routing table will choose the interface with the lower number. In particular, using the "setup" command, we configured an F760 with on-board 100Mbps e0 and GigE e7 on the same subnet. Using "netstat -r", we determined that the default route was using e0, which was not what we wanted--the 100Mbps was intended to be a backup link, not for regular production use: pow> netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Interface default 135.90.100.254 UG 1 61 e0 127 localhost UG 1 9 lo localhost localhost UH 1 0 lo 135.90.100/24 link#1 UC 0 0 e0 135.90.100.254 0:50:50:3f:18:1f UHL 1 0 e0 135.90.100.255 link#1 UHL 1 46 e0 After some experimentation, we settled on editing /etc/rc to configure e0 after both configuring e7 and adding the default route; we also turned off routed: #Auto-generated by setup Wed Dec 20 19:16:53 GMT 2000 hostname pow ifconfig e7 `hostname`-e7 flowcontrol full netmask 255.255.255.0 route add default 135.90.100.254 1 ifconfig e0 `hostname`-e0 mediatype auto netmask 255.255.255.0 #routed on options dns.domainname is.paradyne.com options dns.enable on options nis.domainname is.paradyne.com options nis.enable on savecore exportfs -a nfs on Now we have the results we wanted; all outbound packets should use the gig link, according to netstat: pow> netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Interface default 135.90.100.254 UG 5 2148 e7 127 localhost UG 1 261 lo localhost localhost UH 1 0 lo 135.90.100/24 link#2 UC 0 0 e7 135.90.100.254 0:50:50:3f:18:1f UHL 1 0 e7 135.90.100.255 link#2 UHL 1 1794 e7 Looking at the systems we had in production, we realized that, as a result of this oversight, they had been sending all outbound traffic via their fast ethernet interfaces rather than gig! Aaargh! --Brian L. Brush Senior Systems Administrator Paradyne Corporation

1 1

Re: Gotcha on multiple network interfaces
by svawter＠c-cube.com 04 Jan '01

04 Jan '01

What you should use for a failover link is create a vif in single mode with e7 & e0, favoring e7. vif create single f0 e7 e0 vif favor e7 ifconfig f0 hostname flowcontrol full netmask 255.255.255.0 or perhaps: vif create single f0 e7 ifconfig f0 hostname flowcontrol full netmask 255.255.255.0 vif favor e7 vif add f0 e0 Steve Vawter voice: 408-490-5310 fax: 408-490-8615 Staff UNIX Systems Administrator Steve.Vawter(a)C-Cube.COM --> --> From brian(a)paradyne.com Thu Jan 4 09:56:51 2001 --> From: "Brian L. Brush" <brian(a)paradyne.com> --> X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.8 sun4u) --> To: toasters(a)mathworks.com --> Subject: Gotcha on multiple network interfaces --> --> --> If you have multiple network interfaces on your filers, this information --> may be useful to you. If you're thorough about reading the documentation --> and clever about checking your results, you may have discovered it for --> yourself. --> --> While testing our new F760 cluster, we have discovered that if the filer --> has two interfaces on the same subnet and the default gateway resides on --> that subnet, the default route in the filer's routing table will choose --> the interface with the lower number. --> --> In particular, using the "setup" command, we configured an F760 with --> on-board 100Mbps e0 and GigE e7 on the same subnet. Using "netstat -r", --> we determined that the default route was using e0, which was not what we --> wanted--the 100Mbps was intended to be a backup link, not for regular --> production use: --> --> pow> netstat -r --> Routing tables --> --> Internet: --> Destination Gateway Flags Refs Use Interface --> default 135.90.100.254 UG 1 61 e0 --> 127 localhost UG 1 9 lo --> localhost localhost UH 1 0 lo --> 135.90.100/24 link#1 UC 0 0 e0 --> 135.90.100.254 0:50:50:3f:18:1f UHL 1 0 e0 --> 135.90.100.255 link#1 UHL 1 46 e0 --> --> After some experimentation, we settled on editing /etc/rc to configure --> e0 after both configuring e7 and adding the default route; we also --> turned off routed: --> --> #Auto-generated by setup Wed Dec 20 19:16:53 GMT 2000 --> hostname pow --> ifconfig e7 `hostname`-e7 flowcontrol full netmask 255.255.255.0 --> route add default 135.90.100.254 1 --> ifconfig e0 `hostname`-e0 mediatype auto netmask 255.255.255.0 --> #routed on --> options dns.domainname is.paradyne.com --> options dns.enable on --> options nis.domainname is.paradyne.com --> options nis.enable on --> savecore --> exportfs -a --> nfs on --> --> Now we have the results we wanted; all outbound packets should use the --> gig link, according to netstat: --> --> pow> netstat -r --> Routing tables --> --> Internet: --> Destination Gateway Flags Refs Use Interface --> default 135.90.100.254 UG 5 2148 e7 --> 127 localhost UG 1 261 lo --> localhost localhost UH 1 0 lo --> 135.90.100/24 link#2 UC 0 0 e7 --> 135.90.100.254 0:50:50:3f:18:1f UHL 1 0 e7 --> 135.90.100.255 link#2 UHL 1 1794 e7 --> --> Looking at the systems we had in production, we realized that, as a --> result of this oversight, they had been sending all outbound traffic via --> their fast ethernet interfaces rather than gig! Aaargh! --> --> --Brian L. Brush --> Senior Systems Administrator --> Paradyne Corporation -->

1 0

RE: Gotcha on multiple network interfaces
by Premanshu Jain 04 Jan '01

04 Jan '01

Yes..I also observed the same problem and finally disabled the e0 interface. prem -----Original Message----- From: Brian L. Brush [mailto:brian@paradyne.com] Sent: Thursday, January 04, 2001 7:20 AM To: toasters(a)mathworks.com Subject: Gotcha on multiple network interfaces If you have multiple network interfaces on your filers, this information may be useful to you. If you're thorough about reading the documentation and clever about checking your results, you may have discovered it for yourself. While testing our new F760 cluster, we have discovered that if the filer has two interfaces on the same subnet and the default gateway resides on that subnet, the default route in the filer's routing table will choose the interface with the lower number. In particular, using the "setup" command, we configured an F760 with on-board 100Mbps e0 and GigE e7 on the same subnet. Using "netstat -r", we determined that the default route was using e0, which was not what we wanted--the 100Mbps was intended to be a backup link, not for regular production use: pow> netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Interface default 135.90.100.254 UG 1 61 e0 127 localhost UG 1 9 lo localhost localhost UH 1 0 lo 135.90.100/24 link#1 UC 0 0 e0 135.90.100.254 0:50:50:3f:18:1f UHL 1 0 e0 135.90.100.255 link#1 UHL 1 46 e0 After some experimentation, we settled on editing /etc/rc to configure e0 after both configuring e7 and adding the default route; we also turned off routed: #Auto-generated by setup Wed Dec 20 19:16:53 GMT 2000 hostname pow ifconfig e7 `hostname`-e7 flowcontrol full netmask 255.255.255.0 route add default 135.90.100.254 1 ifconfig e0 `hostname`-e0 mediatype auto netmask 255.255.255.0 #routed on options dns.domainname is.paradyne.com options dns.enable on options nis.domainname is.paradyne.com options nis.enable on savecore exportfs -a nfs on Now we have the results we wanted; all outbound packets should use the gig link, according to netstat: pow> netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Interface default 135.90.100.254 UG 5 2148 e7 127 localhost UG 1 261 lo localhost localhost UH 1 0 lo 135.90.100/24 link#2 UC 0 0 e7 135.90.100.254 0:50:50:3f:18:1f UHL 1 0 e7 135.90.100.255 link#2 UHL 1 1794 e7 Looking at the systems we had in production, we realized that, as a result of this oversight, they had been sending all outbound traffic via their fast ethernet interfaces rather than gig! Aaargh! --Brian L. Brush Senior Systems Administrator Paradyne Corporation

1 0

Jump to page:

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 January 2001