toasters

toasters@lists.teaparty.net

13520 discussions

Re: Network Appliance makes the news...
by Jim McCoy 18 May '99

18 May '99

sirbruce(a)ix.netcom.com writes: >As to what happened, the most *likely* scenario for any signficant >downtime of the Netapp is double disk failure. That is, one disk >failed, and during reconstruction they lost another. I beg to differ. YahooMail has had significant problems with all sorts of unpleasant little bugs which has led to downtime for the system and in two cases actual data loss. Since the beginning of this year we have apparently run into every possible failure mode of these systems, except for a dual disk failure, and I can assure you that there are all sorts of reasons that an event like this could occur. Reading the tea leaves on this one I would guess that they also run into bug 1549 and were forced to run a wack on a filer (props to John E. for the fast wack, if it were not for that single improvement I can assure everyone at NetApp reading this that Yahoo would be using EMC boxes right now...) >If they were running a cluster, most likely there would have been >no interruption in service. You get what you pay for. I'm sure >their Apache (or whatever) web servers have crashed more than their >filers have. How I wish we would get what we paid for... We run a hacked version of Apache and have probably had a total of 30 minutes of system downtime due to this Apache problems this year (mostly due to a memory leak I think that we introduced into our version.) Contrast that with a total of 36 hours of system downtime since January due to filer failures. If NetApp expects us to pay twice as much per MB of storage and run a cluster then they are going to start getting into the realm where an EMC box begins to look like a better deal, and when it comes to system reliability NetApp still has a long way to go to reach the sort of reputation that EMC has in the industry. NetApp had a very serious problem with quality control on hardware and QA within the engineering department was so useless as to be non-existent. We have been given assurances that this specific problem as been recognized and is being addressed. Only time will tell. >There doesn't seem to be much of a story here. But there is a story here, and one which needs to be addressed. NetApp charges a large premium over the raw costs of the disks and hardware to hook them together compared to what I could rig up with a PC and a few raid controllers, as a customer I would like to know that I am getting some value for this addtional cost. When that "value-add" proves to be a mirage I think that I have a justifiable reason to be pissed off. Critical Path was just the first customer to admit that NetApp was the source of the downtime, the prompt attention we have received from NetApp (even when there was nothing they could do) is the only thing which prevented Yahoo from being the first one to attribute responsibility for system downtime to NetApp in a press release. jim mccoy Yahoo! Inc.

5 4

Re: Network Appliance makes the news...
by Tripp Cox 18 May '99

18 May '99

On 17 May 1999 20:54:25 -0400, Andrew Hobson wrote: >Of course, I'm more Netapps means more hardware, and more opportunity >for foulups, but we've received cards that were bent so badly we >couldn't put them in. The box didn't appear damaged at all. I recall several instances of buggy hardware and sloppy hardware QA dating back to early-mid 1997. I'd like to think things have improved since then. We had to replace all of our SCSI controllers in a slew of F540s, we had bad EMUs in a couple of F630s, and a heck of a time with the short-lived EFBs of the F520s. Not to mention a plethora of bad disks (new equipment) and shelf pairs bent beyond any utility. I also recall having to reseat a small microchip within the casing of an EFB. Of course, Jan and I managed to hose Netapp's lab equipment so bad on one trip to San Jose that a stream of curious engineers visiting the sick equipment couldn't recover it before the day was over. Maybe we're not the best test case. :) Of course the point to all of this being that it generated a great deal of service downtime that we never should have had to endure. Tripp

1 0

Re: Network Appliance makes the news...
by Andrew Hobson 18 May '99

18 May '99

On Mon, 17 May 1999 12:50:58 -0700, "Jim McCoy" <mccoy(a)yahoo-inc.com> said: > sirbruce(a)ix.netcom.com writes: >> As to what happened, the most *likely* scenario for any signficant >> downtime of the Netapp is double disk failure. That is, one disk >> failed, and during reconstruction they lost another. > I beg to differ. I just about to write this exact same email. We've had the same experiences with filer failers and quality control. We're having the same thoughts about the cost when you want non-stop computing. Netapp is great for the 98% uptime market. They aren't ready to play in the 99.99% uptime market, at least in my view. I used to be a Netapp enthusiast, but no longer. I'd sleep better if our customers' email was moved off of filers. Drew "Speaking from experience, but not speaking as a representative of MindSpring" Hobson -- "He's a love machine, sir." -- Waylon Smithers

2 2

Re: Network Appliance makes the news...
by Jeff Newton 18 May '99

18 May '99

Ok, I'll bite. What is a "wack"? Cheers, > In the immortal words of Jim McCoy (mccoy(a)yahoo-inc.com): > > > Reading the tea leaves on this one I would > > guess that they also run into bug 1549 and were forced to run a wack on a > > filer (props to John E. for the fast wack, if it were not for that single > > improvement I can assure everyone at NetApp reading this that Yahoo would be > > using EMC boxes right now...) > > Out of morbid curiosity, which is bug 1549? I have had to run wack > in recent memory, and it was a...sobering experience. > > -n > > ------------------------------------------------------<memory(a)blank.or g> > I've got more than one membership / to more than one club > and I owe my life / to the people that I love. (--Ani DiFranco) > <http://www.blank.org/memory/>---------------------------------------- -- ---- Jeff Newton Unix Systems Administrator PMC-Sierra Inc.

2 1

32-bit uptime counter?
by Brian Tao 17 May '99

17 May '99

Still running good ol' 4.2a on an F230: Sun Apr 18 21:00:00 EDT [statd]: 9:00pm up 497 days, 1:10 407777519 NFS ops, 0 CIFS ops, 0 HTTP ops Sun Apr 18 22:00:00 EDT [statd]: 10:00pm up 497 days, 2:10 408458997 NFS ops, 0 CIFS ops, 0 HTTP ops Sun Apr 18 23:00:00 EDT [statd]: 11:00pm up 42 mins, 409036765 NFS ops, 0 CIFS ops, 0 HTTP ops Mon Apr 19 00:00:00 EDT [statd]: 12:00am up 1:42 409494263 NFS ops, 0 CIFS ops, 0 HTTP ops This looks like 2^32 ticks elapsed (about 42949673 seconds)... is this one of the counters being increased to 64 bits? -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

2 1

Re: Running CIFS
by sirbruce＠ix.netcom.com 17 May '99

17 May '99

On 05/05/99 15:53:45 you wrote: > >In message <7F608EC0BDE6D111B53A00805FA7F7DA03A83938(a)TAHOE.netapp.com>, "Muh >lestein, Mark" writes: >>A mixed qtree already works exactly as you want it to. In a mixed qtree the >>security of a file is based on the last security-setting operation. If an A >>CL is >>set which denies you access, but you still need to do something with a file, >>then as root you can change the security on any files/dirs in that qtree (using >>chmod, chown, or chgrp), which changes the security-style to UNIX. After that, > > Ok, so far I've read this alot. No maybe I'm missing something > 'cause I get the following errors trying to put it into practice. What errors? These are exactly correct. > Here's a test on a directory w/ NTFS permissions allowing only full > control to the owner: In other words, you've told NTFS that Administrator can't read the directory or change permissions. All Administrator can do is assume ownership. >root@jagular: fs0/home/kelleher [130] # >root@jagular: fs0/home/kelleher [130] # ls -ald test_dir >drwx------ 2 kelleher users 4096 May 5 14:47 test_dir >root@jagular: fs0/home/kelleher [131] # >root@jagular: fs0/home/kelleher [131] # ls -al test_dir >test_dir: Permission denied >total 8 This is correct; root on UNIX will map as Administrator in the NT realm, so it can't read the directory. >root@jagular: fs0/home/kelleher [132] # >root@jagular: fs0/home/kelleher [132] # chown 755 test_dir >chown: test_dir: Not owner Firstly, you should have done chmod, not chown. Secondly, this would be correct... Administrator (root) does not have permission to change the file permissions. >root@jagular: fs0/home/kelleher [133] # >root@jagular: fs0/home/kelleher [133] # chown root test_dir >chown: test_dir: Not owner >root@jagular: fs0/home/kelleher [134] # This should have suceeded, if I understand the model correctly. I'm not sure why it didn't; perhaps it's a bug? > I can however su to the UNIX user, chmod it, and then get access to > the file: > >root@jagular: fs0/home/kelleher [134] # su kelleher >jagular% >jagular% chmod 755 test_dir >jagular% >jagular% exit >jagular% root@jagular: fs0/home/kelleher [135] # >root@jagular: fs0/home/kelleher [135] # ls -al test_dir >total 72 >drwxr-xr-x 2 kelleher users 4096 May 5 14:47 . >drwxr-xr-x 25 kelleher users 32768 May 5 15:25 .. >-rwx------ 1 kelleher users 0 May 5 14:47 test_file >root@jagular: fs0/home/kelleher [136] # >root@jagular: fs0/home/kelleher [136] # > > Is this what you mean? This all makes sense. >>those files follow regular UNIX rules, which allows root full access. If the >>user wants to put an ACL back on afterwards, no problem. >> >>We have found that using ACLs in a mixed qtree can be helpful in a number of >>situations. That's because ACLs are enforced even for NT Admins and root. For >>example, we found that some files were being accidentally deleted by root/Admin >>users, so we put an ACL on those files which allows only READ access to all >>users. That prevents deleting, even by root or NT Admins. Of course, if we >>actually want to delete the files we just change the permissions to allow that, >>since in a mixed qtree both root and NT Admins have a special dispensation >>tochange the permissions. > > Sounds like the problem is too many people with root/Admin access. > Your solution only requires these people to take an extra step > (give themselves the permissions) before they accidentally mess > something up. If I were you I'd work on getting rid of their > access. (Not that it's an easy thing to do.) In my experience many people are unwilling to take this approach, for reasons I can't quite fathom. They would much rather let incompetent people continue to work for them and spend effort trying to keep them from shooting themselves in the foot rather than spending the time to make them competent and/or getting another employee. Bruce

2 1

ISP_2100: cmd opcode 0x28, retry count 0: command timeout, aborting request error
by Mike Ball 17 May '99

17 May '99

Can anyone shed some light on the error below? It looks like it is just a media error which was recovered from, but I wanted verification. Thank you, Mike Wed May 12 00:13:03 EDT [isp2100_timeout]: 8.45 (cmd opcode 0x28, retry count 0): command timeout, aborting request Wed May 12 00:13:03 EDT [isp2100_timeout]: isp2100_reset_device: device 8.45 (1.45)

1 0

determining patch revision level..
by Kane, Kevin 17 May '99

17 May '99

Can anyone tell me how to determine the patch level of the OS? Does a response of 5.2.1 from the "version" command mean that I have generic 5.2.1 with no P releases? TIA Kevin A. Kane Manager - Engineering Computing Infrastructure Aspect Telecommunications Direct: 978 250-7933 Business Fax: 978 250-7998 Pager: 888 799-4866 Home: 978 388-1875 Mobile: 508 783-2695 Email: Kevin.Kane(a)aspect.com Pager Email: Kevin.Kane.Pager(a)aspect.com

4 3

Re: determining patch revision level..
by Robert Palermo 17 May '99

17 May '99

Yes you are running the generic 5.2.1 as it were. If you had a patch release the console command "version" would report 5.2.1P2 for example. There are other trailing characters such as D8 and such but the system should report the actual patch version if you are running it. > From: "Kane, Kevin" <Kevin.Kane(a)Aspect.com> > To: "'toasters(a)mathworks.com'" <toasters(a)mathworks.com> > Subject: determining patch revision level.. > Date: Mon, 17 May 1999 12:51:18 -0400 > MIME-Version: 1.0 > > Can anyone tell me how to determine the patch level of the OS? Does a > response of 5.2.1 from the "version" command mean that I have generic 5.2.1 > with no P releases? > > TIA > > Kevin A. Kane > Manager - Engineering Computing Infrastructure > Aspect Telecommunications > Direct: 978 250-7933 > Business Fax: 978 250-7998 > Pager: 888 799-4866 > Home: 978 388-1875 > Mobile: 508 783-2695 > Email: Kevin.Kane(a)aspect.com > Pager Email: Kevin.Kane.Pager(a)aspect.com > >

1 0

Re: Ontap P* relase mess.
by Jason D. Kelleher 17 May '99

17 May '99

In message <Pine.BSF.3.96.990506145048.2243D-100000@localhost>, kg writes: > >So it looks like I'm going to have to downgrade to 5.2.1P2 from 5.2.2 to >avoid panics from assertions in the netbios name service.. Patches for >5.2.2 are somewhere in the indeterminate future.. (all of this for bug >12712, which for some reason isn't listed in Bugs Online) > >This brings up one of the points that Tom (?) was ranting on a week or so >ago.. Why release 5.2.2, a minor bug-patch revision, that don't >incorporate patches from its predecessor? > >Perhaps I shoud've called support first, but I just brought these 760's >online with 5.2.2, under the apparently false impression that I was >getting all the up-to-date fixes.. Was there an erratta for 5.2.2 that I >missed that said "THE FOLLOWING IS STILL BROKEN:"? > >argh. > >..kg.. Sounds like another vote for a concise "Known Bugs" list for each ONTAP rev... jason

1 0

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