toasters

toasters@lists.teaparty.net

13531 discussions

Re: Filer and IIS
by sirbruce＠ix.netcom.com 19 Apr '98

19 Apr '98

On 04/20/98 04:38:04 you wrote: > >Mike Patchen - Verio Southern California wrote: >> >> This is a bug in IIS. MS and netapp are aware of it. Frontpage also has >> a bug where all content has to be on local disk so we cannot use our filer >> on these accounts. MS says this will be fixed in the FP99 release. >> >> We had the exact same problems you describe. >> >> -Mike Patchen >> Verio Southern California >> >> On Fri, 17 Apr 1998, Jimy Liu wrote: >> >> >But I think I did not use FrontPage. And if I use other PC(win95) as >NT's network >drive running IIS. It worked fine. Why Netapp Not ? MS may say "We can >work with Normal >network drive like win95. NetApp filer may be not Normal". It is not unusual for Microsoft to violate their own spec. I don't know specifically what is wrong in IIS, but probably the filer is advertising something perfectly reasonable (that win95 doesn't), but IIS isn't handling it correctly. If Microsoft says this is a problem with IIS, then I see no reason to doubt them. (Yes, they may initially accuse Netapp, but the impression I am getting is that they aren't doing so now.) >About two month ago, my customer ran Notes server on NT using NetApp >filer => Notes boot Fail . >If she ran Notes server on this NT using another NT's disk as network >drive => Notes boot Success. Again why filer can't ? >(ps: I hope to resolv IIS with filer first ) I know these sorts of things happened in earlier versions of the filer CIFS software. Whether or not it happens now is hard to say. I would upgrade your filer software, try it, and if it still doesn't work, contact Netapp so they can open a bug on it. Bruce

1 0

Re: Filer and IIS
by sirbruce＠ix.netcom.com 19 Apr '98

19 Apr '98

On 04/18/98 14:25:45 you wrote: > >On Sat, 18 Apr 1998, Mike Patchen - Verio Southern California wrote: >> >> This is a bug in IIS. MS and netapp are aware of it. Frontpage >> also has a bug where all content has to be on local disk so we >> cannot use our filer on these accounts. MS says this will be fixed >> in the FP99 release. > > Yup. Interestingly, if you run an NFS client on the NT server and >mount the Netapp filesystems that way, it *does* seem to work, even >though it still "looks" like a network share. There are other >problems though, with directory and file permissions, that we gave up >and went with local disks for the NT boxes. Silly Microsoft. :( I dunno... seems like Microsoft "won" to me, since you didn't abandon IIS. Instead you were coerced into a more expensive and more NT-centric solution. (Before someone questions whether or not such a solution is really more expensive, please don't... I don't want this to turn into some flamewar about Microsoft and/or NT.) Bruce

2 1

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

18 Apr '98

On 04/17/98 11:01:58 you wrote: > >sirbruce(a)ix.netcom.com wrote: >> >> As has been pointed out before, Netapp tests DRAM they get from Samsung before >> it goes out the door, and does find failures, so I can't see how Samsung direct >> could be any MORE reliable, unless Netapp somehow damages the DRAM in assembly >> or shipment. >> >> Bruce > >Maybe it may make people feel better if NetApp could supply some facts >that would show people what kind of failure rate they find on some of >the different lines of products. It is one thing to say that they find >failures, but are the failures 1 in 10 or 1 in 200? > >I would agree that if the failure rate is high (i.e. 1 in 10), then >NetApp is certianly pushing the edge of the components. BUT (and a big >but at that) if the failure rate is much lower (e.g. 1 in 100 or 200 >components), then I would tend to say that NetApp's argument for testing >does not hold any water. The small amount of failures that NetApp finds >could be attributed to manufacturing defects and delivery problems. I basically agree (I'm not sure if I'd draw the line at 1 in 200), but I would point out that if they can be attributed to manufacturing defects, then you are just as likely to get such a defect direct from the supplier. So again, going through a supplier like Samsung isn't going to be more reliable, although how much less reliable (i.e. 0.5%) may be negligible for your particular environment. It would, however, somewhat dispel the notion that the filers push the edge of the components. Bruce

1 0

Re: Data ONTAP 5.0 memory requirements
by Jason D. Kelleher 17 Apr '98

17 Apr '98

In message <Chameleon.980326065754.dpower(a)blue.insync.net>, David Power writ es: >Have you priced 630 memory lately? I was quoted $12,000 for a 32 meg >nvram, 256 meg system ram upgrade. Thats not dropping to me. We just paid NetApp $4000 to up the NVRAM on our F330 from 2MB to 8MB. That's over $650 for each 1MB SIMM! When I asked our Sales Rep about the cost, I was quoted the "We do in house testing" line. Anyway, two of the SIMMs we were sent were bad... Very disappointing. I think it'd work out best for everyone if they just published a list of "approved" vendors for memory and disk. The customers would get a better price, and NetApp would look alot nicer. jason >--- On Thu, 26 Mar 1998 17:30:52 +1100 Mike Bosch <mbosch(a)netapp.com> >wrote: > >>Marc, >> >>As I recall, Cisco was requiring 64MB and recommending 128MB on most ISP >>7500s over a year ago. Whatever......the point is that memory >requirements >>will continue to grow over time. >> >>The good news is that as more features have required more memory, the >price >>of memory has dropped at an even faster rate. >> >>MJB >> >> >>At 22:21 25/03/98 -0500, Marc Nicholas wrote: >>>On Thu, 26 Mar 1998, Mike Bosch wrote: >>> >>>> A Filer is generically much more like a router than a general purpose >Unix >>>> or NT box, but we still require much less space than Cisco's IOS, for >>example. >>> >>>Excuse me? You require less memory than IOS? Did I suddently reappear >in >>>another universe where IOS requires 128mb to run? :-p >>> >>>You can even run a couple of full BGP views in a Cisco with 64mb -- and >>>that's to compensate for Cisco's braindead table archietecture. >>> >>> >>>-marc >>> >>>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>>Hippocampus OSD, Inc. "Industrial Strength Internet Solutions" >>>vox://416.979.9000 fax://416.979.8223 http://www.hippocampus.net >>> >>> >>> >> >> >>-------------------------------------------------------------------------- >-- >>------ >> >>Mike Bosch >>Regional Manager >>Network Appliance Australia - New Zealand >> >>Phone: 61-41-728-7345 >>Email: mbosch(a)netapp.com >> >> >>********************************************************************* >> FAST SIMPLE RELIABLE MULTI-PROTOCOL >>********************************************************************* >> >> >>-------------------------------------------------------------------------- >-- >>------ >> >> > >-----------------End of Original Message----------------- > > >David Power >V-P Operations >Insync Internet Services Inc. > >

9 9

fcal filers?
by Alexei Rodriguez 17 Apr '98

17 Apr '98

Has anyone ordered or taken delivery of such a beast yet? How is it? Alex

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: > >On Thu, 16 Apr 1998 sirbruce(a)ix.netcom.com wrote: > >|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. > >I think you have a serious misunderstanding about "netapp components" >bruce. > >Netapp uses: > >Dallas SEmiconductor NVRAM >Samsung DRAM >Seagate Hard Drives >Alteon gigabit ethernet cards >Eurologic storage shelves > >I would hardly call it "3rd party" if you buy the *EXACT* OEM >equipment netapp uses. > Oh, I see what you are getting at now... as if "netapp components" don't come from a third-party vendor in the first place. I'm afraid you're the one who misunderstood; within the context of the discussion, we were distinguishing between the original vendor of the component and getting it straight from Netapp itself. Thus, when I say third-party components are less reliable, I mean "If you get Samsung DRAM from Samsung, it's going to be less reliable than if you get Samsung DRAM from Netapp" in this context. You suggested another vendor was required; perhaps you didn't think I meant Samsung in the first place. But that's what I asked... what vendor do you think is more reliable, or at least the same reliability, getting it direct than from Netapp? In other words, are you saying the Samsung memory you get direct from Samsung is more reliable than the Samsung DRAM you get from Netapp? As has been pointed out before, Netapp tests DRAM they get from Samsung before it goes out the door, and does find failures, so I can't see how Samsung direct could be any MORE reliable, unless Netapp somehow damages the DRAM in assembly or shipment. Bruce

2 1

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 16 Apr '98

16 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

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

14 Apr '98

hitz(a)netapp.com (Dave Hitz) writes: > The ESTALE error simply means that the server couldn't find any file > for a given file handle. If a client writes to a file, but the inode number does not change, would a different client receive ESTALE or a different error? Anyway, the reason I'm asking all this is because I'm at a loss to explain the following sequence of events. First, a daemon "xx" failed as follows: Sat Apr 11 00:00:48 1998 xx: (INFO) Removing old directories Sat Apr 11 00:00:49 1998 xx: (INFO) Done removing old directories Sat Apr 11 00:00:49 1998 xx: (INFO) Daemon is using 7024 Kb (limit is 7000) - restarting Sat Apr 11 00:00:49 1998 xx: (INFO) next instruction is execv(...self...) Sat Apr 11 00:00:49 1998 xx: (SEVERE ERROR) Execv failedStale NFS file handle Sat Apr 11 00:00:49 1998 xx: (INFO) Dropping core in directory /xxx/yyy 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 Unfortunately, this version of the kernel doesn't show the "before" and "after" NFS filehandles, but the server did return ESTALE (error=-116 in Linux) according to the kernel. (The NetApp server logs don't show anything intereresting around this time.) The weird part is that all three timestamps for "xx" precede April 11 00:00:49 by a wide margin. $ ls -ali /foo/bar/bin/xx* 4072292 -rwx------ [...] Apr 10 13:11 /foo/bar/bin/xx 1161604 -rwx------ [...] Apr 10 11:22 /foo/bar/bin/xx.old Here is the code sequence that was running on the "xx" daemon when it received ESTALE when it tried to re-execute itself (it had been running since April 8). ------- start of cut text -------------- void re_exec_daemon(void) { char buf[TMP_BUF_SIZE]; disconnect(); if (close(Admin_sock) == -1) { sprintf(buf, "Can't close admin socket (%s)", strerror(errno)); log_mesg(ERROR, buf); } if (close(User_sock) == -1) { sprintf(buf, "Can't close user socket (%s)", strerror(errno)); log_mesg(ERROR, buf); } /* jump to directory we started from */ if (chdir(Invoke_dir) == -1) { sprintf(buf, "Can't change to directory %s", Invoke_dir); fatal_error(buf, strerror(errno)); } /* make sure sockets are closed */ (void) close(Admin_sock); (void) close(User_sock); log_mesg(INFO, "next instruction is execv(...self...)"); /* Re-execute us */ execv(Invoke_command[0], Invoke_command); /* should not get here */ fatal_error("Execv failed", strerror(errno)); } ------- end ---------------------------- Dan

2 1

stale NFS file handles
by Daniel Quinlan 13 Apr '98

13 Apr '98

Could someone from NetApp list the circumstances under which a Network Appliance server will return the NFS RPC ESTALE error? I'm specifically interested in NFS v2, but a v3 listing would be nice if it's different. Thanks. - Dan

3 3

snmpwalk on NetApp 5.0 problem
by Daniel Quinlan 13 Apr '98

13 Apr '98

We seem to be unable to use snmpwalk on NetApp 5.0 and 5.0R1. We're using UCD-snmp version 3.3.1 to retrieve data as well as the latest out-of-date NetApp MIB. SNMP works fine for us on 4.3.1 and earlier versions. The problem is that we can't walk the entire SNMP tree -- it fails after barely starting. It does seem possible to access later portions of the tree, but only if you know they exist and ask specifically for a smaller part of the tree. Here's the UCD-snmp environment variables we're using: export MIBFILE=/usr/local/share/snmp/mibs/netapp.mib export PREFIX=.iso.org.dod.internet.private.enterprises I was wondering if anyone else does or does not have this problem. Thanks for any info. - Dan

1 0

RE: 4GB/9GB shelf migration from toaster A to toaster B.
by grant＠netapp.com 10 Apr '98

10 Apr '98

Hi Thomas, > [Weeks, Thomas] > What's this multivolume thing? > From 5.0 Data ONTAP has support for multiple filesystems on each filer. Each filesystem is termed a volume and each volume has support for multiple raid groups, i.e. more than one (parity + data) disk set. So now (well soon) you can take your TB+ filer and configure it with 5+ x 200GB volumes, etc And you can download 5.0R1 from NOW today! The major features in Release 5.0R1 are support for Multiple Raid Groups, Multiple Volume File systems and Fibre Channel disks. > > [Weeks, Thomas] > When we bought a new filer (FAS1400-->FS230) we just used > NDMPcopy to go from the old filer to the new filer... > > We got around 5Mbps xfer rates, powered down the old server, > powered up the new server and ran.. keeping the old server in the rack > for a week just in case. > Cool! Just so you know with 4.3 releases you can migrate a whole filer even faster by asking your S.E. to turn up with his Bare Metal Migrate floppies and it supports FAS1400 hardware! Cheers, Grant

1 0

450 and a network switch
by Mark Richards 10 Apr '98

10 Apr '98

Hello I'm having a problem with my 450 (running 4.3.3) when it is connected to a LanCast 10mbp switch. Put simply. performance is terrible when switch is in my network and clients are acessing the 450 (which is attached to the switch with a crossover cable). If I remove the the switch from the network, all is well. I've sent the switch back to be tested and it is fine. Other UNIX servers in my network give great performance with or with the switch as do the clients. I've thought about half/full duplex issues on the 450's ethernet but its set correctly on the netapp and I've read that the 450 does support full-duplex anyway. Any ideas as to why my 450 doesn't like the switch? Regards Mark Richards

3 2

Re: 4GB/9GB shelf migration from toaster A to toaster B.
by sirbruce＠ix.netcom.com 10 Apr '98

10 Apr '98

On 04/09/98 16:50:02 you wrote: >Here's my theory as to the cause (translation: guess): > >The netapp mirrors the OS on the header of all the disks. > >At least half of the disks must have the same OS copy/version/checksum/magic-number >in order for the netapp to boot correctly (guess #1) Well, if true, this would have to be a new thing with respect to the OS version... it would just boot whatever OS it found "first". The "first" disk is usually the same every reboot, but circumstances (as well as simple chance) can change this. You're right about the magic-number stuff, but I think there is more than one magic-number to consider. >The "vol destroy" uses a hardware-quick-erase feature which blows away the whole >disk, not just the data portion. This blows away the OS portion of the disk. > >Viola! After a vol destroy on 22 of my 24 disks, I now have a valid OS on less >than half the disks. Non-floppy boots fail until I get it up with a floppy, and >run download (but no data is lost). The only thing that doesn't make sense to me in this theory is that if the header is invalid, then the disk will just show up as such and have to be reinitialized. But there are various types of headers on the disks and they are looked at in different ways, so the matter is probably much more complicated. My guess is the vol destroy just isn't handling the header correctly, not that the software isn't getting downloaded to it. (The latter might also be true.) Bruce

1 0

Re: 4GB/9GB shelf migration from toaster A to toaster B.
by grant＠netapp.com 10 Apr '98

10 Apr '98

Hi Jim, Jim Davis <jdavis(a)CS.Arizona.EDU> writes: > Potential plan: buy a shelf of 9GB disks, put it on toaster A, move a > shelf of 4GB disks to toaster B, keeping all of the toaster A data on > toaster A. Toaster B ends up with an empty file system on its 4GB disk > shelf. > > Now the mechanics of the move are a little unclear to me. Presumably we > hook up the 9GB shelf to toaster A and 'raid fail' each 4GB disk in the > shelf we want to move? But there will be 5 9GB data disks, since we have > to burn one as a hot spare and one becomes the new parity disk. Will > there be a problem with having 7 disks to move data from, but only 5 disks > to move data to? There would be enough GBs on the 5 9GB disks, but... I'd propose this plan of action: Buy enough 9GB disks to support all data resident on 4GB disks. Install Data ONTAP 5.0. Attach 9GB disks and create second volume. Run NDMPcopy to transfer vol0 -> vol1 (special care required if you use incrementals). Make vol1 the root volume Offline & destroy vol0 after vol1 deemed okay! Break up 4GB disks between filer A & B. Create second volume on Filer A using leftover 4GB disks. Alternative is: dump data to tape (quota trees would be useful) Break up 4GB disks between filer A & B Add 2 volumes to Filer A using 4GB & 9GB disks restore from tape to any volume (again quota trees would be useful) You have to get *all* the data off the 4GB disks before you can free any of them up (as Dan already pointed out). We don't have an EVACUATE command. Note for the future: We aim to have a volume copy command in a future release that will allow a larger volume (measured by disk capacity) to be transferred to a smaller volume (measured by disk capacity) as long as the resident data will fit. You will need to use NDMPcopy to transfer the volume if you do it with one filer and multiple volumes since BareMetal Migrate is only available in the 4.3. software release. With two (single volume) filers in play BareMetal Migrate is just the ticket. Cheers, Grant

2 1

Re: Fun with NDMP
by grant＠netapp.com 09 Apr '98

09 Apr '98

Hi Tripp, > > I have successfully (I think) ported ndmpcopy to Digital Unix, > Cool! Any chance you can contribute your changes back to ftp.ndmp.org. If you leave the code in /incoming. I'll make sure it makes its way to the contrib directory. > > but I am running into some problems trying to initiate a copy. > Boo. Hiss. > > adminhost# ./ndmpcopy srcfiler:/ms/ftp destfiler:/ftp -sa > root:passwd -da root:passwd -level 0 -v > > srcfiler> Thu Apr 9 17:09:12 EDT [ndmp_session_0]: > ../common/ndmpd/mover.c:1169 ndmpdMoverConnect: connect error: > No route to host > > destfiler> Thu Apr 9 21:09:12 GMT [ndmp_session_0]: > ../common/ndmpd/mover.c:1169 ndmpdMoverConnect: connect error: > Can't assign requested address > > I can ping destfiler from srcfiler and vice-versa. > The output below shows me that the mover on the destination is still listening for a NDMP data connection to be initiated by the source machine. Obviously the DEC client can see both filers, but perhaps the filers can't see each other on these addresses without a route being added. You can check that all ip addresses are consistent on each machine. I know that I will change the local hosts file on a filer here to talk to a server that the filer knows as server1 (111.222.333.12) whereas the yp map on all other clients will be server1 (222.333.111.70) and server1-333 (111.222.333.12). Alternatively, you could use the -dhost option with NDMPcopy and provide the ip address of the destination filer. You get this value from running ping -s destfiler from srcfiler. BTW, you can generate a bunch of (pretty cryptic) debug by running: rc_toggle_basic ; dbg level ndmpd=0xffff ; rc_toggle_basic. To turn off again run: rc_toggle_basic ; dbg level ndmpd=0x0 ; rc_toggle_basic Hope this helps. Let me know how you get on or if you have any more questions. > > Here's some interesting information: > > srcfiler> ps > [...] > 3687 BR 0% 2160 13% ndmpd > 3688 ?? 0% 3888 11% ndmp_session_0 > 3689 BR 0% 256 0% ndmp_session_1 > 3690 BR 0% 256 0% ndmp_session_2 > 3691 BR 0% 256 0% ndmp_session_3 > 3692 BR 0% 528 1% ndmp_session_4 > [...] > > destfiler> ps > [...] > 3692 ?? 0% 4112 12% ndmp_session_0 > 3693 BR 0% 208 0% ndmp_session_1 > 3694 BR 0% 208 0% ndmp_session_2 > 3695 BR 0% 208 0% ndmp_session_3 > 3696 BR 0% 208 0% ndmp_session_4 > [...] > > srcfiler> ndmpd status > ndmpd ON. > Session: 0 > Active > tape device: not open > data state: Idle > data operation: None > mover state: Idle > > destfiler> ndmpd status > ndmpd ON. > Session: 0 > Active > tape device: not open > data state: Idle > data operation: None > mover state: Listen > > srcfiler> ndmpd probe 0 > ndmpd ON. > Session: 0 > pid: 0xfffffc00006432f0 > isActive: TRUE > eof: FALSE > authorized: TRUE > spt.device_id: -1 > spt.ha: -1 > spt.scsi_id: -1 > spt.scsi_lun: -1 > tape.id: -1 > tape.device: not open > recordCount: 0 > tape.mode: Read only > mover.state: Idle > mover.mode: Read > mover.pauseReason: N/A > mover.haltReason: N/A > mover.dataWritten: 0 > mover.seekPosition: 0 > mover.bytesLeftToRead: 0 > mover.windowOffset: 0 > mover.windowLength: 18446744073709551615 > mover.position: 0 > mover.discardLength: 0 > mover.recordSize: 64512 > mover.recordNum: 0 > mover.rIndex: 0 > mover.wIndex: 0 > data.operation: None > data.state: Idle > data.haltReason: N/A > data.pauseReason: N/A > data.abort: FALSE > data.mover.addr_type TCP > data.mover.addr 0xc0003f0d > data.mover.port 1046 > data.readOffset: 0 > data.readLength: 0 > > destfiler> ndmpd probe 0 > ndmpd ON. > Session: 0 > pid: 0xfffffc00007299f0 > isActive: TRUE > eof: FALSE > authorized: TRUE > spt.device_id: -1 > spt.ha: -1 > spt.scsi_id: -1 > spt.scsi_lun: -1 > tape.id: -1 > tape.device: not open > recordCount: 0 > tape.mode: Read only > mover.state: Listen > mover.mode: Write > mover.pauseReason: N/A > mover.haltReason: N/A > mover.dataWritten: 0 > mover.seekPosition: 0 > mover.bytesLeftToRead: 0 > mover.windowOffset: 0 > mover.windowLength: 18446744073709551615 > mover.position: 0 > mover.discardLength: 0 > mover.recordSize: 64512 > mover.recordNum: 0 > mover.rIndex: 0 > mover.wIndex: 0 > data.operation: None > data.state: Idle > data.haltReason: N/A > data.pauseReason: N/A > data.abort: FALSE > data.mover.addr_type TCP > data.mover.addr 0x0 > data.mover.port 0 > data.readOffset: 0 > data.readLength: 0 > > Any help or ideas would be greatly appreciated. > > Tripp > > Cheers, Grant

1 0

Fun with NDMP
by Tripp Cox 09 Apr '98

09 Apr '98

I have successfully (I think) ported ndmpcopy to Digital Unix, but I am running into some problems trying to initiate a copy. adminhost# ./ndmpcopy srcfiler:/ms/ftp destfiler:/ftp -sa root:passwd -da root:passwd -level 0 -v srcfiler> Thu Apr 9 17:09:12 EDT [ndmp_session_0]: ../common/ndmpd/mover.c:1169 ndmpdMoverConnect: connect error: No route to host destfiler> Thu Apr 9 21:09:12 GMT [ndmp_session_0]: ../common/ndmpd/mover.c:1169 ndmpdMoverConnect: connect error: Can't assign requested address I can ping destfiler from srcfiler and vice-versa. Here's some interesting information: srcfiler> ps [...] 3687 BR 0% 2160 13% ndmpd 3688 ?? 0% 3888 11% ndmp_session_0 3689 BR 0% 256 0% ndmp_session_1 3690 BR 0% 256 0% ndmp_session_2 3691 BR 0% 256 0% ndmp_session_3 3692 BR 0% 528 1% ndmp_session_4 [...] destfiler> ps [...] 3692 ?? 0% 4112 12% ndmp_session_0 3693 BR 0% 208 0% ndmp_session_1 3694 BR 0% 208 0% ndmp_session_2 3695 BR 0% 208 0% ndmp_session_3 3696 BR 0% 208 0% ndmp_session_4 [...] srcfiler> ndmpd status ndmpd ON. Session: 0 Active tape device: not open data state: Idle data operation: None mover state: Idle destfiler> ndmpd status ndmpd ON. Session: 0 Active tape device: not open data state: Idle data operation: None mover state: Listen srcfiler> ndmpd probe 0 ndmpd ON. Session: 0 pid: 0xfffffc00006432f0 isActive: TRUE eof: FALSE authorized: TRUE spt.device_id: -1 spt.ha: -1 spt.scsi_id: -1 spt.scsi_lun: -1 tape.id: -1 tape.device: not open recordCount: 0 tape.mode: Read only mover.state: Idle mover.mode: Read mover.pauseReason: N/A mover.haltReason: N/A mover.dataWritten: 0 mover.seekPosition: 0 mover.bytesLeftToRead: 0 mover.windowOffset: 0 mover.windowLength: 18446744073709551615 mover.position: 0 mover.discardLength: 0 mover.recordSize: 64512 mover.recordNum: 0 mover.rIndex: 0 mover.wIndex: 0 data.operation: None data.state: Idle data.haltReason: N/A data.pauseReason: N/A data.abort: FALSE data.mover.addr_type TCP data.mover.addr 0xc0003f0d data.mover.port 1046 data.readOffset: 0 data.readLength: 0 destfiler> ndmpd probe 0 ndmpd ON. Session: 0 pid: 0xfffffc00007299f0 isActive: TRUE eof: FALSE authorized: TRUE spt.device_id: -1 spt.ha: -1 spt.scsi_id: -1 spt.scsi_lun: -1 tape.id: -1 tape.device: not open recordCount: 0 tape.mode: Read only mover.state: Listen mover.mode: Write mover.pauseReason: N/A mover.haltReason: N/A mover.dataWritten: 0 mover.seekPosition: 0 mover.bytesLeftToRead: 0 mover.windowOffset: 0 mover.windowLength: 18446744073709551615 mover.position: 0 mover.discardLength: 0 mover.recordSize: 64512 mover.recordNum: 0 mover.rIndex: 0 mover.wIndex: 0 data.operation: None data.state: Idle data.haltReason: N/A data.pauseReason: N/A data.abort: FALSE data.mover.addr_type TCP data.mover.addr 0x0 data.mover.port 0 data.readOffset: 0 data.readLength: 0 Any help or ideas would be greatly appreciated. Tripp

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