toasters

toasters@lists.teaparty.net

13531 discussions

Mixing Shelves
by Jay Orr 12 May '99

12 May '99

I'm trying to figure out if the toasters always have just one volume, or if I can have a few shelves as 4 gig, and a few as 9 gig, and use 2 mount points (one for the 9G and one for the 4G shelves). We've currently got 4 shelves of 4gig narrows, but all that is available from NetApps now (and soon to be stopped) are fast/wide 9gig shelves/controllers. Can we take a fast/wide card and a shelf of 9GIG to expand, or will the 9G drives be treated like 4G drives, and I'll loose the extra 5G per drive? ----------- Fujitsu - Nexion, St. Louis, MO Jay Orr (314) 579-6517

2 1

cheaper alternatives to NetApp?
by Matt Harrington 11 May '99

11 May '99

I'm in the market for something very similar to a F720 but with cheaper 18GB drive prices. I know of competitive products from Nitech and Procomm but as far as I can tell nothing but the NetApp will let me add 1 or 2 drives to the RAID set at a time. I assume this is because the NetApps use RAID 4. Does anyone know of a NAS product which will allow me to add a drive at a time without having to reformat the entire RAIDset? matt -- matt(a)ucsd.EDU

1 0

End-of-Year backup plans...
by Don Glascock 11 May '99

11 May '99

Hi -- As we prepare for the potential purchase of a relatively large toaster in six months or so, we are also considering the options for backing it up. We're happy with our little F230, traditional "14 Gbyte" 8mm tapes, and Networker, but it would appear that lights-out backups of a much larger toaster would do better with bigger-capacity tapes. The AIT/DLT discussions & documents have been very useful. So the big questions we will need to have answered in the next six months are: 1. Will Legato's Networker backup software speak NDMP by Q1 2000? It is said that this is the reason why they bought BudTool from Intelliguard. Do representatives of Legato read this list? 2. Does Network Appliance plan to support AIT jukeboxes (not just autoloaders) in native mode (not just "dds mode") by Q1 2000? 3. Will Legato (or Veritas) take advantage of the memory chips on AIT tapes? If so, exactly how? 4. What do you think of the statement made in one of the AIT/DLT documents that said that AIT tape drives only clean the head, and not the tape path as well? I realize this is only May, but planning is everything. Thanks! Don Glascock -- Donald S. Glascock Mailstop GU-1016 Special Purpose Processor Development Group Mayo Foundation Rochester, MN 55905 Glascock.Donald(a)Mayo.EDU +1.507.284.1850 +1.507.284.9171 (fax) http://www.mayo.edu/sppdg/sppdg_home_page.html "No matter where you go, there you are."

1 0

rsh from NT
by Jason Middlebrooks 11 May '99

11 May '99

Now that I have been corrected about rsh working from NT how do I do it. I have the NT host name in the hosts.equiv file on the filer but everytime I try to rsh I get a permission denied. Any ideas?

2 1

Solaris/NIS/shadow-passwords
by David Lee 11 May '99

11 May '99

We are considering getting a NetApp Filer to become the major fileserver in our established cluster of Solaris 2.6 machines, with a user population of some 15,000 administered using NIS with shadow passwords for authentication. We understand that filer can do NIS, and that it can use its own shadow password file, but can use a Solaris/NIS/shadow combination? Network Appliance haven't yet been able to give us a definitive answer, nor a reference site we could contact. -- : David Lee I.T. Service : : Systems Programmer Computer Centre : : University of Durham : : Phone: +44 191 374 2882 (ddi) South Road : : Fax: +44 191 374 7759 Durham : : Internet: T.D.Lee(a)durham.ac.uk U.K. :

4 3

Re: Solaris/NIS/shadow-passwords
by sirbruce＠ix.netcom.com 11 May '99

11 May '99

On 05/10/99 14:25:10 you wrote: >However, if you are in a Unix only environment, then this doesn't >matter. The filer does no allow login, so the password portion is not >used. The only thing the filer uses the password file for is to do >username->UID mapping, so you only really need to worry about having a >password at all if you have an /etc/quotas file with usernames in it. Jerry, You're forgetting PC-NFS. Some people still use that. It would be nice if PC-NFS supported Solaris shadow passwords as well as the old SunOS 4.x NIS shadow passwords. >If you are using Unix password authentication with CIFS, however, you >have to copy the shadow file onto the filer itself. (Note that this does >not apply if you have domain authentication.) But what he wants is for the filer to support this via NIS, so he doesn't have to copy the shadow file onto the filer itself. (That is one of the main points of NIS, you know.) Bruce

2 1

Dual power on F760
by Aaron M. Sims 11 May '99

11 May '99

I've scanned the docs and the now.netapp.com site for an answer to this... no luck. How do I determine the status of either power supply in a F760 filer. If a power supply is off or failed, I'd like to run a command that will tell me just that. Thanks, Aaron -- Aaron M. Sims | "The reason why bad things happen to you is BellSouth.net | because you're a dumbass!" Systems Engineer | - Red Foreman, That 70s Show aaron.sims(a)bellsouth.net|

3 4

Re: rsh into the filer from NT
by Matt Day 10 May '99

10 May '99

Jason Middlebrooks <Jason_Middlebrooks(a)datalink.com> wrote: >I was told by someone that you can not rsh into a filer from the builtin >rsh utility NT has to offer. Am I correct on this one and is there a third >party rsh utility that will allow me to do this? I know it works great in >the UNIX evironment. No, that's not true. NT's builtin rsh works fine with the filer. Matt

1 0

RE: rsh into the filer from NT
by Benn, Paul 10 May '99

10 May '99

Hi Jason, Yes, rsh CAN be used on an NT box to issue commands to a filer. I recently released a white paper that has a section on using rsh. Check out Section 5.2 of: http://www.netapp.com/technology/level3/3052.html Hope this helps. Regards, Paul -----Original Message----- From: Jason Middlebrooks [mailto:Jason_Middlebrooks@datalink.com] Sent: Monday, May 10, 1999 2:46 PM To: toasters(a)mathworks.com Subject: rsh into the filer from NT I was told by someone that you can not rsh into a filer from the builtin rsh utility NT has to offer. Am I correct on this one and is there a third party rsh utility that will allow me to do this? I know it works great in the UNIX evironment.

1 0

rsh into the filer from NT
by Jason Middlebrooks 10 May '99

10 May '99

I was told by someone that you can not rsh into a filer from the builtin rsh utility NT has to offer. Am I correct on this one and is there a third party rsh utility that will allow me to do this? I know it works great in the UNIX evironment.

1 0

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

07 May '99

On 05/07/99 12:09:23 you wrote: >[process details snipped] >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. Well, the new process looks more efficient and sensible, but basically it amounts to eliminating P releases and putting out regular maintence releases. This is fine, but it doesn't really eliminate the problem this particular custoemr had. In the new scheme, CS would have given this customer a 5.2.1Dx patch which they'd be using when 5.2.2 came out. Due to the timing constraints you mention, the D patch might not have made it into the 5.2.2 release. The new customer, seeing 5.2.2 (either on a new filer or on NOW) assumes 5.2.2 would include 5.2.1Dx, and so downloads it and gets bitten. This was what prompted me to suggest what I did before. In the new scheme you describe, since CS can spin a D release quickly to address a customer problem, when 5.2.2 is ready for release it can be delayed only a day or two for CS to spin any Ds it needs from 5.2.1 to go with 5.2.2 that didn't make it into 5.2.2. Then when the customer running 5.2.1Dx goes to NOW, they'll not only see 5.2.2, but 5.2.2Dx with a note only to download this version if they're running 5.2.1Dx. Of course, if CS really can't spin a release that fast, then okay. But I suspect this might be what will wind up happening anyway. A customer experiences one bug, which CS fixes in 5.2.1Dx, then another bug which is fixed in 5.2.2. CS will have to spin a 5.2.2Dx release before 5.2.3 (which hopefully finally contains the 5.2.1Dx patch missing in 5.2.2) >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. Yes, barring any other corrective action at least this will provide another way an otherwise confused customer can learn not to install a certain version because the patch they want isn't in it. Bruce

1 0

Re: Dual power on F760
by sirbruce＠ix.netcom.com 07 May '99

07 May '99

On 05/07/99 16:02:32 you wrote: > >Well, here's my delima. The filer is isolated (network wise) and >has no default route to the rest of the world. SNMP won't help. > >The filer is in a remote location (800 miles away), so looking >at the LED is not a viable option. I think that even when one power supply fails and the other takes over, it will log a message in the messages file (and on the console). This may be one of those "log once every hour" messages so the customer can't miss it. So if you don't have those, I think the power supplies are OK. The message may not tell you which power supply is bad, but that's what the LED is for, since you have to have someone there in person to replace it. Bruce

1 0

RE: Dual power on F760
by Jonas Jonsson 07 May '99

07 May '99

Hmm, We have a customer that have been testing this all week. Lots of mails and SNMP traps sent all over the net. Also the LED will show this info. /// Regards, Jonas Jonas Jonsson phone: +46-8-623 65 82 Proact Datasystem AB mobile: +46-709-42 13 67 Djupdalsvägen 7 mail: jonas.jonsson(a)proact.se Sollentuna, Sweden -----Original Message----- From: Aaron M. Sims [mailto:ams@bellsouth.net] Sent: Friday, May 07, 1999 8:24 PM To: toasters(a)mathworks.com Subject: Dual power on F760 I've scanned the docs and the now.netapp.com site for an answer to this... no luck. How do I determine the status of either power supply in a F760 filer. If a power supply is off or failed, I'd like to run a command that will tell me just that. Thanks, Aaron -- Aaron M. Sims | "The reason why bad things happen to you is BellSouth.net | because you're a dumbass!" Systems Engineer | - Red Foreman, That 70s Show aaron.sims(a)bellsouth.net|

2 1

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

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

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