toasters

toasters@lists.teaparty.net

13531 discussions

Re: Future Newbie Needs Advice
by sirbruce＠ix.netcom.com 04 Mar '99

04 Mar '99

On 03/04/99 13:56:29 you wrote: > >Hello Everyone, > >I am about to purchase two F760's w/ Cluster Failover Software and Hardware >because we need a system that is 100% available and rock solid. I was convinced >after talking to other Net App users that this was the way to go. After a week >of reading this mailing list, I am no longer convinced. Does anyone out there >have the system I described? Are you happy with it? I am particularly concerned >about the fiber channel problems and all of the OS upgrades and patches. > >We are also considering the new Auspex NS2000. Does anyone know of an Auspex >mailing list like this one? Data seems to suggest that despite the problems described, your Netapp is going to be far more reliable than an Auspex or virtually any other system. *Nothing* is going to be 100% available. Clustered filers are close; for more reliability you're going to have to pay a LOT more for really big iron which may not have the software capabilities you want. The other important thing is that the filer, when it does crash, generally results in a minimal outage. Other serves may take a half-hour or more to recover. Bruce

1 0

Re: Gb-ether and Extreme: closure! :-)
by Devi Nagaraj 04 Mar '99

04 Mar '99

At 10:38 AM 3/4/99 -0800, Dane Jasper wrote: >On Thu, Mar 04, 1999 at 09:19:36AM -0000, Garrett Burke wrote: >> As an aside, have you run a filer into a 100Mb/s port on a S48? I'm seeing >> CRC errors on the port that my F230 is on. Netapp are investigating, just >> wondering if anyone else is seeing/has seen this. > >We've got a F230 running 100-FD with a Summit 48. We found that we had >better results if we hard set both devices to 100-FD and turned off >negotiation. The F200/F300 series on-board ethernet doesnot autonegotiate. So if you had the filer's ethernet interface set to operate in 100BaseTx-FD, the corresponding switch port should also be set to operate in 100BaseTX-FD. When speed/duplex mismatches occur, depending on the switch to which the filer's interface is connected, you will see CRC errors and collisions. You will definitely see poor network throughput. Here is a table that gives info on the board types and the supported speed and duplex (mediatype) Interface Sysconfig name Mkt P/N Mediatype --------- -------------- ------- --------- Single 10/100 - ZX342 - X1001 - 10BaseT(half/full), 100BaseTx(half/full) Quad 10 BaseT - ZX314 - X1002 - 10BaseT(half/full) Quad 10 BaseT - ZX314 - X1003 - 10BaseT(half/full) Quad 10/100 - ZX346 - X1012 - 10BaseT(half/full), 100BaseTx(half/full), auto Single 10/100 - ZX345Q - X1001B - 10BaseT(half/full), 100BaseTx(half/full), auto Quad 10/100 - ZX346Q - X1012B - 10BaseT(half/full), 100BaseTx(half/full), auto F200/300 series onboard - 10BaseT(half/full), 100BaseTx(half/full) F700 series onboard - 10BaseT(half/full), 100BaseTx(half/full), auto Here is a small note on autonegotiation in the ethernet world: Q. What is Auto-negotiation? A. Auto-negotiation is an optional function of the IEEE 802.3u Fast Ethernet standard that enables devices to automatically exchange information over a link about their speed and duplex abilities. This allows devices to perform automatic configuration to achieve the maximum common level of operation over a link. Q. How does Auto-Negotiation work at Both Ends? A. When two auto-negotiation devices with multiple capabilities are linked together, they find their maximum common mode of operation based on a priority table. The following table lists priorities from the highest (1) to the lowest (5). The full-duplex mode of operation is given higher priority over half-duplex because, at the same speed, more data can traverse the full-duplex link. ------------------------------------------------------- Priority Capabilities ------------------------------------------------------- 1 100BaseT4 (not supported on NetApp filers) 2 100BaseTX Full Duplex 3 100BaseTX 4 10BaseT Full Duplex 5 10BaseT -------------------------------------------------------- Q. How does Auto-Negotiation work at One End? A. If one link partner is set to auto-negotiate and the other link partner is manually set, the manually set partner must always be half-duplex.The IEEE spec does not allow the auto-negotiating partner to detect full-duplex on a manually set link partner. auto ----X--> 100BaseT-FD auto -------> 100BaseT-HD If one end is configured to operate in 100BaseTx fullduplex make sure that the other end is also manually configured to operate in the same mode. If there is a speed/duplex mismatch, you might see CRC errors and poor network throughput. Hope this helps. -Devi Network Appliance

4 3

RE: UNCORR PROC MCHK 98
by Bulfer, David 04 Mar '99

04 Mar '99

This is not a memory error on and F630. For an F630, an MCHK 98 means "Processor Hard Error". It is a SW problem associated with SNMP. Access NOW and check out bug 11610. David Bulfer -----Original Message----- From: G D Geen [mailto:geen@msp.sc.ti.com] Sent: Wednesday, March 03, 1999 1:46 PM To: 'toasters(a)mathworks.com' Cc: Peter Pross; Mike Ball Subject: Re: UNCORR PROC MCHK 98 We were told that this was a memory issue as well. This was not so in our case. Ours occurred when a network device discovery was run from the Spectrum server. This did not affect the system running version below 5.1.1. If you are running some sort of network monitoring tools such as Cabletron's Spectrum server, the SNMP call made by the discovery may be causing your problem as it did ours. NetApp took ownership of this issue and created a patch to fix our problem. Though this problem had been reported by other vendors, Cabletron does not consider it a bug in *their* code. -gdg Peter Pross wrote: > > Hi, > > I believe this may be memory errors. I think you aloud 1 in a blue moon, if > more replace mem. Check with netapps. > > Cheers, > > Peter > > __^__ > ( ___ > )--------------------------------------------------------------------------- > ------ > | / | Peter Pross Title: Unix Systems > Administrator > | / | Nortel Networks Montreal Email: pross(a)nortel.ca > | / | 16 Place du Commerce Voice: 514-765-7973 > | / | Nun's Island, Quebec, Fax : 514-761-8710 > > | / | Canada H3E 1H6 ESN : 852-7973 > > |___| > > (_____)--------------------------------------------------------------------- > ----------- > > > -----Original Message----- > > From: Mike Ball [SMTP:mball@rtp.opensystems.com] > > Sent: March 3, 1999 2:06 PM > > To: 'toasters(a)mathworks.com' > > Subject: UNCORR PROC MCHK 98 > > > > Does anyone have an idea of what the below error is pointing to on my F630 > > running 5.21? > > > > "Wed Mar 3 09:26:49 EST [rc]: relog syslog UNCORR PROC MCHK 98 > > pc:fffffc0000482260 cia:0 mm:4090 eia:1820f550 fs:ff00 eis:945000000 isr: > > 0 pci0:3010106 pci1:4000" > > > > I discovered my system was locked up this morning when I came in. After > > rebooting i discovered the following error in my messages file. > > > > -- --------------------------------------------------------------- G D Geen mailto:geen@ti.com Texas Instruments Phone : (972)480.7896 System Administrator FAX : (972)480.7676 --------------------------------------------------------------- Life is what happens while you're busy making other plans. -J. Lennon

3 2

RE: Gb-ether and Extreme: closure! :-)
by Garrett Burke 04 Mar '99

04 Mar '99

Hi Bruce, You'll find the same thing happens if you setup port mirroring. When you turn mirroring off the port isn't in any VLAN and hence doesn't pass any packets. Couldn't find it mentioned in any of the Extreme docs...must doc it for my colleagues..now where's my clone and a 48hr day As an aside, have you run a filer into a 100Mb/s port on a S48? I'm seeing CRC errors on the port that my F230 is on. Netapp are investigating, just wondering if anyone else is seeing/has seen this. Regards, GB > ---------- > From: Bruce Walker[SMTP:bmw@visgen.com] > Sent: 04 March 1999 09:02 > To: toasters(a)mathworks.com > Subject: Re: Gb-ether and Extreme: closure! :-) > > > But what happens when you unconfigure a trunked port on a Summit, > apparently, is that the port ends up not being on *any* VLAN. The > port is "alive" but nothing is routed to or from it. > >

3 2

Re: newbie asking about autoloaders
by rbutler＠pdc.com 04 Mar '99

04 Mar '99

> From bmw(a)visgen.com Wed Mar 3 19:26:09 1999 > From: Bruce Walker <bmw(a)visgen.com> > Subject: Re: newbie asking about autoloaders > To: kfischer(a)rsinc.com (Kathy Fischer) > Date: Wed, 3 Mar 1999 20:20:43 -0500 (EST) > Cc: toasters(a)mathworks.com > X-Mailer: ELM [version 2.4 PL24 ME5a] > Content-Type: text > Sender: owner-toasters(a)mathworks.com > Content-Length: 1536 > > Kathy Fischer writes: > > > > Can anyone out there recommend an autoloader (DLT type), or warn against any > > for use with the toaster? > > If it doesn't have to be DLT, the Exabyte Mammoth tapes get excellent > performance and are cheaper. I am getting better than 5 Mbytes/sec > continuous xfer, which lets me backup 65 Gigs in about 4 hours > using dump on the filer. This is to an Exabyte F220 autoloader > (10 tapes) running in dumb mode, attached directly to an F720. > > Well almost directly; I have a Rancho differential SCSI to single-ended > converter mashed in between the Exabyte and the F720. I ordered > both the F720 and the Exabyte at the same time and failed to notice > that the 720's come with differential SCSI! I sure croaked that > filer bad when I connected a plain 68pin to 50pin HD SCSI kluge > adapter to it. Kernel fault and core dump. > > Supposedly, BudTool works with the Exabyte too, but I may never be > able to find that out :-) > > On the performance thing: it's important that the filer be able to > get the data rate up high enough to prevent the DLT tapes from > shoe-shining which brings down their effective xfer rate a lot. > I had a DLT4000 drive for a while before I bought the F220 and it > shoe-shined a lot when driven from an F330 filer. It only managed > to do about as well as the 4mm DAT drive it was temporarily replacing. > > I kinda like helical scan technology for that start/stop ability. > > Cheers! > -- > -bmw | Double helix in the sky tonight > | Throw out the hardware > | Let's do it right -- Steely Dan; Aja > Hi, BudTool supports most all libraries that are manufactured. This includes the Exabyte 220. There are a number of DLT libraries with DLT7000 and DLT4000 tape drives in them. In my opinion, DLT is the defacto standard in the industry. Mammoth may be a little cheaper, but was never really accepted widely by the market. The top three Tape Library manufacturers are StorageTek, ATL, and Breece Hill. Any tape library from these manufacturers will give you very good service for the long term. If you go with 8mm technology such as the Mammoth or Sony AIT, then Exabyte or Spectrologics makes excellent tape libraries to fill this nitch. As an aside, the top three Tape Library manufacturers I mentioned above (STK, ATK and BH) decided to only support DLT tape technology for OpenSystems (UNIX) and passed on Mammoth and AIT. Randy Butler System Engineering Supervisor - Western Region PDC Solutions, Inc. phone: 972-446-2644 x15 Systems Engineering Solutions FAX: 972-245-9320 1445 MacArthur Drive, Bldg. 1, Suite 116 Carrollton, TX 75007 E-mail: rbutler(a)pdc.com //////////// //////////// ////////// // /// // // /// // // //// // /// // // /// // /// // /////////// // /// // // // /// // // // /// /// /// //// ///////////// /////////////

1 0

Sun Trunking
by Mohler, Jeff 04 Mar '99

04 Mar '99

Im looking for a reference to the Sun Trunking software..and Im unable to locate so far. Sorry for the off topic, but if anyone has a reference...thanks.

1 0

RE: VIF command
by Mohler, Jeff 04 Mar '99

04 Mar '99

> What switch are you using (mfg/model)? There are many differences in how > load > balancing is implemented. I have even found differences in different > model > switches from the same manufacturer. All that I have seen are based on > MAC > addresses - Either source, destination or a combination. Some mfg's let > you > choose which to use. If your client base is reasonably large with random > MAC > address and equal loads, then the traffic will be balanced. Small client > pools > or most traffic being generated/requested by a few clients can skew the > load. > Some implementations have standby ports in the trunk, which seems like > what you > are seeing. I believe Extreme allocates one port out of the trunk as a > standby. > Perhaps this is configurable. --- Its a FEC blade in a Cisco 5505.

1 0

RE: VIF command
by Naden, Barbara 04 Mar '99

04 Mar '99

What switch are you using (mfg/model)? There are many differences in how load balancing is implemented. I have even found differences in different model switches from the same manufacturer. All that I have seen are based on MAC addresses - Either source, destination or a combination. Some mfg's let you choose which to use. If your client base is reasonably large with random MAC address and equal loads, then the traffic will be balanced. Small client pools or most traffic being generated/requested by a few clients can skew the load. Some implementations have standby ports in the trunk, which seems like what you are seeing. I believe Extreme allocates one port out of the trunk as a standby. Perhaps this is configurable. Barbara -----Original Message----- From: Mohler, Jeff [mailto:jeff.mohler@wilcom.com] Sent: Thursday, March 04, 1999 7:01 AM To: 'Sam Cramer'; Mohler, Jeff Cc: 'toasters(a)mathworks.com' Subject: RE: VIF command > If you unplug one of the busy links, does one of the idle links pick up > the > slack? > > Sam --- Yes, a spare link picks up the dead one, and holds onto it when you restore the dead link.

1 0

Re: 5.2.1 blues
by sirbruce＠ix.netcom.com 04 Mar '99

04 Mar '99

On 03/03/99 08:42:57 you wrote: > >I mean, instead of running 5.1.2P1, P2, D1, D2, D3, D4, D5, D6, or D7 >(deep breath) >I'd like to run 5.1.2 with the patches i feel i'd like to have. I think that's an even worse idea. If you think that Netapp's QA is bad now (and I'm not saying it is), you've just increased their workload exponentially because they have to test each combination of patches to make sure they all work together in whatever combination a user might pick. My experience is that Netapp's patches for specific problems are generally very good, but there always seem to be a couple of large bugs in new releases that many customers run into right away that should have been caught in testing. Bruce

3 2

RE: VIF command
by Mohler, Jeff 04 Mar '99

04 Mar '99

> If you unplug one of the busy links, does one of the idle links pick up > the > slack? > > Sam --- Yes, a spare link picks up the dead one, and holds onto it when you restore the dead link.

1 0

Re: VIF command
by Sam Cramer 04 Mar '99

04 Mar '99

Jeff writes: > I created me a vif interface made up of four 100Mb Ethernet interfaces. > > I see, that only the first two interfaces really do anything, the second two > show no errors, but dont DO anything. It's my understanding that etherchannel switches use a proprietary protocol to distribute load over the links. This protocol often involves a hash of the source and destination addresses. It may be that you have a pattern of access from specific clients that doesn't hash well, and so doesn't distribute the load over all the links. > Im thinking it hasnt reached a 'threshold' to fire up more links. I don't believe that total network load needs to hit a certain threshold in order to use all the links. If you unplug one of the busy links, does one of the idle links pick up the slack? Sam

2 1

RE: NFS 2 -vs-3
by Mohler, Jeff 04 Mar '99

04 Mar '99

Nothing makes me think 2 is -better-, just that I see more "V2 is better" type arguments. Im just ferreting out actual facts *grin* > -----Original Message----- > From: kls(a)netapp.com [SMTP:kls@netapp.com] > Sent: Tuesday, March 02, 1999 10:17 PM > To: jeff.mohler(a)wilcom.com > Cc: toasters(a)mathworks.com > Subject: Re: NFS 2 -vs-3 > > > In a really short list, other than the attribute cache, why is vers 2 > NFS > > better than vers 3? > > What makes you think V2 is better than V3? > > > I will be working with directories with fewer than a dozen LARGE files > on > > each mount. > > With few files per directory, I can't think of anything in favor of > V2, and with large files I can think of various advantages to V3, > larger packet sizes being the major one. > > -- Karl

3 2

Re: Gb-ether and Extreme: closure! :-)
by Bruce Walker 04 Mar '99

04 Mar '99

A very long time ago (mid-November 98), when I got my F720 filer with Gigabit ether, I tried to connect it to an Extreme Summit48, had trouble, contacted NetApp, despite excellent suggestions still had trouble and appealed to this list. Got a few "let us know what happens", but unfortunately no real leads. The story has a happy ending, and here's what did happen. First off: Gigabit on F720 to Summit48 works great. That's settled. Also, with the help I got from NetApp (Mark Smith, Tim McCarthy, David Zwick, Devi Nagaraj, possibly others!), if I had been actually able to concentrate on the problem for more than 30 minutes at a time (and more than 60 minutes per week :-), I might have noticed what was going on earlier. What the problem turned out to be is: on both of the Summit48's I had available to me to test the Gig ether link, the port I was using, always port 50, was missing from any VLAN list. What *that* means is that although the port appeared alive, no packets were ever delivered to that port from any other and it quietly acted as a packet sync for anything received from the filer. Now how did port 50 end up off of all VLANs, on both switches? Simple! Right after I first received my brand new switches, I had trunked the two fiber links on the two Summit48's together, just to see if it would work. I ran fiber from port 49 on one to port 49 on the other and 50 to 50. When the F720 arrived, I moved one fiber link (port 50) from the second Summit48 over to the 720 and unconfigured the trunking. But what happens when you unconfigure a trunked port on a Summit, apparently, is that the port ends up not being on *any* VLAN. The port is "alive" but nothing is routed to or from it. So, I reconfigured the affected ports (put all ports back on the Default VLAN) and the G/B link to the 720 now works just fine. There's still one small "cosmetic" glitch. When the filer comes up, it always reports that the G/B link is up, then right away that it's down. The last console message is always "e8: link down". But it is up (or I couldn't type this mail), so I'm not overly concerned. Do I really need Gigabit ether to an F720? Possibly not. I've only managed to drive the link to 1.5 times the speed of a 100Mbit link so far. But with the prices of Summit48's back when I bought them, I figure the Gig interfaces came for free. Plus, this way I don't have to trunk 100Mbit ether ports and waste good sockets on the switch. And anyway, I'm always adding more clients to load down the filer. That reminds me: has the Progress db been certified yet? -- -bmw | Double helix in the sky tonight | Throw out the hardware | Let's do it right -- Steely Dan; Aja

2 1

newbie asking about autoloaders
by Kathy Fischer 04 Mar '99

04 Mar '99

Hi everyone, I'm brand new to this mail group, and to toasters. We just recently setup our new toaster (720), and we are currently implementing into our environment. Part of this process is developing a backup policy for our toaster, and hooking up an autoloader! Can anyone out there recommend an autoloader (DLT type), or warn against any for use with the toaster? We need to buy one pretty quick, and I want to be sure we get one that won't cause us major headaches :-) !! FYI, we've been looking at the DLT4700, but are unsure which brand to go with. Thanks in advance for any help, Kathy Kathleen G. Fischer Research Systems, Inc. (303)413-3909 kfischer(a)rsinc.com

2 1

RE: Dell Deal
by Strange, Steve 04 Mar '99

04 Mar '99

> From: Dane Jasper [mailto:dane@sonic.net] > > If only the power switch wasn't on the front. We had to tape a half of a > plastic backup tape box on unit to keep someone from pushing the big black > button. You must have an F630 or earlier filer -- your wish came true on the 700-series! Steve

1 0

"5.1.2P2D7"? Whoa, Nelly.
by Brian Rice 03 Mar '99

03 Mar '99

I had no idea that x.y.z.Pm.Dn could exist. So thanks for the tip (sigh). I'm guessing that 5.1.2P2D7 is probably my best bet for a retrograde target, if it comes to that. Any horror stories with that one? I'm not running any cutting-edge hardware...just boring old SCSI shelves (well, one of the F630's is FC). I just want all my filers running the same release, and not panicking when I do a "quota on". It'd be lovely if said release didn't have a name suggestive of a Star Wars droid, but I'll take what I can get. Brian Rice (known to his friends as B2R2)

1 0

Re: Dell Deal
by Jay Sekora 03 Mar '99

03 Mar '99

Dave "Color Me Cool" Hitz wrote: > The most consistent complaint that we've had about the > 700 series is that the bezel isn't "cool" enough. > > I've done some serious rabble rousing, and I've gotten > a strong commitment that the bezel on our next high > end system will be cool. My officemate's response to this was: `They don't think that thing's cool? I think that thing's _mad_ cool! What're they talking about?' So you have at least one voice of approval for the coolness of the 700-series bezels. However, I have to admit that we haven't actually seen the stainless steel ones here. Jay Sekora Northeatern University College of Computer Science PS - I think `mad cool' is supposed to mean something like `very impressive' or `extremely appealing', but I wouldn't know - I don't speak cool.

5 4

RE: Dell Deal
by Bulfer, David 03 Mar '99

03 Mar '99

No, chrome was never really considered. It was supposed to look slightly unrefined, somewhat brash, totally in your face. Aluminum was selected because of the tooling budget that NetApp could afford at the time and because of the expected volume of the F540. Had we known that we'd sell as many F540s as we did, thing may have turned out differently. David -----Original Message----- From: kls(a)netapp.com [mailto:kls@netapp.com] Sent: Wednesday, March 03, 1999 12:20 PM To: hitz(a)netapp.com Cc: jeff.mohler(a)wilcom.com; toasters(a)mathworks.com Subject: Re: Dell Deal > > Is there any way we can get some -real- faces on the F760s? > > > > Seriously, my management was quite unhappy to see four non-matching purple > > plastic faces on our 760s after the sweet Stainless on the demo 630 we had > > *grin* Polished aluminum, actually. It was really supposed to be chrome, but the story I heard was that chrome would have been *really* expensive. > The most consistent complaint that we've had about the > 700 series is that the bezel isn't "cool" enough. > > I've done some serious rabble rousing, and I've gotten > a strong commitment that the bezel on our next high > end system will be cool. A refrigerated bezel? :-) I guess a refrigerated toaster wouldn't make much sense. -- Karl

1 0

RE: Dell Deal
by sirbruce＠ix.netcom.com 03 Mar '99

03 Mar '99

On 03/03/99 08:57:44 you wrote: > >A faux-tigerskin bezel, a fireplace, a scantily-clad young lady stroking said >bezel while purring appreciatively. Has anyone contacted our advertising agency? Does the scantily-clad young lady included with the bezel? I bet they could sell a lot of filers that way.... Bruce PS - This would make a great ad campaign. Show a picture like the above, the woman stroking the bezel and the words, "Is your file server... sexy?" Then you could have a little asterisk and at the bottom of the advert the words: *Scantily-clad young lady not included. Bruce

1 0

Re: 5.2.1 blues (salient points for exploiting NetApp support facilities, a worked example ;)
by mds＠gbnet.net 03 Mar '99

03 Mar '99

On Tue 2 Mar, 1999, Graham Knight <grahamk(a)ast.lmco.com> wrote: > Our encounter (albiet brief) with 5.2.1 was pretty disasterous too. I'm > camped at 5.1.2P2 and have no reason to move. Except for the occasional > 5.2.1 floppy boot for the fiber channel diagnostics. ;-) I've a long story about 5.1.2...are we sitting comfortably? I shall begin: Well, we'd decided to move to 5.1.2 as a Y2K compliance upgrade. I fished around on the NOW site to check whether there were any patch releases available. You see we've been bitten several times by the following scenario: o upgrade to recommended release. o get hit by *known* bug. o get told that we should have gone straight to the latest official patch release (now apaprently the x.y.zPa releases, but once x.y.z.Da ..) which, bizarrely is invisible in the NOW site, unless you go fishing. o upgrade *again* So I fished around the un-linked-to parts of the Software Library and found 5.1.2P1, P2, D1, D2, and which now has D5, D6, and god-(and NetApp)-only knows what else. I never touch X releases. If any other letters are in use, I wouldn't know. I read over the descriptions and decided that 5.1.2P2 was the latest and greatest and officially sanctioned with a 'P' release moniker and that that was what we should go for. My colleagues, gaining experience with the filers, while I went off to upgrade our DNS/etc. infrastructure, undertook to upgrade our remaining 4 F330's, F520, 3 F630's and F540. They'd carefully tested the upgrade on another F330 a week earlier. All was apparently go-for-launch. After the upgrade there was a problem with the quotas one one filer - we couldn't turn them on because the filer would crash. Because we'd upgraded from 4.3.1 they could back-out without going to 5.0 first, which they didn't have, and didn't know how to find in NOW (I'm the only angler). I proposed they get NetApp support on the case and progress the issue - as the filer was still running and serving. For extra entertainment value 2 filers threw 3 disks between them (1 threw 2 in quick, but not lethal, succession - scary!) and another started misbehaving doing restores in the next day. Then another machine threw a disk, and *crashed* as a result. We logged calls for some failures and a call was automagically logged for the last one, from the autosupport mail (even though they're _all_ configured for autosupport), and cores were ftp'd for analysis. We were told that we needed to use wackz (not wackq, not wacky.. wackz *sigh* the Great UnDocumented, what a confidence builder) from, get this, 5.1.2P2D7. to fix the quotas problem on our one limping filer. 5. 1. 2. P2 _D7_ ferchrissakes!!! Dutifully my colleague did so. Now I, in my greater experience would then have booted from the 5.1.2.P2D7 floppies, and installed the 5.1.2P2D7 sysfiles, downloaded and then rebooted avoiding at all costs the known-to-be-buggy 5.1.2P2 code that still lurked on the filer. Sadly my colleagues just ran the wackz and rebooted...back to the known buggy 5.1.2 install. *sigh* I was very convincing, and somewhat impassioned and the upgrade was done, belatedly, but hopefully without any damage during the brief 5.1.2P2 run-time. I'm probablyoverstating the danger, but _D7_! Sheesh! Anyway. Long story, doubt many of you are still with me, but the moral I draw is this: NetApp have now achieved an overly baroque and divaricated release tree and have obscured it behind a screen of cgi's and HTML. They've developed wonderful support mechanisms that don't seem to be applied 100%, which means they can't be relied upon. These issues need to be addressed before they get worse. Being more forthright about all the patchings at each release, and making clear statements about which one the developers and support folk think customers should be running, rather than hiding all but the first release in the Software library would be very good. Patches being made for one specific customer site should perhaps be furnished only to that site, not placed into the public software library. Now I love NetApp kit and software for their evident virtues and I consistently champion them in my company, but I'm getting somewhat disenchanted, even annoyed by the increasingly less-than-polished releases of DOT and the support structure backing us up. The dismal state of backup-and-restore technology is also causing me to worry about the long-term ability of NetApp boxes to fulfill our needs. Maybe I'll change my opinion about that when we get Veritas Netbackup working...*if* we get it working. But that's another story, for another day. 8) I rather hope someone in NetApp takes up these points, seeing as so many of the fine folks on this list are NetApp stalwarts. This is the sort of feedback that I hesitate to give to front-line support folk lest they take it personally, or just bury it. This list at least hits doers at all levels in the NetApp organisation! There, that's off my chest... And everyone lived happily ever after. > > One day, i'd really like to see NetApp move to a user patchable OS. Anyone > else? Well, the patches may be big, but NetApp boxes are user patchable. We don't need our NetApp SE's to do everything for us. 8) > > Graham > >-- End of excerpt from Graham Knight

4 3

RE: VIF command
by Mohler, Jeff 03 Mar '99

03 Mar '99

> The filer is quite busy at the moment: > > CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache > in out read write read write > age > 75% 2695 1322 0 1554 2930 769 0 0 0 > 3 > 86% 2596 1150 0 2668 6273 4564 1953 0 0 > 2 > 94% 2515 1125 0 4332 6292 6295 3998 0 0 > 2 > 92% 2447 1197 0 3581 6829 6164 3836 0 0 > 2 > 87% 2257 1017 0 3251 6568 7332 3976 0 0 > 2 > 78% 2683 1028 0 1482 7961 5595 0 0 0 > 1 > 90% 2796 1057 0 743 10365 5145 3399 0 0 > 1 > 88% 2525 1262 0 2772 9479 5426 0 0 0 > 1 --- This is what I see on averate..and right now: CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 41% 831 0 0 754 5852 7311 8801 0 0 1 62% 897 0 0 322 7038 16440 11499 0 0 1 42% 673 0 0 823 4661 14210 2550 0 0 1 50% 1122 0 0 1175 8226 14409 1054 0 0 1 44% 855 0 0 480 6941 18302 1889 0 0 1 62% 1674 0 0 758 13759 15735 768 0 0 1 71% 1857 0 0 1004 15127 16968 896 0 0 1 84% 1663 0 0 1015 13346 19151 2810 0 0 1 77% 1616 0 0 1002 12960 16984 8008 0 0 1 76% 1351 0 0 610 11101 16928 11891 0 0 1 65% 1633 0 0 928 13222 16540 912 0 0 1 57% 1416 0 0 438 11811 15956 920 0 0 1 66% 1591 0 0 1676 12067 16540 864 0 0 1 59% 1433 0 0 1316 11089 16616 1249 0 0 1 48% 1109 0 0 677 8873 14048 864 0 0 1 50% 1147 0 0 1311 8566 16660 1601 0 0 1 58% 1385 0 0 2106 9911 14210 1089 0 0 1 53% 1197 0 0 2193 8149 14192 1184 0 0 1 64% 1465 0 0 3085 9515 15295 1025 0 0 1 And I only see traffic on two interfaces, although I can unplug working ones, and it fails over to idle ones.

1 0

RE: VIF command
by Mohler, Jeff 03 Mar '99

03 Mar '99

> Here's our output, for comparison. Seems to be a little > more evenly distributed than yours, but e3a takes the lead by far. > > bat> netstat -i > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Collis > Queue > e0* 1500 none none 0 0 0 0 0 0 > > e3a 1500 144.212 bat 935492178 17 1070359540 268973 0 > 0 > e3b 1500 144.212 bat 712967233 17 800877896 233521 0 > 0 > e3c 1500 144.212 bat 527507321 2 669191765 212388 0 > 0 > e3d 1500 144.212 bat 522712811 89 672437298 201463 0 > 0 > lo 1536 127 localhost 30198 0 30198 0 0 0 > --- How much bandwidth are you using there, I am only barely using 110-130Mbits average. Im thinking it hasnt reached a 'threshold' to fire up more links.

2 1

VIF command
by Mohler, Jeff 03 Mar '99

03 Mar '99

I created me a vif interface made up of four 100Mb Ethernet interfaces. Seems to kick butt..again, too easy. I see, that only the first two interfaces really do anything, the second two show no errors, but dont DO anything. --- ratbert> netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Collis Queue f2 4352 10.16.2/24 ratbert.wil 4106473 0 3683613 0 0 0 e1a 1500 151.142.223 tulsnae0.wc 15529776 0 48689576 5 0 0 e1b 1500 151.142.223 tulsnae0.wc 19535884 0 57094960 5 0 0 e1c 1500 151.142.223 tulsnae0.wc 92 0 19 0 0 0 e1d 1500 151.142.223 tulsnae0.wc 1534 0 13 0 0 0 lo 1536 127 localhost.w 0 0 0 0 0 0 ratbert> --- Is this normal? Thanks.

2 1

RE: UNCORR PROC MCHK 98
by Peter Pross 03 Mar '99

03 Mar '99

Hi, I believe this may be memory errors. I think you aloud 1 in a blue moon, if more replace mem. Check with netapps. Cheers, Peter __^__ ( ___ )--------------------------------------------------------------------------- ------ | / | Peter Pross Title: Unix Systems Administrator | / | Nortel Networks Montreal Email: pross(a)nortel.ca | / | 16 Place du Commerce Voice: 514-765-7973 | / | Nun's Island, Quebec, Fax : 514-761-8710 | / | Canada H3E 1H6 ESN : 852-7973 |___| (_____)--------------------------------------------------------------------- ----------- > -----Original Message----- > From: Mike Ball [SMTP:mball@rtp.opensystems.com] > Sent: March 3, 1999 2:06 PM > To: 'toasters(a)mathworks.com' > Subject: UNCORR PROC MCHK 98 > > Does anyone have an idea of what the below error is pointing to on my F630 > running 5.21? > > "Wed Mar 3 09:26:49 EST [rc]: relog syslog UNCORR PROC MCHK 98 > pc:fffffc0000482260 cia:0 mm:4090 eia:1820f550 fs:ff00 eis:945000000 isr: > 0 pci0:3010106 pci1:4000" > > I discovered my system was locked up this morning when I came in. After > rebooting i discovered the following error in my messages file. > >

2 1

cifs reconfiguration (workgroup -> domain)
by Todd C. Merrill 03 Mar '99

03 Mar '99

In the docs I see: file:/..../5_2_1-cd/ontap/5_2_1/doc/html/first/prp_cifs.htm#1149815 Deciding on a domain or workgroup configuration About this section You can install the filer into a Windows NT domain or Windows workgroup. Use the information in this section to help you decide which to choose. Caution: It is difficult to change this decision after you run setup. <gulp> Okay, I do want to change (from a workgroup to a domain). How difficult is "difficult"? If we're talking about gunning/modifying a few files from the filer etc directory, this is not difficult, coming from the CLI UNIX world. I hope this warning was just placed there for NT folks who use the GUI's. This FAQ doesn't quite expound on the "difficult" part above. http://now.netapp.com./knowledge/contents/FAQ/FAQ_309.shtml How does changing the authentication method from NIS to a domain controller affect the UNIX boxes accessing the filer via NFS? This FAQ seems a bit ambiguous: http://now.netapp.com./knowledge/contents/FAQ/FAQ_459.shtml Until next time... Todd C. Merrill The Mathworks, Inc. 508-647-7792 24 Prime Park Way, Natick, MA 01760-1500 508-647-7012 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

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