toasters

toasters@lists.teaparty.net

1 participants
13523 discussions

RE: Ontap P* relase mess.
by Hibbard, Ken 07 May '99

07 May '99

|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. | Bruce, Change is coming. Hopefully for the better but you can be the judge of that. Netapp is moving to a new software release model. This is motivated by a need to correct some of the deficiencies in our current model. Also, as our customer base continues to grow we believe we need a more scalable and predictable approach to patch and maintenance releases. Let me give you a brief summary of the current model and where we are going with this new process. In the past, engineering was responsible for major and minor features releases. These releases went through the full engineering development and QA process. The customer engineering (CS) team had responsibility for the P releases and D patches. D patches were generated to fix a specific customer reported problem. P releases were a roll-up or collection of D patches that were judged to be valuable to a larger set of customers. For a variety of reasons we are moving to a model were engineering will be responsible for feature releases *and* maintenance releases. Maintenance releases will be scheduled at regular intervals (approximately 3 months) and go through the full engineering development and QA process. The CS team will continue to generate D patches for specific customers reported problems. We will make every effort to incorporate all outstanding D patches into the next available maintenance release. (There will be a time window where this is not possible. D patches that are generated in the latter phase of maintenance release testing may be difficult to integrate at the 11th hour. We also don't want to delay the scheduled release of the maintenance release. The predictability is important.) Maintenance releases will be cumulative with respect to the bug fixes they contain. For example, X.2.3 should be a superset of X.2.2. We believe there is a good case to schedule these releases at regular intervals We appreciate the fact that upgrades are disruptive and time consuming. Predictable releases allow our customers to plan for these upgrades. It is also important that the release numbering system be clear and meaningful to customers. Our current D/P number is not always intuitive. We are just beginning to move to this new model. There is likely to be some overlap between P releases and maintenance releases in the near term. I hope you can bear with us as we work through this transition. I also agree with Paul regarding the rfe's. We need to do a better job of documenting the changes that go into these releases. Customers need accurate information about the content of these releases in order to make informed decisions in managing their filers. You should expect to see change here as well. Thanks, Ken

2 1

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

07 May '99

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

2 1

A few general bitches and moans.
by Jaye Mathisen 07 May '99

07 May '99

I've been moving around some of our applications to make better use of our netapps and storage, and as part of this shuffle, some things just gotta be said... (I will preface this by saying that I really like my filers, both of them work very well in terms of reliability, it is just the nature of the beast to criticize when something doesn't work like you want it to, and be silent when it's doing its job. :) o The lack of *good* automated, filer-sufficient backup and management tools. NDMP is fine, but the *filer* needs to truly be an appliance, and needs to be able to do this on its own. No rsh monkeying around, just nice consistent, in-the-background, web-managed backup. Follow a schedule, run some "scripted" jobs, SMTP/SNMP trap the results. Not rocket science. o The lack of widespread tape changer support, or at least tweakable changer support. For various reaons, one of my filers will have 2 ADIC DLT tape changer systems on it, which doesn't do me a speck of good from the filer side, as I still have to issue the commands to swap tapes around. Gag. o CIFS support has got some big holes. - The inability to belong to multiple domains. Not all my domains trust each other. Oops, now the filer is essentially unusable for some of them. - For me, at least, CIFS management with no PDC is non-intuitive at all. I would pay real money for somebody to explain to me how to use autoexnt, a filer with no PDC and no WINS access, and permanently affix a share that is usable by more than one person. I can mount the share in autoexnt, but it's not accessible to anybody. (I use autoexnt with the interactive option, and the connection is successful, yet I always get "access denied" when trying to access it. However, if I attach it with the same login account as the autoexnt service, with the same username/password pair, it's fine. The CIFS tracer thingie on the Netapp tells me that both accesses are being mapped to the same Unix user account, but one works, the other doesn't... I have mailed support this one, but nary a response... - Even the ability to have a different network interface belong to a different domain would be useful. Not a panacea, but at least useful. o The general suckiness of NFS now being insufficient to backup the filer with CIFS. Probably not a solveable problem, but it still sucks. o The apparent lack of CIDR support in routing tables. I realize that routing requirements for a filer are probably not super significant, but something better than /24 would be nice. o NOW is better, but quicker navigation tools would help. I also do not understand why documentation requires a NOW login. o I would give a body part for a small filer, with 3 18 or 36GB drives, self contained, no shelves. Medium performance, medium capacity, hot swappable, 1 100MBit ethernet port, just plug and go. 8MB NVRAM, 256MB RAM. I hate adding file servers for that niche where even a small 720 is physically too much hassle, and the price-point is out the roof. Make the drives user-supplied, off a netapp recommended list, and kaching, give me an even dozen. Maybe leave in a slot for a 5 1/4" Tape drive. Heck, I saw some very scary numbers from consensys for their IDE raid product, use IDE drives instead of scsi in this bad boy, and cut them costs down. WD makes 7200 RPM drives now, at 18GB's a pop, and 5 of 'em fit in a 3 high bay. (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. :)) o It would be cool if config information, perhaps even the OS was on a optional PCMCIA card, that was formatted in a fashion readable on a notebook. Nothing like not having the right serial cable wired up, and having to type all those stupid commands by hand when you make a booboo, and plus the grief of having to boot off two floppies. o Or add an option to read rc from disk 3 on a DOS formatted floppy. o Fine, you don't want to use something like PCMCIA cards, then since Netapp only allows its network cards, allow tftp of the rc file from one of the interfaces. I guess the CIFS stuff is what's torquing me off right now the most, I don't want to have to slap a bunch of storage on some NT boxes when I have this filer sitting there perfectly suited (in theory) to do the job..., and I refuse to purchase 1 filer per domain.

6 7

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

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