toasters

toasters@lists.teaparty.net

13515 discussions

Re: NetApp and FDDI
by dheiland＠lucent.com 05 Sep '97

05 Sep '97

Are these NFS server not responding messages occurring at any specific time? I'm seeing similar messages about 3am each night - the same time that a cron runs to remove .nfs files. I'm still looking into and for me it might just be a matter of changing from soft mounts to hard mounts, or even problems with NIS binding. Dave > On Thu, Sep 04, 1997 at 09:59:11AM -0400, Alexei Rodriguez said: > > > Looking through the logs on the clients, we have "NFS server not responding" > > errors (for 0 sec duration) across all the clients. Those that > > beat more heavily on the NetApp (like one box that constitutes 70% of > > the traffic) has these every few minutes. > > These occur using full duplex 100T and suns as clients as well. So I > don't think that FDDI is the key. I think I remember reading that netapp > had fixed this, or were working on a fix. > -- > Michael Douglass > Texas Networking, Inc.

2 1

Re: NIC card for NetApp?
by sirbruce＠ix.netcom.com 04 Sep '97

04 Sep '97

On 09/04/97 00:34:43 you wrote: >I might agree with you if I didn't have experience with netapp's RMA >department. We have been shipped replacement motherboards with >*mismatched* DRAM simms in them from netapp. Mistakes do happen. I've gotten motherboards with bad onboard ethernet, slots that didn't work, etc. But by working with Netapp these are put into the corrective feedback loop and prevented from happening again (at least in theory). >All accessories we put in >our netapps are *Exactly* the same part numbers as what netapp uses. >Down to the same Samsung Simms that netapp does, the same Seagate >drives that netapp does, the *same* DEC Storageworks canisters, the >*same* dallas semiconductor nvram. I don't think the nvram simms are an approved component for customer buy, but that may have changed. I mean, you think it's the same because of the serial number, but how do you know there isn't something else Netapp changes? Nvram is probably a bad example of this but you can easily think of other examples. >Guess what...it all works *perfectly* as expected So far... what are you going to do if it doesn't? >I was not talking about unapproved components. I would *never* risk >the chance of a failure due to an unapproved component. I do however >have a problem with paying 200-300% *more* for the same accessories. Again, I didn't think nvram was an approved component (as in approved for customer buy), although I know that some memory is. But what about future filers that have memory that isn't (I think the F630 is that way now?) or the new 9GB cannisters? I dunno if those are readily available elsewhere. I agree 200% is steep, but I would have no qualms about paying 150% for the same component I could get elsewhere but had been tested or modified by Netapp to work properly with their equipment. Bruce

3 3

Re: NIC card for NetApp?
by sirbruce＠ix.netcom.com 04 Sep '97

04 Sep '97

On 09/04/97 08:33:11 you wrote: >> Mistakes do happen. I've gotten motherboards with bad onboard >> ethernet, slots that didn't work, etc. But by working with Netapp >> these are put into the corrective feedback loop and prevented from >> happening again (at least in theory). > >But didn't someone _just_ say that the parts you get are tested for >reliability... Yes (it was me). Of course, that process isn't perfect... >I'm sure that was speculation on the part of the >speaker--but I guess this just goes to show you that they are _NOT_ >testing their product before shipping it. We've sent numerous >motherboards back. One would would be curious to know the circumstances. Perhaps RMAs are not tested the same way as shipped product, or perhaps shipped product breaks during shipping (DOA). Neither of these negate what I said about the testing (which does occur normally), nor does it negate the assertion that these problems are resolved through corrective action. I agree, though, that as the quality of the testing process degrades, the trade-off for premium prices diminishes. Keep in mind also that my point of testing was not that it prevents normal breakage, but that it ensures compatibility and realibility of the working part. Disk drive failures, memory simm failures (due to slighting off timing), and compatibility of difference card revisions (i.e. the card you buy off the shelf from DEC may not be the same as the one in your Netapp, even if it looks the same and seems like it should work). Bruce

1 0

Re: NIC card for NetApp?
by sthaug＠nethelp.no 04 Sep '97

04 Sep '97

> Netapp *really* does its customers a disservice but its RIDICULOUS > pricing on common accessories. > > $1950 list for a F/W Cuda 4 from netapp...and they offered us this > *incredible* 15% discount...wow $1657.50... > > Tech Data had the same drive for $665. > > I love our toasters, but someone in netapp marketing really needs to > get a grip on reality. It may be more relevant to compare the NetApp prices with a new Cuda from other sources in a Storageworks shelf. Here in Norway you can only get disks in Storageworks shelves from DEC, and they are *much* more expensive than the disks themselves. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

Re: NIC card for NetApp?
by sirbruce＠ix.netcom.com 04 Sep '97

04 Sep '97

On 09/03/97 21:04:48 you wrote: >Netapp *really* does its customers a disservice but its RIDICULOUS >pricing on common accessories. > >$1950 list for a F/W Cuda 4 from netapp...and they offered us this >*incredible* 15% discount...wow $1657.50... > >Tech Data had the same drive for $665. > >I love our toasters, but someone in netapp marketing really needs to >get a grip on reality. > >Jonah I take the Devil's Advocate (and probably unpopular) position. Sure, everyone would love to be able to get the parts cheaper, but that carries a higher risk unless you are using approved parts. The parts Netapp sells you are going to be tested to some extent. The failure rate of disk drives is very high; you are paying a premium partly for that reliability testing. You may think you see the same part elsewhere... but is it *really* the same part? Is the drive's firmware version the same? What about the NIC card's ethernet chip revision? Or firmware on your FDDI or ATM card? Those things do matter, and just because you may have a third-party component that appears to work doesn't mean it doesn't have a lingering bug, or that it won't stop working in a subsequent software release due to Netapp changing their drivers. Would you want to risk explaining to your boss that the filesystem is trashed or the server won't come back up because you decided to save a few hundred or even a thousand dollars on an acessory, and that Network Appliance can't be blamed for the failure? Now, that having been said, I do agree that many of the prices are steeper than I would like to see as a customer, and I think they need to be reduced to discourage customers from doing what I described above and getting into some serious trouble. But I personally wouldn't risk an unapproved component, and I would be remiss in not advising others to avoid it as well. Bruce

2 1

Re: Nice hidden command: mv
by sirbruce＠ix.netcom.com 04 Sep '97

04 Sep '97

On 09/02/97 22:58:32 you wrote: > >(I'm assuming this mailing list is still active.) > >As an ice-breaker (teaser?), I thought I would share a useful hidden >command that is present in NetApp Release 4.1d (and probably most >others). It isn't listed in any online help (well, that's almost true) >or documented anywhere, but you can use it anytime on the console. >Note: I found this command on my own (i.e., it was not disclosed to me >by NetApp). There are several "hidden" commands, some more hidden than others. Some of them can only be acessed via special instructions Netapp tech support provides. In any case, there's usually a reason the commands are hidden. In many cases they aren't "safe" to use, and you can be sure they certainly don't go through the usual QA cycle. Now, I'm not saying mv is dangerous (I don't know the code), but I would not be surprised if it didn't fail to lock certain buffers properly in multiuser operation, or not update the filesystem correctly for CIFS attributes, or any number of other problems. I wouldn't want to risk the possibility of corruption and/or a crash unless it was an "approved" Netapp command. Bruce

1 0

subscribe
by Jason C Ingham 03 Sep '97

03 Sep '97

1 0

Re: restoring from snapshot
by sirbruce＠ix.netcom.com 26 Aug '97

26 Aug '97

On 08/26/97 15:35:53 you wrote: >Unfortunately there is no magic way, so you simply have >to use your favorite copy command. > >The "cp" command does scary things with symlinks and >device drivers, so "tar | tar" like you've done, or >"find | cpio -pdmv" are better. Yeah, tar has bugs in differnet versions... and cp is just bad. I prefer "find . -print | cpio -pdumv /path/to/newdir" myself. However, long filenames with spaces in it can break this too. :) Gotta write a fancy shell-script wrapper or something... Bruce

1 0

restoring from snapshot
by Christoph Doerbeck 26 Aug '97

26 Aug '97

Greetings, I've run into this scenario where a directory of "useful" stuff got deleted (about 7 gigs of "useful" stuff). At any rate, it all appears to be sitting in the hourly.1 snapshot as expected, but now I wonder... What is the best way to restore it? I`ve disabled the snapshots while my "tar cf - | tar xpf -" does it's thing, but is there a better way? I also wonder, since a "mv" blew away the directory in the first place (this is what I was told), can I "mv" the directory right back out of .snapshot? So what is the BEST snapshot restore method? ++----------------------------------+ )) Christoph Doerbeck (( Motorola ISG )) email: doerbeck(a)dma.isg.mot.com ++----------------------------------+

2 1

Very slow fcntl() calls from Solaris to F230
by Brian Tao 20 Aug '97

20 Aug '97

I noticed a very serious problem this morning on one of our news servers with a Netapp-based spool (Ultra 170, 1GB RAM, Solaris 2.5.1 + Aug 16 rec. patches). That server was recently upgraded from a 2.5 Ultra running INN 1.4unoff4 to the 2.5.1 Ultra running INN 1.5.1. Building or adding to the overviews files takes a *very* long time. I trussed the overchan as well as an expireover process, and I'm seeing a long delay (on the order of a minute or more) after one of the open() calls. I believe it is sleeping on fcntl(): [reading in article headers...] open("/news/spool/a/a/mis/talk/1944", O_RDONLY) = 4 read(4, " P a t h : t o r - n n".., 8192) = 1293 read(4, 0x0004D060, 8192) = 0 fstat(4, 0xEFFFF5A8) = 0 close(4) = 0 open("a/a/mis/talk/.LCK.overview", O_WRONLY|O_CREAT|O_TRUNC, 0664) = 4 open("a/a/mis/talk/.overview", O_RDWR|O_CREAT, 0664) = 5 [big delay here] fcntl(5, F_SETLK, 0xEFFFF5AC) = 0 fstat(5, 0xEFFFFAA0) = 0 writev(4, 0xEFFFFB28, 1) = 7404 rename("a/a/mis/talk/.LCK.overview", "a/a/mis/talk/.overview") = 0 close(4) = 0 close(5) = 0 open("/news/spool/a/bsu/programming", O_RDONLY|O_NDELAY) = 4 fcntl(4, F_SETFD, 0x00000001) = 0 [continue with next newsgroup...] It spends 99% of the time waiting for that fcntl() to return. The spool is mounted NFSv2, UDP. I've tried both hard and soft mounts. The same NFS configuration (AFAIK) worked fine on the old news server. I still have the old server online, and I can verify this (rm the overview file, then regenerate from scratch): old-server% time expireover -a -f /tmp/test.active 0.03u 0.11s 0:00.14 100.0% new-server% time expireover -a -f /tmp/test.active 0.04u 0.13s 1:17.25 0.2% Over a minute to create a 44-line .overview file? lockd and statd are running on the Solaris side, rpcinfo reports nlockmgr is registered. I must be missing something obvious, but I can't see it. :( -- Brian Tao (BT300, taob(a)netcom.ca) "Though this be madness, yet there is method in't"

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters