toasters

toasters@lists.teaparty.net

2 participants
13520 discussions

RE: RAM and NVRAM for F330
by Weeks, Thomas 17 Apr '98

17 Apr '98

> -----Original Message----- > From: Marc Nicholas [SMTP:marc@hippocampus.net] > Sent: Thursday, April 16, 1998 2:48 PM > To: Weeks, Thomas > Cc: 'Kelly Setzer'; sirbruce(a)ix.netcom.com; toasters(a)mathworks.com > Subject: RE: RAM and NVRAM for F330 > > On Thu, 16 Apr 1998, Weeks, Thomas wrote: > > > RAM on the filer is being run to the very MAX of its specs > > (maybe more)... I hear that they have a fairly high failure rate on > RAM > > that would otherwise work FINE in slower, less demanding systems > (PC's). > > 'scuse me??? Really? I find this somewhat hard to believe... > > 60ns RAM is widely available, are you saying they're pushing the > envelope > on that? > > I very much doubt the memory architecture on a NetApp is anything more > sophisticated than Sun's memory architecture (and I almost guarantee > Sun's > memory architecture blows away low-end NetApps)...and Sun seem able to > use > fairly standard parts without too much failure. > [Weeks, Thomas] I'm just telling you what the NetApp engineer that I spoke to told me. Of the RAM that they get in for filer use, that have to send back they told me that they have like a 30% failure rate (of the exhaustive testing they do). I don't know how much that has changed (if at all) recently or not... Why don'tcha ask 'em. > Maybe I'm just missing the big picture... > > > -marc [Weeks, Thomas] Tom

1 0

My Background
by sirbruce＠ix.netcom.com 17 Apr '98

17 Apr '98

Someone spoke to me privately via email and suggested that it would be fair that I disclose my "association" with Network Appliance. Since people were making decisions based upon my opinions (Hah! That would be a first!), they thought I should reveal whatever "bias" I might have, since I'm not just a customer. Some of you already know this. Some of you may also feel that having worked for Netapp, my arguments are suspect. I take exception to that. I was a customer of Netapp for years back when I was working for NETCOM, before I later went to work at Netapp. I don't think that working for Netapp colored my opinions of the filer too much; I thought it was a great product in the first place, which is why I wanted to work there. While I was at Netapp, I worked in Systems Administration. We used Netapp products in-house. In many ways, we were considered the "in-house customer". My job, when it came to the filer, was not to tell Engineering or Marketing or Sales what they wanted to hear... it was to tell them, fairly and honestly, what I liked and didn't like about the products, what the bugs we were encountering were, etc. In many ways this was a continuation of the close working relationship I had with them while we were running early Netapp products at NETCOM. If anything, my work in this area was excessive, but it enabled Netapp to fix bugs and address problems before you, the REAL customer, ever had to see them in the field. Since I left Netapp, I've also done periodic consulting for them, but I'm not really associated with the product development cycle anymore. I'm not depending on a paychek from them or worried about getting fired for saying the wrong thing in this forum. If I were to go back to work for Netapp, I'll be sure to let everyone know. The idea that this has somehow rendered me a Netapp "sympathizer" is ludicrous. I was enthusiastic about the products before I worked there and am enthusiastic about it afterwards. I don't think anyone who knew me at Netapp would accuse me of being anything less than forthright, or out here "towing the party line" to put on a good face to customers. I'm here giving you my honest views. I think those people who post that currently work at Netapp are being genuine as well. Certainly Guy Harris is no spin doctor. :) Do I still have some stake in the company and want it to succeed? Certainly; I own stock in it. And I'm sure many other users of Netapp products do as well. I don't think that should make them suspect. Nor do I think ex-employees are necessarily suspect, either; if anything, I would expect them to be less supportive of their old company due to bad feelings, not more so. In some ways, I think my having worked at Netapp gives my opinions slightly more weight. I understand a bit more about the decision-making process and I know what sorts of problems we ran into using beta software and hardware. I know, for example, that Netapp tests memory it gets from its vendors and some of it fails the stress tests. As an outsider you can guess one way or the other, but having been there myself, I know the facts. My position on non-Netapp-supplied components should be clear by now. Using them means greater risk. You may be comfortable with that increased risk, and/or you may think it's too small to matter. And you may want to advocate on this list that others follow your lead. I don't mind that. Just don't mislead others into thinking the increased risk is zero. Bruce

1 0

RE: RAM and NVRAM for F330
by sirbruce＠ix.netcom.com 17 Apr '98

17 Apr '98

On 04/16/98 15:01:24 you wrote: > >On Thu, 16 Apr 1998, Weeks, Thomas wrote: > >|> >| [Weeks, Thomas] >| RAM on the filer is being run to the very MAX of its specs >|(maybe more)... I hear that they have a fairly high failure rate on RAM >|that would otherwise work FINE in slower, less demanding systems (PC's). > >I highly doubt that. Very few Netapp buyers are running PCs. Most of >us are running Sun/DEC/IBM/SGI/etc machines. The F220 is a _P75_ >based machine with *NO* L2 Cache. I hardly feel it needs 9ns ram ;) 1. It is very true that Netapp demands more from DRAM than Wintel or Alpha-based NT machines. Probably even than Intel-based Solaris boxes, but I'd be less sure of that. Disbelieve this at your own peril. 2. I'm sure that most Netapp buyers have at least one PC in their Company/School/Organization. >Our F630 is Alpha based, and i seriously doubt it is overunning its >ram. I don't know precisely what you mean by "overrunning", but it does indeed put a heavy demand on it, although my impression is that it's less so than the older Intel boxes. The memory the F630 uses is much more specialized too, so the probability of quality manufacture is probably higher. I don't know though; I've never seen a comparison of F630 memory returns vs. other models. Bruce

1 0

RE: RAM and NVRAM for F330
by sirbruce＠ix.netcom.com 17 Apr '98

17 Apr '98

On 04/16/98 11:37:53 you wrote: >I think you have a serious misunderstanding about "netapp components" >bruce. I don't think so... >Netapp uses: > >Dallas SEmiconductor NVRAM >Samsung DRAM >Seagate Hard Drives >Alteon gigabit ethernet cards >Eurologic storage shelves This is a very limited list. As I'm sure you know, they've used many other DRAMs, hard drives, storage shelves, and so on, varying both with time and with the model of the filer. >I would hardly call it "3rd party" if you buy the *EXACT* OEM >equipment netapp uses. I did not originate the term "3rd party" in this thread. Brian did; here is his original post for reference: > I've been trying to find a source for both the system RAM, and the > NVRAM for my F330. I haven't had much luck with this. None of the big > vendors (PNY, Viking, Kingston) were much help. > > Does anyone have any experience with third party RAM or NVRAM for the F330? > > I know that Stornet has a slightly better price than NetApp, but it is > still several times what I'd expect to pay for RAM. > > Thanks! > > -- > - Brian If you have a problem with the term, I suggest you take it up with him. >|Well, I guess it depends on the vendor. The thing is that while you may say >|the RAM has problems, it appears to work for them in their tests, so I could see >|them arguing over taking it back. But I suppose for some vendors it's easier >|to just throw it back in stock for the next customer. :) > >We require next day delivery from ALL our vendors. Including the >resellers we buy samsung/kingston ram from. Like I said, it depends on the vendor and how they'll react if they think they are getting spurious returns. >|I guess that's my point. If Netapp's RAM fails in a Netapp, they'll replace it. >|If the memory you buy at Fry's fails in a Netapp, the customer service guy is >|gonna look at you and say "Netwhat?" > >Oh jesus. Comparing fry's to the REPUTABLE vendors is absurd. The original poster did not qualify where you got the vendors components from, either directly or through a reseller. The above is certainly a valid scenario if customers get the mistaken impression that using 3rd party components is without increased risk. >In >truth, netapp's support/rma department has been so poor lately I am >really wondering what value add netapp really has anymore. I think this has been gone over before. You have less risk with Netapp direct. Whether or not that is worth the cost depends upon your situation. Bruce

1 0

RE: RAM and NVRAM for F330
by Weeks, Thomas 16 Apr '98

16 Apr '98

> -----Original Message----- > From: Kelly Setzer [SMTP:setzer@telalink.net] > Sent: Thursday, April 16, 1998 9:10 AM > To: sirbruce(a)ix.netcom.com > Cc: toasters(a)mathworks.com > Subject: RE: RAM and NVRAM for F330 > > > >I know that Stornet has a slightly better price than NetApp, but it > is > > >still several times what I'd expect to pay for RAM. > > > > My experience has been that if you get third-party components, they > are > > going to be less reliable. Period. > > > > That's a shame. You might try some other third-party vendors. > [Weeks, Thomas] You try any brands other that the approved list of NetApp and they wil not warranty the behavior of the system. Or so they told me. > > > > Whatever the cheaper component is, be prepared to pay double that, > because > > if the first RAM you buy fails, you'll have to buy it again and hope > the > > timing and quality is better. If the Netapp RAM fails under > support, they'll > > replace is for free. > > And this borders on the absurd. It's been a long time since I bought > RAM which > did not have a lifetime warranty. The few times I have had problems > with RAM, > the vendor has been more than happy to replace it. > > [Weeks, Thomas] RAM on the filer is being run to the very MAX of its specs (maybe more)... I hear that they have a fairly high failure rate on RAM that would otherwise work FINE in slower, less demanding systems (PC's). [Weeks, Thomas] Tom > Kelly

4 5

RE: RAM and NVRAM for F330
by sirbruce＠ix.netcom.com 16 Apr '98

16 Apr '98

On 04/16/98 09:10:23 you wrote: > >> >I know that Stornet has a slightly better price than NetApp, but it is >> >still several times what I'd expect to pay for RAM. >> >> My experience has been that if you get third-party components, they are >> going to be less reliable. Period. >> > >That's a shame. You might try some other third-party vendors. Perhaps you'd care to tell us what "others" you refer to? I've had experience with just about every vendor I can think of. What third-party vendor have you found to be more reliable than Netapp's components? Perhaps your experience with a given vendor differs from mine. >> Whatever the cheaper component is, be prepared to pay double that, because >> if the first RAM you buy fails, you'll have to buy it again and hope the >> timing and quality is better. If the Netapp RAM fails under support, they'll >> replace is for free. > >And this borders on the absurd. It's been a long time since I bought RAM which >did not have a lifetime warranty. The few times I have had problems with RAM, >the vendor has been more than happy to replace it. Well, I guess it depends on the vendor. The thing is that while you may say the RAM has problems, it appears to work for them in their tests, so I could see them arguing over taking it back. But I suppose for some vendors it's easier to just throw it back in stock for the next customer. :) I guess that's my point. If Netapp's RAM fails in a Netapp, they'll replace it. If the memory you buy at Fry's fails in a Netapp, the customer service guy is gonna look at you and say "Netwhat?" Bruce

2 1

Re: RAM and NVRAM for F330
by sirbruce＠ix.netcom.com 16 Apr '98

16 Apr '98

On 04/15/98 19:04:51 you wrote: > >I've been trying to find a source for both the system RAM, and the >NVRAM for my F330. I haven't had much luck with this. None of the big >vendors (PNY, Viking, Kingston) were much help. > >Does anyone have any experience with third party RAM or NVRAM for the F330? > >I know that Stornet has a slightly better price than NetApp, but it is >still several times what I'd expect to pay for RAM. My experience has been that if you get third-party components, they are going to be less reliable. Period. How much less reliable is hard to say. If it's a corporate resource, I wouldn't do it. If you or your boss wants something done cheap and will take increased risk, or if it's not critical for you, then perhaps it might be worth it. Whatever the cheaper component is, be prepared to pay double that, because if the first RAM you buy fails, you'll have to buy it again and hope the timing and quality is better. If the Netapp RAM fails under support, they'll replace is for free. Bruce PS - Just because RAM might appear to "work fine" in your home computer or NT server doesn't mean it will in a Netapp box.

2 1

RAM and NVRAM for F330
by Brian Marcotte 15 Apr '98

15 Apr '98

I've been trying to find a source for both the system RAM, and the NVRAM for my F330. I haven't had much luck with this. None of the big vendors (PNY, Viking, Kingston) were much help. Does anyone have any experience with third party RAM or NVRAM for the F330? I know that Stornet has a slightly better price than NetApp, but it is still several times what I'd expect to pay for RAM. Thanks! -- - Brian

1 0

Re: stale NFS file handles
by Daniel Quinlan 14 Apr '98

14 Apr '98

guy(a)netapp.com (Guy Harris) writes: > That still doesn't describe the full scenario. If somebody merely > writes to a file - in the sense of "does a 'write()' to the file" - that > will *NOT* cause ESTALE to occur on other clients - there's no reason > for it to occur. > > If the full scenario has "writes to a file" meaning "unlinks the file, > creates a new file with the same name, and writes to *that* file", > that's the scenario I described in earlier mail. Well, since the file hadn't been recently modified, I wasn't able to come up with any scenario that could apply. It looks more likely that the NetApp was sent an incorrect file handle (or didn't receive the correct one). What level of consistency checking does NFS v2 over UDP provide? > > It may be generally useful for NetApp to publish all of the known > > cases where different (legitimate to the NFS specification) errors can > > be returned from Network Appliance servers. > > "Different" in the sense of "different from, say, a Sun server"? "Different" as in "various" or "different types of errors". > I presume "overwritten" here means "removed and rewritten", as per > the above. Yes it does, please forgive my imprecise language. > If the client is assuming that a file with inode number XXXX (as > returned by an NFS "getattr" call) is the same file as a file that had > inode number XXXX on the same mount from the same client at some point > in the past, the client is buggy - it cannot validly assume that, given > the scenario I outlined in earlier mail. I'll ask the local experts about that. Linux 2.1.x (x > 42) also has a directory/file name cache that hashes names to "dentries" that include a pointer to the inode structure. - Dan

2 1

Re: stale NFS file handles
by Daniel Quinlan 14 Apr '98

14 Apr '98

guy(a)netapp.com (Guy Harris) writes: > You're not describing the full scenario here - the only operations you > mention are a write from one client and an unspecified operation from a > different client that would get an error. What's the rest of the > scenario? The most common scenario where this occurs here is for ELF executables. It may happen other places, but escape notice. It may be generally useful for NetApp to publish all of the known cases where different (legitimate to the NFS specification) errors can be returned from Network Appliance servers. For example, what set of circumstances (or client bugs) can lead to ESTALE. Another time, we had a problem running "ls -l" from client "A" on a binary that had been overwritten from client "B" while one copy of the older version was already running on "A". It was still in the directory cache, but half of the stat would fail (the directory cache lookup would give a nonexistent inode number, and the getattr would return an I/O error). > If a file that one client has open is removed while that client still > has it open, and a new file is created on the server with the same inode > number as the file that was removed, and the client that has the file > open tries to perform some operation on it via the file descriptor it > has opened for that file, it will get ESTALE (if the operation goes over > the wire to the server, which e.g. a "read()" or "stat()" might not if > it can be satisfied from a cache on the client) on most if not all UNIX > NFS servers, as well as on the filer. Yes. > The line > > fatal_error("Execv failed", strerror(errno)); > > should probably be changed to something such as > > fatal_error("Execv failed: ", strerror(errno)); > > or "fatal_error()" should be changed to add the ": ", to make the error > message look more reasonable. I agree. It's not my code, but I said about the same thing to the author. :-) > > The Linux kernel on that host also logged the error, showing: > > > > Apr 11 00:00:49 kernel: nfs_revalidate_inode: bin/xx getattr failed, > > ino=4072292, error=-116 > > It'd be interesting to see a network trace of the NFS traffic between > the client and the server, to see > > 1) what file handle was used to refer to the file on a > successful call; > > 2) what file handle was used to refer to the file on the > unsuccessful call if the latter call went over the wire. Newer versions of the Linux kernel log this information. Unfortunately, the sheer volume of NFS traffic and relative infrequency of errors makes logging this information unfeasible. > It may just be that the client is sending a bad file handle over the > wire. A possibility. Thanks for all the info. Dan

2 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