toasters

toasters@lists.teaparty.net

13531 discussions

Re: Does the netapp support etherchannel/trunking?
by Sam Cramer 01 Sep '99

01 Sep '99

> Ehhhh, I'm still having problems with ifconfig of virtual interfaces. I > tried "ifconfig eta partner eta" and it took, although I don't know what > that means semantically. This means: in takeover mode, have the local "eta" interface takeover for the partner "eta" interface. > Then I came up with another enlightened idea "ifconfig eta -partner > 10.10.10.11" that does not do what "ifconfig eta partner 10.10.10.11" did > in the past (Oh, BTW, thanks NetApp for changing the syntax of the > command between revs). "partner" and "-partner" mean different things. "partner" specifies the takeover interface mapping; the argument after the "partner" keyword specifies the interface that should be taken over. "-partner" clears such a mapping, and takes no argument. These keywords were introduced in 5.2; we haven't changed the meaning of them since. "ifconfig" consumes its arguments one at a time, processing a keyword (and arguments, if applicable) and progressing on to the next keyword. Thus, when you specified "ifconfig eta -partner 10.10.10.11", "ifconfig" parsed it as follows: ifconfig eta -partner # clear the eta partner mapping ifconfig eta 10.10.10.11 # set eta's address Granted, this is somewhat counter-intuitive. > I should add that I tried "ifconfig eta partner 10.10.10.11" before only > to receive this error: > ifconfig: 10.10.10.11: bad vif partner address This is a very poor error message which will be fixed in an upcoming release. Partner mapping for vifs and ATM must be specified by interface name only; partner mapping for other interfaces can be specified by IP address or interface name. The error message is trying to tell you, in a round-about way, that you've specified a IP address, not an interface name. Thanks for your feedback; please don't hesitate to bring other such issues to our attention. Sam

1 0

Re: Parts source for end of life products?
by sirbruce＠ix.netcom.com 31 Aug '99

31 Aug '99

On 08/31/99 14:10:34 you wrote: >On Tue, 31 Aug 1999 sirbruce(a)ix.netcom.com wrote: > >> >If the difference is so great NetApp should be proud to publish >> >their statistics without an NDA. >> >> If that were the case, every company should publish all of their internal >> practices. > >We are definitely, not on the same channel. I said nothing about their >practices. How they obtain the results was not a concern of mine. As >long as they publish the results they can make claims based on them. If >they don't publish such results any claims are just spin. No, publishing results *without* saying how those results were obtained is spin. By your suggestion, you have no problem if Auspex claims to get 10 million NFS ops @ 1.2ms. All they have to do is publish the data and don't have to say how they got it. But I suppose that's too general. We were talking specifically about publishing certain reliability statistics. To my knowledge, Netapp has done so, and claimed 99.99x% reliability. No, they didn't break it down by each component. Given how other vendors treat the same issue, I don't feel Netapp should produce more results to show that their memory in particular is more reliable. I also feel that doing so would only beg the question of how the results were obtained so someone else could try to reproduce them, and that's when you get into publishing internal practices. >> So long as Netapp catches at least one bad >> memory chip before it gets to the customer, my statement is strictly >> true, no matter any data to the contrary. > >No, any claims that NetApp memory is significantly superior to others is >not true in this case. One module out of thousands is hardly meaningfull >statistical data. I don't think I ever claimed 'significant'. I feel it is significant enough to mention, but you questioned that it was FUD and that it ever happened at all. I disproved that. As to exactly how many modules per thousand is enough to be 'significant', that's for you to decide. If you want the exact data, again, I suggest you ask Netapp, not me. I can only tell you what I know to be true. >> (Unless, I suppose, you can >> claim the testing somehow damages memory that otherwise wouldn't fail.) > >Ahh, you read my mind. It is unlikely that they would damage a lot of >memory during testing, but damaging one is certainly plausible. Such >mishap would nullify a benefit of one module described above. I don't think it's very plausible that the module could be damaged in testing in such a way that it doesn't fail at Netapp, but will fail at the customer site. There is another side to this... a customer who does not load their filers the 'right' way may be able to run fine with directly supplied memory that normally would not survive Netapp testing. However, I do not think this should be allowed to skew the data; the customer would still see failures under the right circumstances. I don't think Netapp should be faulted because they test their memory under conditions the customer's filer may never experience, to ensure it's reliability under those conditions. >> Perhaps you live in some magical candyland of perfect management. Or >> perhaps you are simply a beneficiary of this new age of low unemployment. >> However, people have indeed been "axed" for buying failing memory (and >> other parts) for the equipment vendor. > >That may be true, but I bet you there were a lot less (percentage wise) of >those cases than cases where someone purchased third party components all >other factors held the same. I bet you there aren't, because those "other factors" *aren't* the same, and the third party component really was less reliable. >> Different curve but the same principle. While most of the failures do >> follow the curve you describe, there are still the "out of spec" failures >> like the memory ones that happen strictly because of loading, not burn-in >> time. Many drives that fail in a Netapp can be used in your SCSI PC for >> years without any problems, because they don't talk to the drive in the >> same way. > >I don't disagree with you on this point in reference to drives. I never >did. I bet that drives are still the most likely component to fail in a >computer system. That I don't know. My point is simply distribution curve aside, memory has "out of spec" failures just like drives do, aside from "burn-in" failures, and Netapp's testing catches the former for memory that is not caught by Kingston, et al. Or at least, it *did* at one time. >> Ahh, I see. You have personaly axe to grind against Netapp, so you >> just want to toss in a snipe at every opportunity. Sorry, I thought >> you were interested in a serious discussion. > >No, I simply stated that one of the drives failed. No big deal, this >happens quite often with other manufacturers. And why didn't you just simply state all the drives that didn't fail? Don't play innocent; you weren't just making a casual remark. >> No duh. Guess what - memory in groups must also behave in a way as not to >> disturb the other memory (and other stuff going on on the motherboard). > >I don't think memory is as likely to influence other modules especially >that the modules today are of relatively high density which means that >you'll only have a couple of pieces of memory per system, number that >is significantly smaller than drives. I'm not sure; one could argue that although reduced in number, memory is more tightly coupled to other memory than a drive is to another drive. It all depends on exactly what the problem is you're talking about. But in either case it's irrelevant; more likely or less, the point is still true that these are issues for memory as well as disk, and if you think Netapp testing catches those issues for disk, you should accept Netapp testing catches those issues for memory. >Now, since this is leading nowhere, it's time to end the polemics. I agree. Bruce

2 1

Re: Parts source for end of life products?
by sirbruce＠ix.netcom.com 31 Aug '99

31 Aug '99

On 08/30/99 23:39:25 you wrote: > > >On Mon, 30 Aug 1999 sirbruce(a)ix.netcom.com wrote: > >> Netapp does additional testing and gets some memory >> to fail before selling it to you, the consumer. Statistically the >> memory you get from Netapp has to have a lower failure rate. > >As far as I remember memory failure follows Poisson distribution implying >that failures are just as likely to occur at any time. Since memory >failure rates are low and absolescence period is quite short memory >companies can guarantee memory for lifetime. Virtually every large memory >company carries a product with such warranty. This fact doesn't change the fact that some memory produced is not up to specifications. The memory may only "fail" under certain loading and timing constraints. For many manufacturers, this simply means it gets qualified and sold at a lower speed (high ns) much like CPUs. The point is the testing they do in-house is often not sufficiently thorough to duplicate the loading conditions of Netapp's requirements. I don't think Netapp's requirements are "out of spec" either; they are simply strict. >I would be interested in >the failure rate of "NetApp" memory in contrast to "normal" Kingston >memory. If the difference is so great NetApp should be proud to publish >their statistics without an NDA. I feel that NDAs, aside from pre-release >announcements, are generally a way for companies to hide their >shortcommings. If that were the case, every company should publish all of their internal practices. The fact is they don't. So long as that continues to be the business climate, Netapp would be foolish to put themselves at a disadvantage. The NDA is also there to prevent competitors from finding out how Netapp does things so well and then copying it. >General science is done by publishing and peer review not >through secrets. Netapp is not in the business of doing general science, they are in the business of making money. I, as an investor, am quite happy they limit their "science" to only those things that will help revenue generation. If they feel doing a report on their memory testing will do so, great. If they do not, great. I have confidence in their management. >> If the testing didn't do anything, why would Netapp bother? > >Claims of memory testing value and memory superiority over other brands >are greatly exaggerated by EVERY vendor. I've used inexpensive memory in >systems that have been up for ages and expensive memory that failed >miserably after several months in service. In the last year alone I >replaced *GIGABYTES* (Really, I am NOT exaggerating) of what was supposed >to be top quality memory certified by a large system vendor. "Our memory >is much better than someone else's memory" - mostly bunk! So you have had some bad experiences... I never claimed otherwise. But your particular bad luck (or perhaps, poor choice of vendors) does not disqualify my experience. So long as Netapp catches at least one bad memory chip before it gets to the customer, my statement is strictly true, no matter any data to the contrary. (Unless, I suppose, you can claim the testing somehow damages memory that otherwise wouldn't fail.) >The primary purpose of purchasing memory from equipment vendors is the >upkeep of warranties and service. It is also the cost of covering your >behind. Chances of getting axed because you bought failing memory from >the equipment vendor are next to nil. Perhaps you live in some magical candyland of perfect management. Or perhaps you are simply a beneficiary of this new age of low unemployment. However, people have indeed been "axed" for buying failing memory (and other parts) for the equipment vendor. >Chances of being axed if the memory >happens to be third party even with the same or lower failure rate as >OEM's are astronomically higher. I disagree. >> The same goes for the disk drives. > >Hard drives follow a different curve. They are very likely to die at the >very beginning and after a certain time in service. Burning in drives at >the beginning of their life greatly increases the odds that surviving >drives will have a low failure rate during the service period. The last >thing you want to do is send a customer a drive that will fail in the >first weeks of service. Different curve but the same principle. While most of the failures do follow the curve you describe, there are still the "out of spec" failures like the memory ones that happen strictly because of loading, not burn-in time. Many drives that fail in a Netapp can be used in your SCSI PC for years without any problems, because they don't talk to the drive in the same way. >I've had those too even from NetApp, but one can >always blame transportation even though the drives should withstand >several G's of shock and they're usually tucked into globs of foam. Ahh, I see. You have personaly axe to grind against Netapp, so you just want to toss in a snipe at every opportunity. Sorry, I thought you were interested in a serious discussion. >In addition, drives in arrays must behave in a way as not to disturb other >drives. No duh. Guess what - memory in groups must also behave in a way as not to disturb the other memory (and other stuff going on on the motherboard). >> Jeff Sloan has said they've now certified certain "direct from vendor" >> parts to be as good as Netapp supplied memory. My guess is either >> they have stepped down their internal testing, or the difference in >> failure rate has become too minimal to matter. > >Exactly! Regardless, I stand by my statement as having been true until whichever of the events above ocurred, which had to have been within the past year or two. >BTW, how many statisticians does NetApp employ to collect and >thoroughly analyze their data? Is there an audit of the results similar >to the scrutiny financial reports are given? Again, you could probably find out such information with an NDA, if they are willing to give it. There are certainly people in customer support responsible for tracking reliability data and breaking it down by components, filer, OS, etc. Bruce

2 1

Re: Does the netapp support etherchannel/trunking?
by tkaczma＠gryf.net 31 Aug '99

31 Aug '99

On Mon, 30 Aug 1999, Arthur Darren Dunham wrote: > NFS, CIFS, and HTTP requests are stored with the incoming interface. > Their response is sent via the same interface. > > That means that if the switch is round-robining the requests, the > responses will also be pretty well distributed. What happens when a request is larger than one ethernet frame? What happens if the response is larger than one ethernet frame. What happens if you send another request in while the first request is being output? I don't believe that the NetApp implementation rememebers the interface on which the request came in. I think that it simply remembers the last interface on which a packet came in from a certain host. A sort of "arp" table. > If the requests are bunched up, so will the responses. But the requests are a lot smaller than the responses so the one interface will be flooded while others will be sitting idle, right? > Is there any way to force a Cisco switch to round-robin traffic to a > netapp like this? The one time I played with this configuration, the > traffic was not well balanced at all. I thought you said that it was pretty well distributed. Tom

2 1

Parts source for end of life products?
by mitch＠netline.com 31 Aug '99

31 Aug '99

Greetings. I waded through the "toaster" archives hoping to get a list of vendors which sell parts for EOL'ed toasters but had no such luck. Specifically, I have an F210 which has 64Mb RAM and one shelf full of 4Gb hard disks. I'd like to upgrade it to the lastest OS release and get some more disk on it. Upgrading will require an additional 64Mb of RAM and for storage I either have to find a storage shelf and some more 4Gb disks, or replace the 4Gb disks I have with 9Gb drives. Since rack space is at a premium, I'd just as soon move to 9Gb disks but cost and availability are likely to be the deciding factors in the end. Suggestions? -- do svidaniya, ~mitch

2 1

Cluster Problems with second level virtual interfaces
by Stoltz 31 Aug '99

31 Aug '99

Hi folks, I've got two clustered F740s here with second level virtual interfaces configured for failover. The failover works fine on 5.3D20, but we've been unable as of yet to get it to work with anything 5.3.1 and beyond. We'd really like to move to 5.3.2D3 since it includes a fix to the ever-annoying NDMP file descriptor leak which makes it necessary to reboot our filers every week. I've tried moving forward to 5.3.2D3 several times for testing purposes, and it's yielded some very peculiar results, ranging from dropping both boxes off the network on takeover to what seems like some sort of persistence of nonexistent vif configs accross reboots. As I say, very peculiar. The netapp folks are equally puzzled. I'm really tired of hearing the phrases "that can't be" or "that makes no sense" (mostly from myself :P ). My question is, has anyone else gotten this configuration to work successfully in 5.3.2? Is anyone else using this configuration or something similar with trunked failover of interfaces in a cluster? Has anyone else been rebooting their boxes once a week for 3 months while they wait for a fix? # Setup trunk1. # ifconfig e0 mediatype 100tx-fd ifconfig e3a mediatype 100tx-fd vif create multi trunk1 e0 e3a # Setup trunk2. # ifconfig e3c mediatype 100tx-fd ifconfig e3d mediatype 100tx-fd vif create multi trunk2 e3c e3d # Setup second level trunk. # vif create single secondlev1 trunk1 trunk2 vif favor trunk1 # Configure for failover. # ifconfig secondlev1 partner secondlev2 # Bring up secondlev1. # ifconfig secondlev1 `hostname`-11 netmask 255.255.255.0 The partner is of course the same except for the names of the trunks and the names in the setup and configuration of the second level trunk. As I say, works fine in 5.3D20, broken as hell in 5.3.1 and beyond. Frustrated, Mark Stoltzfus Susquehanna Partners

1 0

Re: Parts source for end of life products?
by sirbruce＠ix.netcom.com 31 Aug '99

31 Aug '99

On 08/30/99 16:41:59 you wrote: > > > >On Mon, 30 Aug 1999 sirbruce(a)ix.netcom.com wrote: > >> A cautionary note - much of the supposedly "in-spec" memory Kingston >> or other vendors sell is not capable of handling the strict timing >> and loading requirements of a Netapp filer. > >This sounds like FUD. In fact it sounds like something Kingston would say >about other memory vendors. Do you have data to substantiate this? I'm sure Netapp might provide the data under NDA if you asked. I was speaking personally, however. I have *personally* seen tested Kingston memory come in and fail during internal testing on a filer. I have *personally* seen Netapp test filers they build for customers and have the memory in them fail and have to be replaced and re-tested before shipping to the customer. I have *personally* seen filers experience crashes and spontaneous reboots due to having the right memory in the right slots. I have *personally* seen the poor timing traces on oscilliscopes as EE's examines the problem. >I'm >not saying don't buy memory from NetApp. We buy it there and will >continue to buy it there because we want to maintain our service >agreements. However, since you're making claims that memory sold by >NetApp is superior please show me the data from an independent source. How could an independent source exist? You ask the impossible. But if you could get the data from all customers and somehow verify the source of the memory in them, I think you'd see a difference. It just stands to reason. Kingston sells memory to Netapp that has a certain known possibility of failure. Kingston sells that same memory to you, the consumer. Netapp does additional testing and gets some memory to fail before selling it to you, the consumer. Statistically the memory you get from Netapp has to have a lower failure rate. If the testing didn't do anything, why would Netapp bother? The same goes for the disk drives. Jeff Sloan has said they've now certified certain "direct from vendor" parts to be as good as Netapp supplied memory. My guess is either they have stepped down their internal testing, or the difference in failure rate has become too minimal to matter. Bruce

3 2

Re: OS releases
by Tom Yates 31 Aug '99

31 Aug '99

On Mon, 30 Aug 1999, Graham C. Knight wrote: > I suppose i could start my own NetApp OS mailing list and call tech > support for a weekly OS status. :-) Whaddya think? it's not worth the pain. trust me on this. that being said, a periodic "new release" announcement strikes me as very useful. once every week or two, a tiny summary of what's come out of the ONTAP mothership, say. anyone? Tom Yates - Network Chap - Gatekeeper Technology, Ltd. - 07050 368852

1 0

RE: Parts source for end of life products?
by Jeff Sloan 31 Aug '99

31 Aug '99

Hello, I am in the CSR team which monitors the filer crashes that result from using non-Network Appliance approves SIMMs. The purpose of this message is to clarify the discussion that is going on with regards to Network Appliance certifying Kingston Memory for use in Netapp Filers. We have not certified ALL Kingston memory for use in Netapp filers. In fact there are only a select few that meet the demands inside our boxes. Also note that this entire discussion is in regards to the F/C200/300 line of filers only. These are the only models of Netapp Filers that we have approved third party memory for, except for our older 450/1400 models (to my knowledge). Netapp has not recommended sub standard memory. If the memory is not listed on the Network Appliance Qualified Memory list, then it is not recommended, or more importantly, not supported, in any Netapp Filer. I, personally, have had to deny support to individuals who are using non approved SIMMs. The below listed SIMMs are qualified to give the same quality service as memory that is purchased from Network Appliance directly. For reference, I have attached the list in Excel format. Here's the text version of the list: Netapp F200/300 Qualified Memory Manufacturer and Model # Data Chipset Parity Chipset (16 per SIMM) (8 per SIMM) Kingston KTM8X36L-60G Samsung KM44C4100AK-6 SAMSUNG KM41C4000CJ-6 Kingston KTM8X36L-60G NEC 4217400-60 Hitachi HM514100CS6 or Hitachi HM514100BS6 or Hitachi HD56D836BR-7A Hitachi HM5117400AS6 Hitachi HM514100CS6 or Hitachi HM514100BS6 or Hitachi HD56D836BR-6A Hitachi HM5117400AS6 Hitachi HM514100CS6 or Hitachi HM514100BS6 or Unigen UG18M83602KBG-60 Siemens HYB5117400BJ-60 Toshiba TC5117440BSJ-60 Jeff Sloan Network Appliance 408.822.4754 > -----Original Message----- > From: owner-dl-toasters(a)netapp.com > [mailto:owner-dl-toasters@netapp.com]On Behalf Of Shaun T. Erickson > Sent: Monday, August 30, 1999 11:55 AM > To: sirbruce(a)ix.netcom.com > Cc: toasters(a)mathworks.com > Subject: Re: Parts source for end of life products? > > > sirbruce(a)ix.netcom.com wrote: > > > > On 08/30/99 23:49:43 you wrote: > > >However, the price of RAM from NetApp was 3-5x the price > (I forget exactly > > >how much) of the approved Kingston SIMM. So, we just > purchased 16 SIMMs > > >from our Kingston supplier, saving significant amounts of > cash, and we > > >kept the 4 excess SIMMS in our `hot spare' store. It > works like a charm. > > > > A cautionary note - much of the supposedly "in-spec" memory Kingston > > or other vendors sell is not capable of handling the strict timing > > and loading requirements of a Netapp filer. The reason the SIMMs > > you get from Netapp cost more is because they are tested for proper > > tolerance and inoperability. If you decide to use another source, > > you should be prepared for the chance of crashes or spontaneous > > reboots and be prepared to go through several cycles of swapping > > various SIMMs in various combinations to figure out the problem. > > Then NetApp shouldn't certify them. If I buy memory NetApp approved > memory from Kingston (and I have), I expect it to perform as well as > NetApp supplied memory. I don't expect NetApp to recommend > sub-standard > memory for me to buy. > > -ste > > -- > Work: (908) 582-7629 Pager: (800) 756-1133 Cell: (908) 672-6456 >

3 2

Re: Does the netapp support etherchannel/trunking?
by sirbruce＠ix.netcom.com 31 Aug '99

31 Aug '99

On 08/30/99 16:37:05 you wrote: >I don't believe that the NetApp implementation rememebers the interface on >which the request came in. I think that it simply remembers the last >interface on which a packet came in from a certain host. A sort of "arp" >table. I've been told in the past by software coders "in the know" that at least for some NFS/CIFS packets, Netapp indeed remembers the interface on which the request came in, and that generall the request would go out the same interface. However, certain unusual circumstances with CIFS or ATM could change that. The information I had at the time was not as strong as the statement posted here that it *always* went back out the same interface for all packets. Either the code has been beefed up to ensure this feature, or it's really more complicated than that. Bruce

1 0

Re: Parts source for end of life products?
by sirbruce＠ix.netcom.com 30 Aug '99

30 Aug '99

On 08/30/99 14:54:59 you wrote: >Then NetApp shouldn't certify them. If I buy memory NetApp approved >memory from Kingston (and I have), I expect it to perform as well as >NetApp supplied memory. I don't expect NetApp to recommend sub-standard >memory for me to buy. I don't think you understand. Even the *best* memory vendor has some memory in their "quality" bin that isn't good enough. Their testing simply isn't sufficient for the 99.9x% uptime figures that Netapp wants for their filers. Similarly, Netapp's own testing can't catch everything, and some bad apples still slip through. I suppose if Netapp was big enough, they could partner with a provider to do more quality testing for the memory. They may be big enough now, but even so it's not clear that the deal would be good for the memory provider. I don't think Netapp gaurantees that vendor supplied memory will perform as well as Netapp supplied memory, but I could be wrong. Bruce

1 0

Re: Parts source for end of life products?
by tkaczma＠gryf.net 30 Aug '99

30 Aug '99

On Mon, 30 Aug 1999 sirbruce(a)ix.netcom.com wrote: > A cautionary note - much of the supposedly "in-spec" memory Kingston > or other vendors sell is not capable of handling the strict timing > and loading requirements of a Netapp filer. This sounds like FUD. In fact it sounds like something Kingston would say about other memory vendors. Do you have data to substantiate this? I'm not saying don't buy memory from NetApp. We buy it there and will continue to buy it there because we want to maintain our service agreements. However, since you're making claims that memory sold by NetApp is superior please show me the data from an independent source. Tom

1 0

Does the netapp support etherchannel/trunking?
by Jaye Mathisen 30 Aug '99

30 Aug '99

Can I combine 2 100mbit pipes from a 540 or 630 to something like a Foundry switch to make a 200mbit connection? Can't get gigabit for a 540, but need a bit more oomph than 100...

6 6

Re: SUMMARY: really bad NFS write performance but NFS reads are OK
by sirbruce＠ix.netcom.com 30 Aug '99

30 Aug '99

On 08/26/99 15:41:50 you wrote: >the fix was simple. i didn't realize that things were set up for >synchronous writes. once i set it to asynchronous mode, write performance >skyrocketed. This sounds like such a mode doesn't commit the write to stable storage before responding to the client. Sure, performance will be great, but you'll lose data and have potential corruption the first time the machine goes down. This is hardly a winning quality. >to Bruce: the performance of this box is quite good actually. NetApp >isn't the only game in town. If you price/performance, multiprotocol, and ease of use are on your agenda, Netapp *is* the only game in town. With other vendors you only get to pick 2. >i sent my question to this list because from >time to time people talk about systems from auspex, emc, and many others. Well, people on the list are free to talk about what they chose, but I think the general idea is to discuss such systems only in relation to Netapp. Not "My Auspex isn't working, any ideas?" questions. Bruce

6 5

Re: Parts source for end of life products?
by sirbruce＠ix.netcom.com 30 Aug '99

30 Aug '99

On 08/29/99 18:48:09 you wrote: > >Greetings. > >I waded through the "toaster" archives hoping to get a list of vendors >which sell parts for EOL'ed toasters but had no such luck. > >Specifically, I have an F210 which has 64Mb RAM and one shelf full of 4Gb >hard disks. I'd like to upgrade it to the lastest OS release and get some >more disk on it. Upgrading will require an additional 64Mb of RAM and for >storage I either have to find a storage shelf and some more 4Gb disks, or >replace the 4Gb disks I have with 9Gb drives. Since rack space is at a >premium, I'd just as soon move to 9Gb disks but cost and availability are >likely to be the deciding factors in the end. Well, I don't have any help to offer on finding old parts, but there may be reasons why you should upgrade to a newer filer anyway. Was the F210 ever approved to support 9GB drives? (Or for that matter, 128MB memory?) I don't recall. (Is there a maximum disk space limit on the F210?) You should also consider the load on your filer; if doubling the space will support more clients then the low-end F210 may not be able to handle it. Another thing to keep in mind is in order to move to the larger drives you will have to do something like a backup/restore. Bruce

2 1

Re: SUMMARY: really bad NFS write performance but NFS reads are OK
by sirbruce＠ix.netcom.com 28 Aug '99

28 Aug '99

On 08/27/99 14:00:26 you wrote: > >On Thu, 26 Aug 1999 sirbruce(a)ix.netcom.com wrote: > > Well, people on the list are free to talk about what they chose, but I > think the general idea is to discuss such systems only in relation to > Netapp. Not "My Auspex isn't working, any ideas?" questions. > > >I thought the list was named 'toasters', not 'netapps' for a reason. >We wouldn't want to leave the Yahoo! folks out in the cold, would we? Welcome to the toasters mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, you can send mail to <lists(a)mathworks.com> with the following command in the body of your email message: unsubscribe toasters sirbruce(a)ix.netcom.com Here's the general information for the list you've subscribed to, in case you don't already have it: This is a totally unofficial mailing list for people who have Network Appliance toasters. It is not sanctioned by Network Appliance; it is, in true Internet spirit, a pure resource and grapevine for toaster administrators. It's presently administered by Tom Yates, <owner-toasters(a)mathworks.com>. He has two F330s, in case you were wondering. Bruce

2 1

SUMMARY: really bad NFS write performance but NFS reads are OK
by Matt Harrington 26 Aug '99

26 Aug '99

the fix was simple. i didn't realize that things were set up for synchronous writes. once i set it to asynchronous mode, write performance skyrocketed. to Bruce: the performance of this box is quite good actually. NetApp isn't the only game in town. i sent my question to this list because from time to time people talk about systems from auspex, emc, and many others. ---matt

1 0

Re: really bad NFS write performance but NFS reads are OK
by sirbruce＠ix.netcom.com 26 Aug '99

26 Aug '99

On 08/26/99 11:37:05 you wrote: >what could be causing this poor NFS write performance? The fact that the NAS box is from Western Scientific and not a Netapp filer? Bruce (wondering what this mail is doing on this list)

1 0

really bad NFS write performance but NFS reads are OK
by Matt Harrington 26 Aug '99

26 Aug '99

I have a NAS device on eval which performs well with NFS reads but not with NFS writes. I can read at about 9 MByte/sec (or faster) with certain NFS clients but I can only write at 0.22 MByte/sec from any client. nfsstat looks fine -- no badcalls. here is the setup: - RAID5 NAS device (from Western Scientific) 218GB - Alteon gigabit ethernet NIC - NFS version 2 - clients mostly run Irix 6.5 but there are a few Alphas running DU 4.0E and a Linux box running RH6 (kernel 2.2.5-15). - clients are on 100baseT - NAS box is connected to a Baystack 350-24T switch with a gigabit uplink module what could be causing this poor NFS write performance? matt harrington 415-476-4628

2 1

Re: NDMP and Security
by Steve Kappel 26 Aug '99

26 Aug '99

>We have a UNIX machine running Netbackup. It is initiating backups to >locally attached tapes drives on our filer. Can anyone explain how the filer >knows it's supposed to allow the UNIX host to initiate backups? I would >assume the machine/userid pair would need to be in the hosts.equiv before >this would work. However, backups are working without this entry. How does >security work with NDMP? The command set_ndmp_attr is used to set the password for the filer. Usage: set_ndmp_attr -auth ndmp_server username set_ndmp_attr -robot ndmp_server robotic_device robot_ctrl scsi_id logical_unit_number set_ndmp_attr -list The password is stored in an encrypted format. During NDMP authentication, the password will be sent to the filer either as clear text (NetBackup 3.1.1 or if the filer doesn't support MD5) or a MD5 digest. __________________________________________________________________________ Steve Kappel steve.kappel(a)veritas.com VERITAS Software steve.kappel(a)iname.com (Personal)

1 0

Copying small directory on netapp
by Stephen C. Losen 26 Aug '99

26 Aug '99

We are using our netapps for home directories in a mixed NFS and CIFS environment. We have a prototype new user directory that we set up with some unix "dot" files, a public_html directory, etc. Most of our CIFS users never touch unix, so from CIFS we make the unix dot files hidden. We do this in the hope that they won't delete them and then later on give unix a try and have problems when their account doesn't behave as documented. We use the netapp dump program to dump the prototype directory to a disk file. We create new accounts from unix. We make a new user directory and populate it with netapp restore. Then we chown all the files to the new user. This works great because it preserves the "hidden" attribute on all the "dot" files. Unfortunately, the netapp dump utility writes all the inode information for the entire filesystem to the dump file. So our little prototype directory, which tars into a file of about 20K, dumps into a 2.5M file. This really slows down bulk user adds, because it takes several seconds for each restore to run. Not a surprise when you have to rsh over 2.5M. We added 4700 accounts for our new incoming students and it took about a day -- almost all of the time taken up by restore. And yes, we dump once to file, and do multiple restores from it. I suppose I could build a very small and empty netapp filesystem and put the prototype in there and dump it. That would certainly reduce the size of the dump, but that's an impractial waste of resources. So here are my questions: 1) Is there some way other than dump/restore to copy a directory on a netapp that preserves all NFS and CIFS attributes? 2) We are running 5.2.2P1 and I don't see any dump flags that avoid including all the inode info in the dump. Am I missing something? 3) Is there a way from unix to set the CIFS hidden attribute? If so, I would just use tar and set the attribute. Steve Losen scl(a)virginia.edu phone: 804-924-0640 University of Virginia ITC Unix Support

2 1

RE: Copying small directory on netapp
by Benn, Paul 25 Aug '99

25 Aug '99

Hello Steve, Perhaps this has been answered already.... Anyway, you can also do this by using an NT based backup application (backing up over CIFS). I published a white paper detailing this: http://www.netapp.com/tech_library/3052.html Best Regards, Paul -----Original Message----- From: Stephen C. Losen [mailto:scl@sasha.acc.virginia.edu] Sent: Tuesday, August 24, 1999 8:23 AM To: toasters(a)mathworks.com Subject: Copying small directory on netapp So here are my questions: 1) Is there some way other than dump/restore to copy a directory on a netapp that preserves all NFS and CIFS attributes?

1 0

NDMP and Security
by grdodson＠lexmark.com 25 Aug '99

25 Aug '99

NDMP requires the client to know the password to the NetApp. Depending on the implementation it is either sent in the clear or as a hash from the client to the NetApp during authentication. Graydon Dodson ----- Begin Included Message -----

1 0

RE: NDMP and Security
by Davis, John 25 Aug '99

25 Aug '99

I recently assisted our Veritas resellar technician setup Netbackup on a pair of filers that I installed; the Sun Workstation served as the filers admin host as well as the NDMP "server/controller"; in addition to having the hosts.equiv entry which the filer admin host is in by default, she ran an authentication script like: "set_auth_ndmp toaster root" which then prompts for the filers password...sooooo, I would assume someone at some point in time set the authorization on your unix machine.. -----Original Message----- From: Sean Hinchey [mailto:skh@nortelnetworks.com] Sent: Wednesday, August 25, 1999 11:38 AM To: 'toasters(a)mathworks.com' Subject: NDMP and Security We have a UNIX machine running Netbackup. It is initiating backups to locally attached tapes drives on our filer. Can anyone explain how the filer knows it's supposed to allow the UNIX host to initiate backups? I would assume the machine/userid pair would need to be in the hosts.equiv before this would work. However, backups are working without this entry. How does security work with NDMP? -Sean

1 0

FW: Legato ClientPak for NetApp
by Yu, David 25 Aug '99

25 Aug '99

Re-submitting to toasters(a)mathworks.com . ------------------------------ > The Legato ClientPak for NetApp was announced yesterday. > > Please see: > > http://biz.yahoo.com/bw/990824/ca_legato__2.html > > for details. The ClientPak, which is a Java-based, non-NDMP solution, > will be available in September. The ClientPak is compatible with > Networker Server and Storage Node and backs up over the network. > > Obviously, Legato has invested heavily in NDMP, so it has a prominent > role in Legato's strategy. The Java ClientPak provides a solution right > now for Networker customers. > > Legato plans to provide a complementary NDMP-based Networker solution for > NetApp early next year. > > David >

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