toasters

toasters@lists.teaparty.net

13531 discussions

RE: disk_fw_update issue with 840-5.3.7R2
by Witham, John 08 Jan '01

08 Jan '01

I may be wrong, but here's the scenario I envision when you're talking about this: a) Disk Fails b) RMA c) New disk arrives, with old firmware. d) Disk added as HotSpare - DOWNREV DISKS PRESENT! error abounds. At this point, the new drive is a hotspare. If it's the only downrev disk, you could safely do a disk_fw_update, and it would take just the hotspare offline and upgrade it. I would be on the safe side and specify the disk to upgrade, but all in all, the Filer is still alive and serving data. The key phrase below is "It involves spinning down and then spinning up all AFFECTED disks". -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: Tom "Mad Dog" Yergeau [mailto:MadDog@fool.com] Sent: Monday, January 08, 2001 10:39 AM To: 'Krause, Oliver'; 'toasters(a)mathworks.com' Subject: RE: disk_fw_update issue with 840-5.3.7R2 Just upgrading one disk still takes downtime for the whole system. The filer may be up, but if I can't access my data, effectively, it's down. "Downloading disk firmware can be disruptive to the system. It involves spinning down and then spinning up all affected disks, and suspending all disk I/O to all disks while that is happening. This may take up to 2 minutes to complete. This delay may cause clients to hang, and may cause CIFS clients to drop sessions." It should be noted that this notice can be misleading. It actually takes up to two minutes PER TYPE OF DISK to complete a disk_fw_update. So if you have two models of 18 GB drives and two models of 36 GB drives, if can take up to eight minutes to flash the firmware. Been there, done that. Was a little surprised the first time. :) Since replacement disks often ship with firmware different than the level currently being used on a filer, it would be nice if (a) NetApp checked autosupport logs and pre-flashed the firmware for you before sending you the disk (b) You could flash a single disk w/o disrupting all I/O for the entire filer. Especially if the disk is marked as a spare and therefore not part of any volume. If NetApp wanted to get *really* ambitious (I dunno, for ONTAP 6.5 or something), this would be wild: flash firmware on a volume one disk at a time, and keep the volume online. While each disk is being flashed, use the parity disk to serve data, and keep track of writes somewhere to get the flashed disk back up to synch when the flash is done. It's too bad NetApp doesn't offer mirroring, since if you had mirrored sets this would be a real piece of cake. Just flash half a mirror while the other half served data. Online disk_fw_update would be a big help in five 9s environments. MD -----Original Message----- From: Krause, Oliver [mailto:OKrause@netapp.com] Sent: Saturday, January 06, 2001 5:56 AM To: 'Premanshu Jain'; 'toasters(a)mathworks.com' Subject: RE: disk_fw_update issue with 840-5.3.7R2 You can specify which disk to upgrade. Try disk_fw_update <diskname> This works while the system is running. Oliver > -----Original Message----- > From: Premanshu Jain [mailto:PrJain@shastanets.com] > Sent: Freitag, 5. Januar 2001 23:31 > To: 'toasters(a)mathworks.com' > Subject: disk_fw_update issue with 840-5.3.7R2 > > > I have a 840 cluster. Whenever I add new disks, the cluster > starts throwing > 'doenrev disk firmware' error messages. NetApps suggests doing a > disk_fw_update on the disk and strictly says "NO need to Halt > a filer'. > Reality is totally different. The command specifically asks > you wether the > cluster partner is on Halt-OK prompt or not? > > The workaround I am doing, intitiate a takeover and do the > disk_fw_update. > However, this still needs to do a takeover/giveback and 2 minutes of > downtime...Adding/replacing bad disks is a regular activity... > > Any suggestions..? >

1 0

HSM
by SteveRoche＠datalink.com 08 Jan '01

08 Jan '01

Hello everyone! We are considering implementing an F840 with around 4TB into a mixed UNIX and Win2K environment. My question to this much respected community is can we implement an HSM solution like say Veritas Storage Replicator to extract stale files and put them out to tape with a Netapp? I have been told know but am hoping yes. Thanks in advance Steve Roche sroche(a)datalink.com

1 0

RE: disk_fw_update issue with 840-5.3.7R2
by Tom "Mad Dog" Yergeau 08 Jan '01

08 Jan '01

SnapMirror wouldn't work for what I've suggested as it is read-only asynch. A read/write synchronous mirror (i.e. RAID 4+1) would be required for what I suggested. Also, to avoid disruption to the client systems, the CIFS share name or NFS export could not be changed during the fw_update, so it would have to be the same set of data and not a snapmirror. Thus even a synchronous snapmirror wouldn't work, unless you could make the snapmirror read/write, re-direct clients to the mirror on the fly without breaking the TCP session, and then reverse-synch once the disk_fw_update was done and put the clients back on the original disks. That'd be quite a trick! Think 99.999% uptime, no disruption to clients for *ANYTHING*. Or at least nothing as common and (relatively) trivial as a firmware update. I'd still say NetApp should look at ASUP logs and pre-flash replacement disks to the level appropriate for your ONTAP version before shipping them to you. That's probably a lot easier to do in the short term than my ambitious on-the-fly firmware update suggestion. :) Hey--here's a technical question. SCSI RAID systems allow you to update the firmware on one disk without disruption I/O to the other disks. Is this possible on an FCAL loop? Or is the whole idea technically infeasible due to limitations in FCAL? MD -----Original Message----- From: Bruce Sterling Woodcock [mailto:sirbruce@ix.netcom.com] Sent: Monday, January 08, 2001 2:21 PM To: Tom "Mad Dog" Yergeau; 'Krause, Oliver'; toasters(a)mathworks.com Subject: Re: disk_fw_update issue with 840-5.3.7R2 > It's too bad NetApp doesn't offer mirroring, since if you had mirrored sets > this would be a real piece of cake. Just flash half a mirror while the > other half served data. Have you heard of something called SnapMirror? Bruce

1 0

RE: disk_fw_update issue with 840-5.3.7R2
by Tom "Mad Dog" Yergeau 08 Jan '01

08 Jan '01

Just upgrading one disk still takes downtime for the whole system. The filer may be up, but if I can't access my data, effectively, it's down. "Downloading disk firmware can be disruptive to the system. It involves spinning down and then spinning up all affected disks, and suspending all disk I/O to all disks while that is happening. This may take up to 2 minutes to complete. This delay may cause clients to hang, and may cause CIFS clients to drop sessions." It should be noted that this notice can be misleading. It actually takes up to two minutes PER TYPE OF DISK to complete a disk_fw_update. So if you have two models of 18 GB drives and two models of 36 GB drives, if can take up to eight minutes to flash the firmware. Been there, done that. Was a little surprised the first time. :) Since replacement disks often ship with firmware different than the level currently being used on a filer, it would be nice if (a) NetApp checked autosupport logs and pre-flashed the firmware for you before sending you the disk (b) You could flash a single disk w/o disrupting all I/O for the entire filer. Especially if the disk is marked as a spare and therefore not part of any volume. If NetApp wanted to get *really* ambitious (I dunno, for ONTAP 6.5 or something), this would be wild: flash firmware on a volume one disk at a time, and keep the volume online. While each disk is being flashed, use the parity disk to serve data, and keep track of writes somewhere to get the flashed disk back up to synch when the flash is done. It's too bad NetApp doesn't offer mirroring, since if you had mirrored sets this would be a real piece of cake. Just flash half a mirror while the other half served data. Online disk_fw_update would be a big help in five 9s environments. MD -----Original Message----- From: Krause, Oliver [mailto:OKrause@netapp.com] Sent: Saturday, January 06, 2001 5:56 AM To: 'Premanshu Jain'; 'toasters(a)mathworks.com' Subject: RE: disk_fw_update issue with 840-5.3.7R2 You can specify which disk to upgrade. Try disk_fw_update <diskname> This works while the system is running. Oliver > -----Original Message----- > From: Premanshu Jain [mailto:PrJain@shastanets.com] > Sent: Freitag, 5. Januar 2001 23:31 > To: 'toasters(a)mathworks.com' > Subject: disk_fw_update issue with 840-5.3.7R2 > > > I have a 840 cluster. Whenever I add new disks, the cluster > starts throwing > 'doenrev disk firmware' error messages. NetApps suggests doing a > disk_fw_update on the disk and strictly says "NO need to Halt > a filer'. > Reality is totally different. The command specifically asks > you wether the > cluster partner is on Halt-OK prompt or not? > > The workaround I am doing, intitiate a takeover and do the > disk_fw_update. > However, this still needs to do a takeover/giveback and 2 minutes of > downtime...Adding/replacing bad disks is a regular activity... > > Any suggestions..? >

2 1

Preposterous date/time stamp
by Thomas.L.White＠chase.com 08 Jan '01

08 Jan '01

I seem to recall reading about this on the list - but could not find any related emails. Does anyone know of a bug and or fix for the date stamp on files/directories on the filer showing up as 20 to 30 years in the future ? The users are still being migrated to the filers from their old Novell or NT "homes" so this may even be due to "copy method" I'm not sure at this point We have not managed to replicate the error on "command". thanks tw

1 0

RE: 72 Gig disks
by Mohler, Jeff 08 Jan '01

08 Jan '01

Like anything else, the sizing you are looking at for HDs can affect performance depending on what your application and read/write requirements/habits are. Its inaccurate to state "performance problems" as a global issue as "performance" means different things to different customers. Consult with your salesperson and thier SE..they will be glad to help you make the best decision to match your specific environment, or follow this thread..im sure we'll get into a healthy debate on this. *grin* Cheers!

3 4

disk_fw_update issue with 840-5.3.7R2
by Premanshu Jain 07 Jan '01

07 Jan '01

I have a 840 cluster. Whenever I add new disks, the cluster starts throwing 'doenrev disk firmware' error messages. NetApps suggests doing a disk_fw_update on the disk and strictly says "NO need to Halt a filer'. Reality is totally different. The command specifically asks you wether the cluster partner is on Halt-OK prompt or not? The workaround I am doing, intitiate a takeover and do the disk_fw_update. However, this still needs to do a takeover/giveback and 2 minutes of downtime...Adding/replacing bad disks is a regular activity... Any suggestions..?

3 2

RE: disk_fw_update issue with 840-5.3.7R2
by Krause, Oliver 06 Jan '01

06 Jan '01

You can specify which disk to upgrade. Try disk_fw_update <diskname> This works while the system is running. Oliver > -----Original Message----- > From: Premanshu Jain [mailto:PrJain@shastanets.com] > Sent: Freitag, 5. Januar 2001 23:31 > To: 'toasters(a)mathworks.com' > Subject: disk_fw_update issue with 840-5.3.7R2 > > > I have a 840 cluster. Whenever I add new disks, the cluster > starts throwing > 'doenrev disk firmware' error messages. NetApps suggests doing a > disk_fw_update on the disk and strictly says "NO need to Halt > a filer'. > Reality is totally different. The command specifically asks > you wether the > cluster partner is on Halt-OK prompt or not? > > The workaround I am doing, intitiate a takeover and do the > disk_fw_update. > However, this still needs to do a takeover/giveback and 2 minutes of > downtime...Adding/replacing bad disks is a regular activity... > > Any suggestions..? >

1 0

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

RE: Sun photon (fcal) disks on toaster?
by Traitel, Eyal 04 Jan '01

04 Jan '01

Games like this could be fun indeed, but I doubt if our code supports them... Anyway - you can always try to boot a regular PC with our Intel platform floppies... :) Eyal. ---------------------------------------------------------------------- eTraitel - I'm the new eBuzzword around !!! ---------------------------------------------------------------------- Eyal Traitel - Filer Escalation Engineer CNA, MCSE, CSA, NACA Network Appliance BV Holland Office Center Kruisweg 799b 2132 NG, Hoofddorp The Netherlands Office: +31 23 567 9685 Cellular: +31 6 5497 2568 Email: eyal(a)netapp.com ---------------------------------------------------------------------- Get answers NOW! - NetApp On the Web - http://now.netapp.com ---------------------------------------------------------------------- -----Original Message----- From: Jason S. Cash [mailto:cash@udel.edu] Sent: Thursday, January 04, 2001 2:48 PM To: toasters(a)mathworks.com Subject: Sun photon (fcal) disks on toaster? Has anyone successfully hooked Sun photon disk arrays to a netapp? I have a bunch of these sitting around at the moment a f740 that it might be amusing to see how fast they can go (if at all). Management might be willing to buy us some 840s to act as heads for these arrays if it will work :) TIA, Jason /* Jason S. Cash - Systems Programmer IT/Network and Systems Services University of Delaware, Newark Delaware */

1 0

Sun photon (fcal) disks on toaster?
by Jason S. Cash 04 Jan '01

04 Jan '01

Has anyone successfully hooked Sun photon disk arrays to a netapp? I have a bunch of these sitting around at the moment a f740 that it might be amusing to see how fast they can go (if at all). Management might be willing to buy us some 840s to act as heads for these arrays if it will work :) TIA, Jason /* Jason S. Cash - Systems Programmer IT/Network and Systems Services University of Delaware, Newark Delaware */

1 0

Filer + Netscape Messaging Server
by Brian L. Brush 03 Jan '01

03 Jan '01

We are considering using a filer to provide the message stores for our Netscape (soon to be iPlanet) Messaging Server. Of course, neither Netscape (iPlanet) nor NetApp supports such a configuration. Can anyone offer relevant insight or experience? For a couple of years we have been using a similarly unsupported configuration to provide storage space for Rational ClearCase. While we've had no insuperable problems, I don't relish the prospect of hitting a brick wall on those rare occasions when we request support--for the application, not the configuration. --Brian L. Brush Senior Systems Administrator Paradyne Corporation

1 0

Re: Bad Solaris performance over time
by hill＠communitytelephone.com 03 Jan '01

03 Jan '01

On Tue, 2 Jan 2001, Chris Lamb wrote: ->One box handled incoming SMTP and all local delivery (sendmail+procmail) ->and POP, the other handled some unholy number of Majordomo lists. I mean, ->this was with hardware that nowadays people scoff at, running ancient ->software releases and NFS V2 over a single network interface. I find it ->impossible to believe that a 4-way UltraII and an F760 can't handle the ->load. (Yeah, the average mail message with all the crap "modern" mailers ->add on is probably several Kb larger, but that's almost never the real ->bottleneck.) That was supposed to be part of my point, the machine we have can more the adequetly handle the load. :) The stats http://static-content-01.communitytelephone.net/~hill/server_stats show that the machine doesn't breathe hard all day long. It seems that something happens over time and at some point hits critical mass, which causes the performance to become very bad. -> ->Some questions that may be a bit obvious: Is your 2.6 box patched to ->current levels? Yes. Patch revisions are posted at the above URL. ->Why NFS V2? This was a typo, it is really V3. ->How much NVRAM in the filer? 32Mb. The filer weekly_log is at the above URL. ->Is the network bogged down, or the switch misconfigured? We see no errors on the switch, or the servers network interfaces. ->How many network interfaces, of what type/speed? Filer has a Gigabit interface. Solaris servers has 100Mb. You can see the throughput information at the above URL file: nx.se. ->What does snoop/tcpdump/your network sniffer say? I haven't tried this yet. It looked like there was going to be way too much information to sort through. I will gather it the next time the system begins to act up. ->How many disks in the volume that contains /var/mail? 14 ->Is this filer running CIFS & NFS, or is it purely an NFS box? NFS only ->If /var/mail is on the filer, what about home directories (i.e., is ->your mailer bogging doing ".forward" lookups)? home directories are on the netapp as well. Again I must state it is not a general performance problem, but something that happens over time. -> Are you using NIS and/or DNS on the filer? No. ->What version of sendmail/qmail/whatever? Latest smail. ->Are you using procmail for delivery? Why not? :-) Yes. ->Is disk scrubbing kicking in? Are you taking snapshots too frequently? ->Do you have cron jobs walking the filesystem or other network clients ->hitting the filer or the network when these slowdowns are observed on ->the ->mail server? And really, why NFS V2? I appreciate what you are getting at here, but I don't believe that sort of thing is happening. It you look at the stats for the filer the performance of it stays stable through the trouble period with the one server. Also, all other servers continue to perform well. I believe the server stats show that things like these aren't occuring as well. We are using V3 mounts I typo'd my earlier email. ->(I'm not really a smartass, I just play one on the Internet. :-) These ->are just some of the questions I'd look to answer before poking at ->/etc/system. We did do that. We feel stronghly that there is a bug in Solaris or in the interaction between it and the netapp which cause our performance problems to occur. We tried to massage /etc/system parameters to keep from occuring. Again, I must point out our server ran great when we have /var/mail on local storage. We only began to see this problem after moving it to the filer and only after 24 - 30 hours of operation. I have found a bug ID on sunsolve that described similarities to our problem, but we already have the patch that was supposed to fix that bug. I include it here so you can get a feel for the actual problem from someone elses perspective. Even though our problem is not an exact match we do have similarities with it. We also have similarities to a posting on toasters Date: Tue, 10 Aug 1999 08:05:18 -0700 (PDT) From: Nick Christenson <npc(a)sendmail.com> To: toasters(a)mathworks.com Subject: NFS client tuning, problem and resolution. ------------------------ Sun Bug ID 4034003 --------------------------- Some time ago I got email from someone on a system w/ 37,000 users who had problem using mail from it's mailserver, both CPU were very busy and the system had slowed to a crawl at peak times. The systems gets +/- 70K sendmail calls, 130K pop3 calls a day, mail lives ona NFSv3 capable network appliance server. Mail is delivered to the home directories, not to /var/mail. He ran kernel profiling and found crcmp() topping the list: granularity: each sample hit covers 2 byte(s) for 0.12% of 8.65 seconds % cumulative self self total time seconds seconds calls ms/call ms/call name 39.2 3.39 3.39 crcmp [1] 2.8 3.63 0.24 locked_pgcopy [2] 2.5 3.85 0.22 splx [3] 1.8 4.01 0.16 bcopy [4] 1.7 4.16 0.15 mutex_enter [5] 1.7 4.31 0.15 disp_getwork [6] 1.6 4.45 0.14 dnlc_purge_vp [7] 1.5 4.58 0.13 nfs3_access [8] 1.5 4.71 0.13 ross625_vac_segflush [9] 1.3 4.82 0.11 blkclr [10] 1.3 4.93 0.11 idle [11] 1.0 5.02 0.09 mutex_adaptive_enter [12] While the information is not complete, here's what I think happens, all users access the same rnode ("/export/home", mail is delivered to the home directies) a large access cache is built and here's where we serialize:, in nfs3_access() : [common/fs/nfs/nfs3_vnops.c] ........ mutex_enter(&rp->r_statelock); for (acp = rp->r_acc; acp != NULL; acp = acp->next) { /* * Look for an entry by comparing credentials. */ if (crcmp(acp->cred, cr) == 0) { if ((acp->known & acc) == acc) { #ifdef DEBUG nfs3_access_cache_hits++; #endif if ((acp->allowed & acc) == acc) { mutex_exit(&rp->r_statelock); return (0); } mutex_exit(&rp->r_statelock); return (EACCES); } break; } } mutex_exit(&rp->r_statelock); And further down, if we have a cache miss, we do the same all over again. (As we unlock, we need to recheck whether a new entry was added, so the list is rechecked, again holding the r_statelock) Now, that algorithm works fine in the typical case where users access their own files; or whena few users do. It does *not* work when you have 37K users accessing a single file. As long as the node is cached and the kernel doesn't reap kernel memory, the list will grow out of bounds and access to this node will get increasingly slow. This theory was tested by switching to NFSv2 mounts. This fixed the problem. Attached is a program that shows the behaviour somewhat. It calls "access()" on a file (specified on the command line) as many different users. The file must exist on a NFSv3 filesystem, the program must be run as root and the file must be openable as root on the client. One sample run printed this: 0 18860 500 5680 1000 4798 1500 3963 2000 3071 2500 2425 3000 1552 3500 863 and this tells that after running access(file, F_OK) as 4000 different uids, there's a really high penalty for the first users that called access. In this case for uid(0) searching the cache costs 18ms. It seems that this cache should not be allowed to grow out of bounds, currently it's ownly limited by kernel memory. -Work Around- Use NFSv2 mounts on filesystems that are used by lots of users such as "/var/mail". michael.eisler@Eng 1997-02-24 The above aork around is fine as long as the server is not a Solaris 2.5[.1] or 2.6 system. Since the ACL protocol has an ACCESS procedure for NFS V2, a Solaris 2.5 or alter system will also use the ACL cache system. ---------------------- End Sun Bug ID 4034003 ------------------------- We did try using V2 mounts as a test, and we still experienced the problem. --Jamie Hill -> ->-- Chris -> ->-- ->Chris Lamb, Unix Guy ->MeasureCast, Inc. ->503-241-1469 x247 -><skeezics(a)measurecast.com> -> ->

1 0

Problem to integrate F740 into a Windows 2000 domain (2)
by benny.wistrom＠cn.saab.se 03 Jan '01

03 Jan '01

Hi again! I have tried once again and I get the following messages when I try to integrate my filer into a Windows 2000 domain. CIFS server is beginning domain installation. CIFS server is locating PDC. Wed Jan 3 12:03:31 GMT [rc]: Connection with DC \\ZAMIRA established Wed Jan 3 12:03:31 GMT [rc]: Connection with DC \\ZAMIRA terminated Wed Jan 3 12:03:31 GMT [rc]: CIFS - Filer retrying authentication with backup password. Wed Jan 3 12:03:33 GMT [rc]: Connection with DC \\ZAMIRA established Wed Jan 3 12:03:33 GMT [rc]: Connection with DC \\ZAMIRA terminated Wed Jan 3 12:03:33 GMT [rc]: CIFS - Filer retrying installation. Wed Jan 3 12:03:35 GMT [rc]: Connection with DC \\ZAMIRA established CIFS could not start. See log. CIFS local server is shutting down... Wed Jan 3 12:03:35 GMT [rc]: Connection with DC \\ZAMIRA terminated zam> Wed Jan 3 12:03:35 GMT [rc]: CIFS - Filer's security information differs from domain controller. Wed Jan 3 12:03:36 GMT [nbns_timer]: All CIFS name registrations complete for local server What does the message "CIFS - Filer's security information differs from domain controller." mean? Any suggestions? -- Regards: Benny Wiström CSC Phone: +46 13 4653647 Systemadministrator 581 88 Linköping Fax: +46 13 185771 Benny.Wistrom(a)cn.saab.se Sweden Mobile: +46 13 4653647 Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. -Calvin & Hobbes (Bill Watterson) Talk sense to a fool and he calls you foolish. -- Euripides

2 1

RE: NFS server timeouts on the clients- on new 840's
by Fox, Adam 03 Jan '01

03 Jan '01

After checking the duplex settings (and that can't be stressed enough), you may also want to check the the rsize and wsize of your NFS connections. There was a change right around 5.3.5 (I believe) that changed the default rsize and wsize on the server from 8192 to 32768. Some networks have trouble with the larger transaction sizes and it causes timeouts. A way to test this would be to do an NFS mount from your sun with the mount options rsize=8192,wsize=8192. If this helps, then that's probably your issue. You can then tell the filer to change the size on the server side with options nfs.udp.xfersize This info can be found at: http://now.netapp.com/Knowledgebase/solutionarea.asp?id=ba668eb2-9bbd-11d4-9 2f7-080020c8339b&resource=&number=5&isExternal=0 Just another thing to check. -- Adam Fox NetApp Professional Services, NC adamfox(a)netapp.com > -----Original Message----- > From: Krause, Oliver [mailto:OKrause@netapp.com] > Sent: Wednesday, January 03, 2001 6:07 AM > To: 'Premanshu Jain'; Smith, (CS) Michael > Cc: 'arr(a)oceanwave.com'; 'toasters(a)mathworks.com' > Subject: RE: NFS server timeouts on the clients- on new 840's > > > Looks like a common half-/full-duplex mismatch. Check your > network. On the > filer check your interface with ifstat <interface> and look > for CRC errors. > Always run your filer AND switchport in 100b-tx (not auto). > Sometimes this > connection is done right and people forget to check between > the switch and > the client ... > > Oliver > > > -----Original Message----- > > From: Premanshu Jain [mailto:PrJain@shastanets.com] > > Sent: Mittwoch, 3. Januar 2001 05:15 > > To: 'Mike Smith' > > Cc: 'arr(a)oceanwave.com'; 'toasters(a)mathworks.com' > > Subject: NFS server timeouts on the clients- on new 840's > > > > > > Hi mike, > > I just migrated from 740 to 840 and face this problem on the > > two Sun ultra > > 4500 NFS clients. Here are the error messages... > > _________________________________ > > 19:48:01 mthood last message repeated 10 times > > Jan 2 19:49:29 mthood unix: NFS server filebot not > > responding still trying > > Jan 2 19:49:29 mthood unix: NFS server filebot ok > > Jan 2 20:01:43 mthood xntpd[184]: time reset (step) 0.133869 s > > Jan 2 20:02:46 mthood unix: NFS server filebot not > > responding still trying > > Jan 2 20:02:46 mthood unix: NFS server filebot ok > > Jan 2 20:05:49 mthood automountd[135]: > > filebot:/vol/sw/.view.dat: No such > > file or directory > > Jan 2 20:05:49 mthood last message repeated 1 time > > Jan 2 20:07:42 mthood unix: NFS server filebot not > > responding still trying > > Jan 2 20:07:42 mthood unix: NFS server filebot ok > > Jan 2 20:08:42 mthood unix: NFS server filebot not > > responding still trying > > Jan 2 20:08:42 mthood unix: NFS server filebot ok > > _______________________ > > Can you bail me out of this issues. Both Sun systems are now running > > very-very slow . > > Thanks > > prem > > > > -----Original Message----- > > From: Mike Smith [mailto:mikesmit@netapp.com] > > Sent: Sunday, December 31, 2000 4:15 PM > > To: arr(a)oceanwave.com; toasters(a)mathworks.com > > Subject: Re: NFS server timeouts on the clients > > > > > > Based upon the description there is no way to tell exactly > > what the problem is. First off if you are using 10baseT > > then the 2M transfer will take 2 seconds. If you are using > > 100baseT (full duplex) then it will take 0.2 seconds. > > > > If you are using 10baseT then the transfer time is correct. > > If you are using 100baseT (full duplex) then I would take > > a look at the duplex settings on the filer side and then the > > switch side. If either side is not set exactly as the other side > > then it is possible you have a duplex mismatch. In which case > > I would simply manually set the port that the filer is connected > > to to full duplex. Then set the filer to full duplex manually: > > > > ifconfig e0 mediatype 100tx-fd > > > > Try the transfer again. You should see favorable results. > > Note: sometimes autonegotiation works ok but for the most > > part a lot of us stick to using manually set 100tx-fd on both the > > switch side and the filer side. Hope that helps. > > If not you might try contacting NetApp customer support and opening > > a case > > > > Mike Smith > > NetApp Escalations Engineer. > > mikesmit(a)netapp.com > > > > ----- Original Message ----- > > From: <arr(a)oceanwave.com> > > To: <toasters(a)mathworks.com> > > Sent: Sunday, December 31, 2000 3:10 PM > > Subject: NFS server timeouts on the clients > > > > > > > I have an brand new F720 running 5.3.6R2. We're exporting > > two qtrees via > > NFS > > > and CIFS. When the system is almost completely quiet, I > > try to tar up > > about > > > 2M of stuff and it takes FIVE minutes. I also see NFS > > timeout errors on > > all > > > NFS clients (the one I'm doing the tar from is specifically > > solaris 8, but > > I > > > see the timeouts on linux as well). > > > > > > I've tried NFS v2 and v3, both TCP and UDP, and nothing > > seems to help. > > netstat > > > doesn't seem to show packet collisions (the netowrk > > ispretty much dead), > > not a > > > lot of errors (<10%). I'm seeing writes about every 10 > > seconds (which > > should > > > mean good performance), and the CPU is mostly idle. Why > > the hell does a > > tar > > > of 2M take so bloody long? I can understand if I was > > moving a gig or so, > > but > > > 2M?! > > > > > > I've included important info (this was after I had changed > > to v2 UDP). Is > > > there something else I should look at? > > > > > > > > > >nfsstat -c > > > > > > Server rpc: > > > TCP: > > > calls badcalls nullrecv badlen xdrcall > > > 0 0 0 0 0 > > > > > > UDP: > > > calls badcalls nullrecv badlen xdrcall > > > 1354 0 0 0 0 > > > > > > Server nfs: > > > calls badcalls > > > 1306 0 > > > > > > Server nfs V2: (1306 calls) > > > null getattr setattr root lookup > > readlink read > > > 1 0% 372 28% 2 0% 0 0% 194 15% 0 0% > > 293 22% > > > wrcache write create remove rename link > > symlink > > > 0 0% 440 34% 2 0% 1 0% 0 0% 0 0% > > 0 0% > > > mkdir rmdir readdir statfs > > > 0 0% 0 0% 1 0% 0 0% > > > > > > Server nfs V3: (0 calls) > > > null getattr setattr lookup access > > readlink read > > > 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% > > 0 0% > > > write create mkdir symlink mknod > > remove rmdir > > > 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% > > 0 0% > > > rename link readdir readdir+ fsstat > > fsinfo pathconf > > > 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% > > 0 0% > > > commit > > > 0 0% > > > > > > NFS V2 non-blocking request statistics: > > > null getattr setattr root lookup > > readlink read > > > 1 100% 372 100% 2 100% 0 0% 194 100% 0 0% > > 141 48% > > > wrcache write create remove rename link > > symlink > > > 0 0% 440 100% 1 50% 1 100% 0 0% 0 0% > > 0 0% > > > mkdir rmdir readdir statfs > > > 0 0% 0 0% 1 100% 0 0% > > > > > > NFS V3 non-blocking request statistics: > > > null getattr setattr lookup access > > readlink read > > > 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% > > 0 0% > > > write create mkdir symlink mknod > > remove rmdir > > > 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% > > 0 0% > > > rename link readdir readdir+ fsstat > > fsinfo pathconf > > > 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% > > 0 0% > > > > > > NFS reply cache statistics: > > > TCP: > > > In progress Delay hits Misses Idempotent > > Non-idempotent > > > 0 0 0 0 0 > > > UDP: > > > In progress Delay hits Misses Idempotent > > Non-idempotent > > > 0 5 732 7 42 > > > > > > > > > >sysstat 1 > > > > > > CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s > > Cache > > > in out read write > read write > > age > > > 2% 0 0 0 0 0 0 0 > 0 0 > > 19 > > > 3% 1 0 0 0 1 0 0 > 0 0 > > 19 > > > 2% 0 0 0 0 0 0 0 > 0 0 > > 19 > > > 3% 32 0 0 5 3 0 0 > 0 0 > > 19 > > > 2% 0 0 0 0 0 0 0 > 0 0 > > 19 > > > 6% 0 0 0 0 0 48 128 > 0 0 > > 19 > > > 2% 0 0 0 31 0 0 0 > 0 0 > > 19 > > > 2% 0 0 0 0 0 0 0 > 0 0 > > 19 > > > 2% 0 0 0 0 0 0 0 > 0 0 > > 19 > > > 3% 4 0 0 2 1 0 0 > 0 0 > > 19 > > > 2% 0 0 0 0 0 0 0 > 0 0 > > 19 > > > 2% 0 0 0 0 0 0 0 > 0 0 > > 19 > > > 2% 1 0 0 16 0 0 0 > 0 0 > > 19 > > > 2% 0 0 0 0 0 0 0 > 0 0 > > 19 > > > 2% 0 0 0 0 0 0 0 > 0 0 > > 19 > > > 3% 2 0 0 1 1 0 0 > 0 0 > > 19 > > > 5% 0 0 0 0 0 32 152 > 0 0 > > 19 > > > 2% 0 0 0 0 0 0 0 > 0 0 > > 19 > > > > > > > > > > > > >sysconfig -r > > > > > > Volume vol0 (root) > > > > > > RAID group 0 > > > > > > RAID Disk HA.ID HA SHELF BAY CHAN Used > (MB/blks) Phys > > (MB/blks) > > > --------- ----- ------------ ---- > > -------------- ---------- > > ---- > > > parity 1.3 1 0 3 FC:A 34500/70656000 > > 35003/71687368 > > > data 1.2 1 0 2 FC:A 34500/70656000 > > 35003/71687368 > > > data 1.0 1 0 0 FC:A 34500/70656000 > > 35003/71687368 > > > data 1.5 1 0 5 FC:A 34500/70656000 > > 35003/71687368 > > > data 1.6 1 0 6 FC:A 34500/70656000 > > 35003/71687368 > > > data 1.1 1 0 1 FC:A 34500/70656000 > > 35003/71687368 > > > > > > Spare disks > > > > > > RAID Disk HA.ID HA SHELF BAY CHAN Used > (MB/blks) Phys > > (MB/blks) > > > --------- ----- ------------ ---- > > -------------- ---------- > > ---- > > > spare 1.4 1 0 4 FC:A 0 > > 35003/71687368 > > > > > > > > > > netstat -s > > > > > > tcp: > > > 19180 packets sent > > > 16501 data packets (3116859 bytes) > > > 647 data packets (355343 bytes) retransmitted > > > 804 ack-only packets (114 delayed) > > > 0 URG only packets > > > 0 window probe packets > > > 1156 window update packets > > > 76 control packets > > > 22021 packets received > > > 15990 acks (for 3112800 bytes) > > > 187 duplicate acks > > > 0 acks for unsent data > > > 13688 packets (5178316 bytes) received in-sequence > > > 618 completely duplicate packets (890780 bytes) > > > 0 old duplicate packets > > > 10 packets with some dup. data (10 bytes duped) > > > 50 out-of-order packets (61320 bytes) > > > 0 packets (0 bytes) of data after window > > > 0 window probes > > > 0 window update packets > > > 1 packet received after close > > > 0 discarded for bad checksums > > > 0 discarded for bad header offset fields > > > 0 discarded because packet too short > > > 13 connection requests > > > 27 connection accepts > > > 3 bad connection attempts > > > 0 listen queue overflows > > > 32 connections established (including accepts) > > > 40 connections closed (including 1 drop) > > > 8 embryonic connections dropped > > > 15825 segments updated rtt (of 16329 attempts) > > > 531 retransmit timeouts > > > 0 connections dropped by rexmit timeout > > > 0 persist timeouts > > > 0 connections timed out in persist > > > 8 keepalive timeouts > > > 0 keepalive probes sent > > > 8 connections dropped by keepalive > > > 3594 correct ACK header predictions > > > 3474 correct data packet header predictions > > > 1758 PCB cache misses > > > 0 segments dropped at untrusted interface > > > 0 connection requests closed at filter > > > udp: > > > 3671023 datagrams received > > > 0 with incomplete header > > > 0 with bad data length field > > > 0 with bad checksum > > > 0 dropped due to no socket > > > 137 broadcast/multicast datagrams dropped due to no socket > > > 0 dropped due to full socket buffers > > > 3670886 delivered > > > 3665023 datagrams output > > > ip: > > > 7921585 total packets received > > > 0 bad header checksums > > > 0 with size smaller than minimum > > > 0 with size larger than maximum > > > 0 with data size < data length > > > 0 with header length < data size > > > 0 with data length < header length > > > 0 with bad options > > > 0 with incorrect version number > > > 0 packets with spoofed source address > > > 0 packets arrived on wrong port > > > 6499598 fragments received > > > 0 fragments dropped (dup or out of space) > > > 0 malformed fragments dropped > > > 0 overlapping fragments discarded > > > 3966 fragments dropped after timeout > > > 2272723 packets reassembled ok > > > 3693053 packets for this host > > > 790 packets for unknown/unsupported protocol > > > 0 packets forwarded > > > 867 packets not forwardable > > > 0 redirects sent > > > 3685059 packets sent from this host > > > 0 packets sent with fabricated ip header > > > 0 output packets dropped due to no bufs, etc. > > > 0 output packets discarded due to no route > > > 412593 output datagrams fragmented > > > 862312 fragments created > > > 0 datagrams that can't be fragmented > > > icmp: > > > 0 calls to icmp_error > > > 0 errors not generated 'cuz old message was icmp > > > Output histogram: > > > echo reply: 7 > > > 0 messages with bad code fields > > > 0 messages < minimum length > > > 0 bad checksums > > > 0 messages with bad length > > > Input histogram: > > > echo reply: 2 > > > echo: 7 > > > time exceeded: 790 > > > 7 message responses generated > > > > > > > > > > netstat -i > > > > > > Name Mtu Network Address > > Ipkts Ierrs > > Opkts > > > Oerrs Collis Queue > > > e8* 1500 none none 0 > > 0 0 > > > 0 0 0 > > > e0 1500 192.168.1 myhost 7929745 > > 5917 > > > 4 0 with incorrect version number > > > 0 packets with spoofed source address > > > 0 packets arrived on wrong port > > > 6499598 fragments received > > > 0 fragments dropped (dup or out of space) > > > 0 malformed fragments dropped > > > 0 overlapping fragments discarded > > > 3966 fragments dropped after timeout > > > 2272723 packets reassembled ok > > > 3693053 packets for this host > > > 790 packets for unknown/unsupported protocol > > > 0 packets forwarded > > > 867 packets not forwardable > > > 0 redirects sent > > > 3685059 packets sent from this host > > > 0 packets sent with fabricated ip header > > > 0 output packets dropped due to no bufs, etc. > > > 0 output packets discarded due to no route > > > 412593 output datagrams fragmented > > > 862312 fragments created > > > 0 datagrams that can't be fragmented > > > icmp: > > > 0 calls to icmp_error > > > 0 errors not generated 'cuz old message was icmp > > > Output histogram: > > > echo reply: 7 > > > 0 messages with bad code fields > > > 0 messages < minimum length > > > 0 bad checksums > > > 0 messages with bad length > > > Input histogram: > > > echo reply: 2 > > > echo: 7 > > > time exceeded: 790 > > > 7 message responses generated > > > > > > > > > > > > > > >

1 0

Re: Problem to integrate F740 into a Windows 2000 domain (2)
by benny.wistrom＠cn.saab.se 03 Jan '01

03 Jan '01

Problem solved! Thanks everyone for the input. It worked fine. It turned out that I had missed checking the "Allow pre-Windows 2000 authentication" box when I created the computer account. I also had to remove some files in the /etc directory on the filer because the filer had been part of another domain earlier. -- Regards: Benny Wiström CSC Phone: +46 13 4653647 Systemadministrator 581 88 Linköping Fax: +46 13 185771 Benny.Wistrom(a)cn.saab.se Sweden Mobile: +46 13 4653647 Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. -Calvin & Hobbes (Bill Watterson) Talk sense to a fool and he calls you foolish. -- Euripides

1 0

Jump to page:

2026

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