toasters

toasters@lists.teaparty.net

3 participants
13514 discussions

Web Hits per NFS ops/s ?
by beepy＠netapp.com 03 Sep '99

03 Sep '99

Hey, hey. Without divulging corporate secrets, does anyone have rules of thumb for some "normal" activity, how much NFS traffic if generated out the back of a beefy Web Client to a filer that is serving up the pages via NFS? Rough feels and spreads is all I was curious about... I'm not sure I have ready access to a Web front end/filer back end setup that would be meaningful... Mostly I'm curious. (The number just thrown out, with no justification, was Each "hit" results in 5 NFS operations. I'm sitting here pounding my head trying to understand the "5". V3 might yield: LOOKUP ACCESS READ Per page hit. Is average object size 8 - 12KB? So one read on V3? I assume Apache front ends are not "browsing" they're firing names at the filer. Etc. I thought it an interesting question. What does the op mix look like for a filer backing a Web host? (I've seen the mix, I guess I was never startled enough to remember, seemed boring with lots of LOOKUPs, 10% READs, 5 - 8% WRITEs?). beepy

1 0

RE: Anyone mounting filer on Linux with smbfs ?
by Sam Schorr 02 Sep '99

02 Sep '99

Stephen, We are mounting multiple filers (2 F740's, 2 F760's), running OT 5.3.2D2, using NFS on Linux running on a Compaq. We are almost exclusively a CIFS environment and had wanted to do exactly what you want. However, there are known problems with OT that prevent using Samba (for example) to do a direct CIFS mount. So, we have a mixed ACL on the filers, run both CIFS and NFS, and mount the filers from Linux as NFS. It does require some tricks with WAFL settings to insure that non-trusted UNIX users are defaulted to the proper NT user domain account, and you have to make sure that the wafl options for unicode are set to both convert and create. If you convert from 5.2.x or prior, and your filer data has been created through CIFS, you will HAVE TO go through some procedure to open every directory to force conversion. If you do not, any directory not converted will be inaccessible in its snapshot, and snapshots cannot be converted. --srs -----Original Message----- From: Stephen C. Losen [mailto:scl@sasha.acc.virginia.edu] Sent: Thursday, September 02, 1999 12:54 PM To: toasters(a)mathworks.com Subject: Anyone mounting filer on Linux with smbfs ? Linux provides a SMB fs type and we are trying to mount a netapp CIFS share on a linux box, but with no luck. We are using unix authentication on the filer from a NIS map. We have no Windows or NT authentication set up at all. Windows and NT attach to CIFS shares on the filer just fine, using cleartext passwords. And they also attach to a linux samba server just fine, with unix authentication and cleartext passwords. But we can't get linux to mount a smb fs from the netapp. We would like to do this because we expect a large number of users to run linux on their desktops and we would love to not have to manage the exporting nightmare that NFS would require -- especially when most folks will be getting IP addresses via DHCP. It would be much more convenient (for us sysadmins) for linux users to just mount their home dir as a smb fs type, and they authenticate with their unix password. Steve Losen scl(a)virginia.edu phone: 804-924-0640 University of Virginia ITC Unix Support

1 0

Anyone mounting filer on Linux with smbfs ?
by Stephen C. Losen 02 Sep '99

02 Sep '99

Linux provides a SMB fs type and we are trying to mount a netapp CIFS share on a linux box, but with no luck. We are using unix authentication on the filer from a NIS map. We have no Windows or NT authentication set up at all. Windows and NT attach to CIFS shares on the filer just fine, using cleartext passwords. And they also attach to a linux samba server just fine, with unix authentication and cleartext passwords. But we can't get linux to mount a smb fs from the netapp. We would like to do this because we expect a large number of users to run linux on their desktops and we would love to not have to manage the exporting nightmare that NFS would require -- especially when most folks will be getting IP addresses via DHCP. It would be much more convenient (for us sysadmins) for linux users to just mount their home dir as a smb fs type, and they authenticate with their unix password. Steve Losen scl(a)virginia.edu phone: 804-924-0640 University of Virginia ITC Unix Support

1 0

Has anyone been able to get FrontPage 98 extensions working with Netapp filers?
by Mike Ball 02 Sep '99

02 Sep '99

I am running Data Ontap version 5.3D20 on F230 authenticating to NT 4.0 domain. We are unable to access web pages created in FrontPage 98 stored on the Netapp. The error I receive when I try to access the pages states "credentials passed by the client do not have access to the particular resource. Unauthorized due to ACL on resource". Has anyone been able to run FrontPage extensions on the Netapp? Thank you, Mike Ball mball(a)opensystems.com

1 0

RE: DLT problems on F740s
by Benn, Paul 01 Sep '99

01 Sep '99

It's been my experience that "differential" SCSI drives as well as terminators are clearly marked as being such. Best Regards, Paul -----Original Message----- This sounds remarkably similar to the symptoms I saw when I accidentally plugged a single-ended (i.e, non-differential) DLT4000 into our F740. I removed the drive after I noticed it was hanging at a similar point to where yours was, and all was well. I've since had a wide differential DLT7000 on the F740 working without any problems. As to how to test the tape drives; no idea. `Check with your vendor'?

1 0

RE: DLT problems on F740s
by Benn, Paul 01 Sep '99

01 Sep '99

Hello Dave, Is it possible that a single ended SCSI drive and terminator were plugged into the differential SCSI port? Regards, Paul Network Appliance -----Original Message----- From: Dave Atkin [mailto:dla1@york.ac.uk] Sent: Wednesday, September 01, 1999 1:02 AM To: toasters(a)mathworks.com Subject: DLT problems on F740s On startup the 740 hangs for a long time just after the memory test and the "Complete" message. We've tried each drive on two 740s and they both act the same. We used the cable and terminator supplied with drives. The 740s hang even with the drive powered off.

2 1

Re: DLT problems on F740s
by Luke Mewburn 01 Sep '99

01 Sep '99

Dave Atkin writes: > We are just in the process of replacing our two F230s with three F740s > and it's all going well apart from the DLT drives. We bought two Quantum > DLT7000 differential SCSI drives, but we can't get them to work. > > On startup the 740 hangs for a long time just after the memory test and > the "Complete" message. We've tried each drive on two 740s and they both > act the same. We used the cable and terminator supplied with drives. The > 740s hang even with the drive powered off. > > Any ideas anyone? Could it be that these drives are not really > differential - how could we tell? This sounds remarkably similar to the symptoms I saw when I accidentally plugged a single-ended (i.e, non-differential) DLT4000 into our F740. I removed the drive after I noticed it was hanging at a similar point to where yours was, and all was well. I've since had a wide differential DLT7000 on the F740 working without any problems. As to how to test the tape drives; no idea. `Check with your vendor'?

1 0

DLT problems on F740s
by Dave Atkin 01 Sep '99

01 Sep '99

We are just in the process of replacing our two F230s with three F740s and it's all going well apart from the DLT drives. We bought two Quantum DLT7000 differential SCSI drives, but we can't get them to work. On startup the 740 hangs for a long time just after the memory test and the "Complete" message. We've tried each drive on two 740s and they both act the same. We used the cable and terminator supplied with drives. The 740s hang even with the drive powered off. We've tried 5.2.2P1 and 5.3.2. Booting the diagnostic disk and running the scsi disgnostic tends to report SCSI errors of various types, eg "SCSI bus reset failed". Any ideas anyone? Could it be that these drives are not really differential - how could we tell? ------------------------------------------------------ Dave Atkin, Head of Technical Services Computing Service, University of York, YORK YO10 5DD Phone: +44-1904-433804 (ddi) Fax: +44-1904-433740 Email: D.Atkin(a)york.ac.uk ------------------------------------------------------

1 0

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

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