toasters

toasters@lists.teaparty.net

13520 discussions

Start a nNew thread

apologies
by kelvin 07 May '99

07 May '99

sorry, i must have been blind um, how about proxy-only mode button on the web manager :) sigh kelvin

1 0

RE: Ontap P* relase mess.
by sirbruce＠ix.netcom.com 07 May '99

07 May '99

On 05/06/99 20:35:58 you wrote: >I'm not surprised to see Bruce has pretty much got the scenario of how this >happened since he's an ex-NetAppian. In fact 5.2.2 was in test as other bugs >came in. Hey, the process can always change. :) I was mostly just guessing given the circumstances, and knowing that Netapp wouldn't not include the patch without a reason. >Since the CIFS problem, 12363, was biting a number of customers and it >caused a Panic, we wanted to get 5.2.2 into manufacturing as fast as possible. >Judgement call on our part, we decided not to restart all the testing and just >go with 5.2.2 as it was in order to have a new GA release that manufacturing >would ship. I was trying to think of possible ways around this and couldn't really think of a good one. One idea, though, would be to make sure that any P releases from a previous version that aren't rolled in have P releases made for the new version by the time it's released. That way customers on 5.2.1P2 can get 5.2.2P2 if they have a specific bug, while 5.2.1 customers can pick the regular 5.2.2. You could put something on NOW basically saying that they shouldn't download 5.2.2P2 unless they were experiencing that particular bug, because it hadn't been thoroughly tested. Bruce

1 0

RE: Ontap P* relase mess.
by Norman, Paul 07 May '99

07 May '99

> -----Original Message----- > From: sirbruce(a)ix.netcom.com [mailto:sirbruce@ix.netcom.com] > Sent: Thursday, May 06, 1999 3:48 PM > To: toasters(a)mathworks.com > Subject: Re: Ontap P* relase mess. > > > On 05/06/99 14:56:52 you wrote: > >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) It got moved to REVIEW state today. Should be up on NOW soon. > > I agree... many bugs are missing from Bugs Online and the bugs are > not updated often enough. Perhaps the people making patch releases > don't have full power to update Bugs Online as part of the patch > making and bug reporting process. > > >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? > > My guess is something like this. > > When 5.2.1 was released, naturally 5.2.2 was already being considered > and worked on. Shortly thereafter it probably went into testing. > > During 5.2.2 testing, some bugs cropped up in 5.2.1. Various patch > releases were created to fix some of the problems. However, they did > not get as extensive testing as a full "dotdot" release. No doubt > someone wanted to roll the P2 patch into 5.2.2, but someone else > said it was already too late and doing that would require testing > all over again. This was probably unnaceptable for some political > reason - anything from something minor like not wanting to slip on > the schedule to something major like something in 5.2.2 that some > big customer needs and said big customer not being likely to > encounter bug 12712. I'm not surprised to see Bruce has pretty much got the scenario of how this happened since he's an ex-NetAppian. In fact 5.2.2 was in test as other bugs came in. Since the CIFS problem, 12363, was biting a number of customers and it caused a Panic, we wanted to get 5.2.2 into manufacturing as fast as possible. Judgement call on our part, we decided not to restart all the testing and just go with 5.2.2 as it was in order to have a new GA release that manufacturing would ship. > > >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:"? > > Would be nice if they had listed known bugs in 5.2.2. I've burted two RFEs. #14809 RFE - Release notes (Start Here Guide) should list all bugs fixed in a release #14810 RFE - Release notes (Start Here Guide) should list all bugs fixed in "P" or "D" releases but not fixed in this release > > Bruce > >

1 0

Ontap P* relase mess.
by kg 06 May '99

06 May '99

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..

2 1

Re: A few general bitches and moans. (turning back into what wouldpeoplr like in a very-low-end filer?)
by sthaug＠nethelp.no 06 May '99

06 May '99

> > Wrongo. SCSI is still way more expensive than EIDE. > > Just an example of RETAIL market prices for drives. > > 9.1GB EIDE Ultra DMA / 66 AC29100 7200RPM 9.5NS 2MB Buffer 3 Year Warranty > > $188 > > 9.1GB 3391WD SCSI Wide Differential. > > $219 > > about 15% difference in price. I wouldn't call that much. I think you're > a bit out of touch with the market. The US isn't the whole world. There are other parts of the world where SCSI is significantly more expensive than IDE. Norway is an example of this. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

2 1

Raid Scrub errors
by scw＠seas.ucla.edu 06 May '99

06 May '99

We've had a 220 for 30 months and a 330 and a 540 for about 18 months. In that time we've never had a raid scrub problem. On April 25 we got 3 raid scrub error messages. I called netapp (that morning) and the CE said that there was nothing to worry about unless they continue and/or there are hard disk errors associated with the problem. I expected that this was the case, and accepted this response. Please note that everything seems to be just fine, and I'm probably being a nervous Nelly. The error didn't reoccur, even though we ran scrub twice on the machine during the week. On Thursday I called back (having had second thoughts, but also having been out of town), and asked for further clarification. In particular: (1) How can there be a parity inconsistency w/o some sort of disk error? If there was a hard error why is there no log entry for same? If there was no error then how can the parity be wrong? Disk_stat reports that since the filer was booted (2 months ago) there have been 3 recovered errors. However I would not expect a recovered error to produce a parity inconsistency, since the correct data should have been recovered. (2) How does the system know that the error is in the parity block and not in a data block? The response that we received from netapp support indicated that it may have in fact rewritten a data block, but logged it as a parity block. In either case how can they determine where the error is if a parity inconsistency occurs w/o a corresponding media error? (3) How can we (as end users) map the stripe number to disk blocks, and then further to the data and/or filesystem info (Inode) blocks. (4) Short of wacky how can we be really sure of our filesystem/data integrity? What I got back was (in essence) don't worry, everything is fine and some canned (RAID for dummies) answers about why raid scrubbing is run and a brief synopsis of the error messages. Except for items 3 and 4... (3) You can't, not really. I believe this and really didn't really expect any other answer, just wishful thinking. (4) Use wacky and don't forget you have to take the filer out of service and it can take up to 10 hours to check the filesystem [for large values of filesystem]. Or upgrade to 5.3 and it only takes about a hour. Could someone give me a pointer to a document that answers questions 1 and 2? Or a brief answer to the group? Does anyone else get these messages? Log file entries: Sun Apr 25 01:00:00 PDT [raid_scrub_admin]: Beginning disk scrubbing... Sun Apr 25 02:39:11 PDT [raid_stripe_owner]: Inconsistent parity on volume vol0, RAID group 0, stripe #606202. Sun Apr 25 02:39:11 PDT [raid_stripe_owner]: Rewriting bad parity block on volume vol0, RAID group 0, stripe #606202. Sun Apr 25 02:39:11 PDT [raid_stripe_owner]: Inconsistent parity on volume vol0, RAID group 0, stripe #606203. Sun Apr 25 02:39:11 PDT [raid_stripe_owner]: Rewriting bad parity block on volume vol0, RAID group 0, stripe #606203. Sun Apr 25 02:39:11 PDT [raid_stripe_owner]: Inconsistent parity on volume vol0, RAID group 0, stripe #606204. Sun Apr 25 02:39:11 PDT [raid_stripe_owner]: Rewriting bad parity block on volume vol0, RAID group 0, stripe #606204. Sun Apr 25 03:48:07 PDT [consumer]: Scrub found 3 parity inconsistencies Sun Apr 25 03:48:07 PDT [consumer]: Scrub found 0 media errors Sun Apr 25 03:48:07 PDT [consumer]: Disk scrubbing finished... ----- Stephen C. Woods; UCLA SEASnet; 2567 Boelter hall; LA CA 90095; (310)-825-8614 Finger for public key scw(a)cirrus.seas.ucla.edu,Internet mail:scw@SEAS.UCLA.EDU

2 1

RE: SNMP traps (+ other monitoring issues)
by Hackworth, Brian 06 May '99

06 May '99

: The [miscGlobalStatus] MIB description is a little woolly however : : Is there a more detailed explanation of what event will : trigger what status? We were intentionally vague in describing the status, to allow us the flexibility to change the algorithm in future releases. The current algorithm is to report "critical" if there are any failed fans, power supplies, or if the chassis temperature is too hot. It reports "nonCritical" if there are any failed disks, or if any volume is 99% full. : However, when doing : the same power supply pull, we only get a message in the : 'info' file. I filed a bug report (14576) on this one. Power supply failures are more serious than "info"; we need both to get the severity right, and to make it consistent across the various flavors of reporting.

4 4

Re: Hardware for F330
by sirbruce＠ix.netcom.com 06 May '99

06 May '99

On 05/05/99 23:35:44 you wrote: >> Netapp has other narrow approved disks they can sell you. You should buy >> those. > >We seem to have some conflicting information here. The Norwegian vendor >claims that there are *no* narrow disks in the Netapp price list any more >- ie. no new narrow disks (of any kind) can be obtained from Netapp. The >best that the Norwegian vendor can do is to get us refurbished narrow >disks. We are only moderately interested in this... Sorry, I was going by what George Kahler said about them being replaced with the Fujitsus. My main point was that they don't *have* to be the same vendor of disks that you already have, which seemed to be a concern of yours. I suppose your vendor may be right bout the price list, although I find it pretty suprising that Netapp wouldn't find a replacement or wouldn't keep enough in stock to cover existing customers. Bruce

1 0

Re: Raid Scrub errors
by sirbruce＠ix.netcom.com 06 May '99

06 May '99

On 05/05/99 13:01:00 you wrote: > On Thursday I called back (having had second thoughts, but also having >been out of town), and asked for further clarification. In particular: > > (1) How can there be a parity inconsistency w/o some sort of disk error? Short of a software error in calculating parity or a similar write problem, there probably isn't a way. > If there was a hard error why is there no log entry for same? > If there was no error then how can the parity be wrong? A variety of ways. Two immediately spring to mind: 1. The block with the error did not go bad until after data had been written to it, but before data was read from it. 2. The drive thought the data was written correctly but was incorrect. 3. The drive thought the data was read correctly but was incorrect. > Disk_stat reports that since the filer was booted (2 months ago) > there have been 3 recovered errors. However I would not expect > a recovered error to produce a parity inconsistency, since the > correct data should have been recovered. I've usually seen parity inconsistencies as a result of an improper shutdown. However these are repaired immediately upon reboot. > (2) How does the system know that the error is in the parity block and > not in a data block? The response that we received from netapp > support indicated that it may have in fact rewritten a data block, > but logged it as a parity block. I don't think it may have in fact rewritten a data block (I could be wrong). Rather, they read all the data, and the parity block was inconsistent with the data, so they rewrote the parity information. I'm not sure if there is any way to know for sure that the parity is actually correct and it is the data block that is wrong. > In either case how can they > determine where the error is if a parity inconsistency occurs w/o > a corresponding media error? I think you're basically saying the same thing here; the problem could be in the data block, not the parity block. In any case, assuming it is parity then they can determine which block goes on that stripe. > (3) How can we (as end users) map the stripe number to disk blocks, and > then further to the data and/or filesystem info (Inode) blocks. I don't think there's any way without an expensive scan of various metadata files. However, it would be nice if every such disk message contained such information. > (4) Short of wacky how can we be really sure of our filesystem/data integrity? No way, but if the filesystem is fine then wacky won't tell you if the data is corrupt either. If the block of zeroes got all flipped to ones, and the parity was rewritten to accomodate that, there's no way to know that it happened unless you happen to know the block should be otherwise in a given file. > What I got back was (in essence) don't worry, everything is fine and >some canned (RAID for dummies) answers about why raid scrubbing is run >and a brief synopsis of the error messages. >Except for items 3 and 4... > >(3) You can't, not really. I believe this and really didn't really expect > any other answer, just wishful thinking. > >(4) Use wacky and don't forget you have to take the filer out of service > and it can take up to 10 hours to check the filesystem [for large values > of filesystem]. Or upgrade to 5.3 and it only takes about a hour. > > > Could someone give me a pointer to a document that answers questions 1 >and 2? Or a brief answer to the group? Does anyone else get these >messages? Yep. The bottom line is - don't worry about it, as they are probably of no consequence. If you continue to get inconsistent parity, it could be a pointer to some other problem. Bruce

1 0

Re: A few general bitches and moans. (turning back into what would peoplr like in a very-low-end filer?)
by mds＠gbnet.net 06 May '99

06 May '99

On Wed 5 May, 1999, tkaczma(a)gryf.net wrote: > > The price differences between SCSI and IDE are not that significant > anymore, but I was wondering why someone didn't come up with and IDE Wrongo. SCSI is still way more expensive than EIDE. It's just the EIDE disk are meant for cheap-and-cheerful low-requirements users and SCSI occupies the middle-high disk market. But we're talking about a VLE filer here, so we can make different assumptions, maybe. > appliance. The argument that I would come up with is that you can only > have 2 devices on one bus, much too few for a RAID 5 set. This also Bzzt. Irrelevant, add more busses because EIDE busses are also quite cheap. > applies to your request for a 3 disk appliance. The power of striping > comes from the number of drives. The more drives you add the smaller the > parity overhead. With 3 drives 33.3 ... % is "wasted" on parity. With 14 > drives the "waste" goes down to about 7%. Parity overhead in terms of space maybe, but computation goes up linearly at best and might go up higher (reconstructing blocks from parity when a disk blows). Tradeoff time. > > > (And no, I'm not interested in the philosophical war of IDE vs SCSI. > > Fact: IDE is currently cheaper than SCSI. Fact: I want this box to be > > cheap. Check and mate. :)) I agree. But I'd do things slightly differently. > No mate, and probably not even check. SCSI drives are not THAT much more > expensive anymore. You must remember that you can have only 2 IDE drives Oh yeah they are. Here in the UK I spent 360quid on an UW 9GB Seagate (end user price) where a 10GB UDMA EIDE drive cost 190quid (end user price). > on the bus, among other limitations. The money you save in drives will > probably be made up in the complexity of the controllers and software. > Everything costs money, the drives are only a fraction of the cost. I've seen PCI-EIDE controllers advertised for about the same as SCSI host adapters, but I'd put them together on the motherboard with an integral network interface (10/100Base-TX). Performance on the SCSI is a bit better but not *that* much better. I'd bet that a good board designer could easily put 3 EIDE controllers on a PCI bus, giving you (4 devices per EIDE controller, last time I counted) 12 disk connections. The motherboard could have the EIDE connections, one cheap integral SCSI host adapter for tapes, one network interface and one set of battery-backed memory (just back up all memory - don't have separate NVRAM, we're talking small and compact here). Given a K6-3 or Celeron and DOT this baby would cost quite a bit less in parts costs than the latest and greatest filers, but wouldn't be an embarrassment to NetApp (of that I'd be quite quietly confident). You could make the mboard quite small and make the whole thing into a single rack-mount shelf/deskside tower style thing, with the disks presented at the front and the power-supply, motherboard access, serial-line, floppy drive, network connector and SCSI connector round the back. >-- End of excerpt from tkaczma(a)gryf.net

4 3

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