toasters

toasters@lists.teaparty.net

13515 discussions

Weird error messages
by Haim Dimermanas 11 May '00

11 May '00

Hi all, At last, my filer is in production :) Pfff.... almost had a hearth attack! I had to copy about 29 Gb of files in different qtree all located on the same volume. After the whole thing finished (it took 3 hours), I went to the console and saw this : Thu May 11 03:06:14 EDT [de0]: 8 CORR SYS ERR 201 eia:f6f60058b20000 fs:274f400 eis:0 isr:80000001 Thu May 11 03:06:14 EDT [de0]: ...SYS ECC error: address=0xf6f600, bit=31, DIMM=J27 Thu May 11 03:12:29 EDT [raid_stripe_owner]: 9 CORR SYS ERR 201 eia:ccf254058b20000 fs:2c3f400 eis:0 isr:80000001 Thu May 11 03:12:29 EDT [raid_stripe_owner]: ...SYS ECC error: address=0xccf2540, bit=31, DIMM=J27 Thu May 11 03:27:18 EDT [de0]: 10 CORR SYS ERR 201 eia:94960058b20000 fs:2f1f400 eis:0 isr:80000001 Thu May 11 03:27:18 EDT [de0]: ...SYS ECC error: address=0x949600, bit=31, DIMM=J27 Thu May 11 04:00:00 EDT [statd]: 4:00am up 9 days, 4:14 21685006 NFS ops, 0 CIFS ops, 0 HTTP ops Thu May 11 04:14:33 EDT [de0]: 11 CORR SYS ERR 201 eia:46545058b20000 fs:202f400 eis:0 isr:80010001 Thu May 11 04:14:33 EDT [de0]: ...SYS ECC error: address=0x465450, bit=31, DIMM=J27 Thu May 11 04:41:14 EDT [de0]: 12 CORR SYS ERR 201 eia:d578c058b30000 fs:2d0f400 eis:f0 isr:80000001 Thu May 11 04:41:14 EDT [de0]: ...SYS ECC error: address=0xd578c0, bit=31, DIMM=J27 Thu May 11 04:41:14 EDT [de0]: 13 CORR SYS ERR 201 eia:ec93b0058b20000 fs:2d0f400 eis:f0 isr:80000001 Thu May 11 04:41:14 EDT [de0]: ...SYS ECC error: address=0xec93b00, bit=31, DIMM=J27 Thu May 11 04:43:50 EDT [wafl_hipri]: 14 CORR SYS ERR 201 eia:11b2a90058b20000 fs:2b5f400 eis:0 isr:80000001 Thu May 11 04:43:50 EDT [wafl_hipri]: ...SYS ECC error: address=0x11b2a900, bit=31, DIMM=J30 Thu May 11 05:00:00 EDT [statd]: 5:00am up 9 days, 5:14 25265758 NFS ops, 0 CIFS ops, 0 HTTP ops Thu May 11 05:07:31 EDT [raid_stripe_owner]: 15 CORR SYS ERR 201 eia:1b52ca4058b20000 fs:2a3f400 eis:0 isr:80000001 Thu May 11 05:07:31 EDT [raid_stripe_owner]: ...SYS ECC error: address=0x1b52ca40, bit=31, DIMM=J30 Thu May 11 06:00:00 EDT [statd]: 6:00am up 9 days, 6:14 28703375 NFS ops, 0 CIFS ops, 0 HTTP ops can anyone explain me what this means? Is it serious? Thanks. Haim. -- @o=qw(Nu Wjoepxt2l Mjdsptpgu);@p=("jt gvdlfe vq","jt tiju","tvdlt"); for($i=0;$i<@p;$i++){$o[$i]=~y/b-y/a-z/;$p[$i]=~y/b-y/a-z/;} while(){print $o[((rand)*3)]." ".$p[((rand)*3)]."\n";}

3 3

RE: Recovering files using NetApp
by Darleen.Cormier＠netapp.com 11 May '00

11 May '00

Hi Akhilesh, You need to be running the ClientPak for NetApp on your filer, and if you are then, then you would use a special na_recover command from the command line ( The GUIs do not presently work, with this version from Legato) The na_recover command ensures that the files retain their original permissions or ACLs when they are recovered. If you need to know more about the ClientPak for NetApp, please check out Legato's web site. -----Original Message----- From: Akhilesh Kumar [mailto:akumar@egreetings.com] Sent: Wednesday, May 10, 2000 3:16 PM To: NetApp mailing list Subject: Recovering files using NetApp Hi Gurus, I am using Legato Networker to back up a F720 filer. On a Unix machine that is setup as a Legato client, I can run nwrecover on the client and recover selected files. Any ideas how to do a recover for the filer ? I can use nwadmin on the backup server, but that recovers the whole save set. I want only particular files. Thanks Akhilesh Kumar

2 1

Recovering files using NetApp
by Akhilesh Kumar 10 May '00

10 May '00

Hi Gurus, I am using Legato Networker to back up a F720 filer. On a Unix machine that is setup as a Legato client, I can run nwrecover on the client and recover selected files. Any ideas how to do a recover for the filer ? I can use nwadmin on the backup server, but that recovers the whole save set. I want only particular files. Thanks Akhilesh Kumar

1 0

RE: bootpc/DHCP on NetCache (was RE: Portscan causes DOT 5.3.2R1 to fall over?)
by Jonas Jonsson 10 May '00

10 May '00

Configure the IP address of the box manually acc to the maunal. /// Br, Jonas > -----Original Message----- > From: Colin Johnston [mailto:colinj@uk.psi.com] > Sent: 10 May 2000 16:42 > To: James R Grinter > Cc: toasters(a)mathworks.com > Subject: Re: bootpc/DHCP on NetCache (was RE: Portscan causes DOT > 5.3.2R1 to fall over?) > > > > > > seems to answer your own question - it looks like the > netcache box can > > be set up to acquire configuration via DHCP (which is, as I'm sure > > you know, basically bootp+extensions anyway and all works > on that same > > bootpc port.) > > How does one disable this DHCP functionality ?? since I know what ip's > should be allocated to the machines in question. > > Colin Johnston > SA > PSINET UK >

1 0

RE: Portscan causes DOT 5.3.2R1 to fall over?
by Sateesh Mucharla 10 May '00

10 May '00

What are effects of Virus (computer virus) on a "ntfs qtree" and on a "mixed qtree". Thanks to all who responded to my question on "Raid Groups". I am going with 12+1, 12+1,6+1 with 2 hot spares. (Totally 35 drives). Thanks Sateesh Mucharla National Semiconductors - CA.

1 0

bootpc/DHCP on NetCache (was RE: Portscan causes DOT 5.3.2R1 to fall over?)
by jrg＠acm.org 10 May '00

10 May '00

On Wed 10 May, 2000, Colin Johnston <colinj(a)uk.psi.com> wrote: >Any idea why bootpc runs in NetAppCache machines ?? >68/udp open bootpc > >Also message on console when nmap run about DHCP >Wed May 10 11:37:12 BST [de0]: Discarding packets for DHCP client port >originating from server 10.0.0.5 port 400 seems to answer your own question - it looks like the netcache box can be set up to acquire configuration via DHCP (which is, as I'm sure you know, basically bootp+extensions anyway and all works on that same bootpc port.) James.

2 1

RE: Portscan causes DOT 5.3.2R1 to fall over?
by Muhlestein, Mark 10 May '00

10 May '00

This is could be bug #12417. It's fixed in 5.3.5P2, 5.3.5R2P1, and 5.3.5R2P2. Mark Muhlestein -- mmm(a)netapp.com > -----Original Message----- > From: Brian Tao [mailto:taob@risc.org] > Sent: Tuesday, May 09, 2000 10:58 PM > To: toasters(a)mathworks.com > Subject: Portscan causes DOT 5.3.2R1 to fall over? > > > Has anyone tried portscanning a filer (or had their filer > portscanned?) Any ill effects? We ran a network-wide nmap on our own > internal network yesterday evening, and while at first it didn't seem > like it harmed anything (we weren't expecting any problems), it now > appears that some badness may have resulted on one of our F210's > running DOT 5.3.2R1. > > We started noticing the problem when NFS clients were no longer > able to establish file locks. At first, we thought this was simply > Solaris' NFS client acting up again. But then we noticed it happening > on a few other Solaris servers and also on someone's FreeBSD > workstation. > > Further digging showed that every Solaris NFS client of the F210 > logged the exact same message to syslog at roughly the same time (give > or take a couple of minutes): > > May 8 18:13:25 office.corp /usr/lib/nfs/lockd[19392]: > t_accept(file descriptor 5/transport tcp) TLI error 7 > > The lock_dump command on the filer showed a few locks in GRANTED > state, but one was for a pid that no longer existed on the given > client. At that point, any attempt to lock a file residing on that > Netapp would time out and fail. An "rpcinfo -p" showed all the usual > RPC services running (nlockmgr, status, mountd, nfs, rpcbind) except > for rquotad. I don't know if that is significant (we do have user and > tree quotas on the filer). > > The time of the syslog entries coincided with the time of the > portscan run the previous night. To test a couple of other theories, > I tried a series of TCP, UDP and RPC portscans using nmap 2.30b20 > ("nmap -sRUT"). The filer crashed almost immediately, but came back > up within a couple of minutes. Now file locking was behaving > correctly again, and a number of applications that were hanging before > now worked fine. > > I'm not sure if Netapp support will have much to go on here... no > crash dump was saved to disk and /etc/messages is clean, with the only > odd entry being: > > Tue May 9 15:39:20 EDT [de0]: Discarding packets for DHCP > client port originating from server 10.35.1.73 port 9af6. > > 10.35.1.73 is the host doing the nmap. This entry was logged just > before the filer crashed. I didn't have a console attached to the > filer at the time to watch the boot messages. The filer serves NFS as > well as CIFS. > > Anyone run across this problem before? > -- > Brian Tao (BT300, taob(a)risc.org) > "Though this be madness, yet there is method in't" >

2 1

Quota & Performance
by Fabio Pietrosanti 10 May '00

10 May '00

Hi, i'm planning to setting up quota on the Filer, but i want to know if it decrease the performance of the filer. Thanks Fabio Pietrosanti

1 0

Portscan causes DOT 5.3.2R1 to fall over?
by Brian Tao 10 May '00

10 May '00

Has anyone tried portscanning a filer (or had their filer portscanned?) Any ill effects? We ran a network-wide nmap on our own internal network yesterday evening, and while at first it didn't seem like it harmed anything (we weren't expecting any problems), it now appears that some badness may have resulted on one of our F210's running DOT 5.3.2R1. We started noticing the problem when NFS clients were no longer able to establish file locks. At first, we thought this was simply Solaris' NFS client acting up again. But then we noticed it happening on a few other Solaris servers and also on someone's FreeBSD workstation. Further digging showed that every Solaris NFS client of the F210 logged the exact same message to syslog at roughly the same time (give or take a couple of minutes): May 8 18:13:25 office.corp /usr/lib/nfs/lockd[19392]: t_accept(file descriptor 5/transport tcp) TLI error 7 The lock_dump command on the filer showed a few locks in GRANTED state, but one was for a pid that no longer existed on the given client. At that point, any attempt to lock a file residing on that Netapp would time out and fail. An "rpcinfo -p" showed all the usual RPC services running (nlockmgr, status, mountd, nfs, rpcbind) except for rquotad. I don't know if that is significant (we do have user and tree quotas on the filer). The time of the syslog entries coincided with the time of the portscan run the previous night. To test a couple of other theories, I tried a series of TCP, UDP and RPC portscans using nmap 2.30b20 ("nmap -sRUT"). The filer crashed almost immediately, but came back up within a couple of minutes. Now file locking was behaving correctly again, and a number of applications that were hanging before now worked fine. I'm not sure if Netapp support will have much to go on here... no crash dump was saved to disk and /etc/messages is clean, with the only odd entry being: Tue May 9 15:39:20 EDT [de0]: Discarding packets for DHCP client port originating from server 10.35.1.73 port 9af6. 10.35.1.73 is the host doing the nmap. This entry was logged just before the filer crashed. I didn't have a console attached to the filer at the time to watch the boot messages. The filer serves NFS as well as CIFS. Anyone run across this problem before? -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

1 0

RMA Drives
by John Tatar 09 May '00

09 May '00

As a note of caution to some of you folks out there that have older filers, we have a 540 with two volumes. 3 Shelves of 4 Gig Drive and 1 Shelf with 9 Gig Drives (all SCSI). We had one of the 9 Gig drives go out on us two weeks ago. We are still awaiting the RMA drive. Luckly I had a 9Gig'er in my spares kit or I would be all over netapp on this. But if I hadn't, 2 weeks would be like an eternity without a 9 Gig spare sitting on the shelf. Since we have a service contract, why isn't netapp maintaining an adequate inventory of spares? JT -- =================================================================== John J. Tatar Systems & Network Engineering Section Advanced Computer Applications Group Decision & Information Sciences Division Argonne National Laboratory mailto:tatar@dis.anl.gov or john(a)tatar.com Office: 630-252-3242 Fax: 630-252-5128 ===================================================================

2 1

RE: NetApp 202: Advanced System Admin
by Anissa.Mohler＠netapp.com 09 May '00

09 May '00

The complete course description is online for those that haven't seen it yet: http://www.NetApp.com/education/ (for all courses) http://www.NetApp.com/education/netapp202_new.html (for the new 202 course) This is what the course description may not tell you: The revamped NetApp 202 has some information that answers several questions that I see on this list frequently... for instance: How many RAID groups or volumes should I set up? What is wrong with my backup performance? What type of filer setup is required for Oracle 8 (and some other databases, mail systems, etc)? The class is NOT a "this is how you set up your X database on a filer" but it does give you some general ideas of things you will want to do to optimize and protect your databases. It also gives you pointers to other resources for database specific questions. You get tips for performance tuning depending on environment and tools and utilities to determine where a performance problem may come from. There is a scenario based lab where you get to determine the optimum configuration for a specific environment. The class goes into advanced concepts of the WAFL file system and NetApp architecture ... for instance, did you ever wonder why we have 20 snapshots? or how they work? Like to get a glimpse into our inode structure? You get that too. The better you understand the file system you are working with the more you are able to understand how it performs in specific situations. It also provides some great troubleshooting tools and techniques. You get thrown into hands on labs where the filer is broken and you have to fix it. (Without the added pressure of managers breathing down your neck). You get to practice recovery techniques that you will hopefully never need in real life, but if a major problem happens you will be prepared to handle it. There are many case studies where you get to review details of problems encountered by customers in the field (from easy to very hard), what NetApp and the customers did to resolve the problem and what thought process was required to do so. In addition there are labs built in to the case studies where you get to practice some of the more rarified commands in a safe environment. The class will not give you direct answers for every aspect of your environment. But it will give you the tools and concepts to find your own answers. I hope you all get a chance to attend. While some of the material is drawn from the old 202 course. Most of it is brand new, and, IMHO, worth attending. PS. If you have any suggestions for new training you'd like to see or things you would like changed in any of NetApp's course material you can e-mail NetApp Educational Services at: dl-training-feedback(a)netapp.com :-----Original Message----- :From: Derek Kelly [mailto:derek.kelly@genomecorp.com] :Sent: Tuesday, May 09, 2000 6:40 AM :To: Douglas Ritschel :Cc: toasters(a)mathworks.com :Subject: Re: NetApp 202: Advanced System Admin : : :I took the 101 and 202 as a package deal as well. While I haven't taken :the 202 class since it was revamped, I found them both to be highly :useful (I suspect that it's even better now!). Just the books alone are :worth the price of the class since they document many of the features :and "hidden" commands most admins would never know about. That's also :where I found out about this talk list and made some friends in the :business who are local to me as well. : :In short, If you're working with Filers on a regular basis, I highly :recommend this class. : :BTW, these classes are the same exact ones NetApp employees (from tech :support to engineers) must attend. There were at least 4 employees in :the same class I took. : :If you have the opportunity, try to take it right in :Sunnyvale. The area :is beautiful and the training facilities are terrific. If you do decide :to go, send me an email if you're looking for travel recommendation :particulars. : :Derek Kelly :Gennomecorp : :On 5/8/00 at 5:21 PM, Douglas.Ritschel(a)fnc.fujitsu.com (Douglas :Ritschel) wrote: : :> Has anyone taken the "NetApp 202: Advanced System Administration and :> Troubleshooting for Network Appliance Filers class. And if so, was it :> useful?

1 0

NIS problem
by Haim Dimermanas 09 May '00

09 May '00

Hello, I have been spending days with tech support on this one, and nobody seems to have a clue. This is the first time I post on this list so please excuse me for any mistake contained within this message. I searched the archives of the list but did not find anything related to this problem. I have an F740 running 5.3.4R3. The box is not yet in production because of an annoying problem regarding NIS (also known as Yellow Page). My NIS server is a Linux box running Debian 2.1 with the kernel 2.2.14 and Portmap version 5. I must say that the dns resolution on the filer works, that I am able to mount shares from any clients in my class C (including the NIS server) and of course I can ping the filer from the NIS server and I can ping the NIS server from the filer. This makes me believe that the network part of it is fine. The problem is the following : the Filer does not have access to the maps when a single server is specified in the option nis.servers. It works with a lot of garbage in the logs when I specify server,* in this same option. Just in case it helps when reading the logs, my NIS server is named "aux" (ip : 192.168.1.152). The F740 is named "filer" (ip : 192.168.1.240). I took out the dates and time to make it easier to read. -------------------- First Scenario : options nis.servers my_nis_server Message on the filer : [nis_poll]: NIS server(s) not available Message on the NIS server : (repeated every minute or so) aux portmap[14166]: connect from 192.168.1.240 to callit(ypserv): request not forwarded 'ypcat group' on the filer : No such map group.byname. Reason: Local resource allocation failure Conclusion : it does not work :( ------------------ Second Scenario : options nis.servers my_nis_server,* Message on the filer : [nis_poll]: Bound to preferred NIS server 192.168.1.152 [nis_grp_updater]: Local NIS group update successful. (and the following every two minutes or so) [nis_main]: Preferred NIS Server 192.168.1.152 not responding [nis_main]: NIS server(s) not available [nis_poll]: Bound to preferred NIS server 192.168.1.152 Message on the NIS server : (every minute or so) aux portmap[14223]: connect from 192.168.1.240 to callit(ypserv): request not forwarded 'ypcat group' on the filer : Print the proper groups from the NIS map. Works to with ypcat passwd and ypcat hosts. Conclusion : it works, sort of. ------------------- So what exactly is happening? I have an explanation, but I am IN NO WAY SURE THAT IT IS THE CORRECT ONE. It just seemed to me that it would be the more possible one. I must say that I am in no way an NIS expert but I know Linux pretty well. All this to say that yes, the hosts.allow - hosts.deny and other yp.securenets are set correctly. I think the problem comes from the portmap security scheme. I looked into portmap source code and found this in pmap_check.c : /* * pmap_check - additional portmap security. [Stuff deleted] * Refuse to forward requests to NIS (YP) daemons; The only exception is the * YPPROC_DOMAIN_NONACK broadcast rpc call that is used to establish initial * contact with the NIS server. [More stuff deleted] */ line 89 : #define log_no_forward(addr, proc, prog) \ logit(deny_severity, addr, proc, prog, ": request not forwarded") line 200 (the actual check_callit function) : check_callit(addr, proc, prog, aproc) struct sockaddr_in *addr; u_long proc; u_long prog; u_long aproc; { #ifdef HOSTS_ACCESS if (!(from_local(addr) || good_client(addr))) { log_bad_host(addr, proc, prog); return (FALSE); } #endif if (prog == PMAPPROG || prog == NFSPROG || prog == YPXPROG || (prog == MOUNTPROG && aproc == MOUNTPROC_MNT) || (prog == YPPROG && aproc != YPPROC_DOMAIN_NONACK)) { log_no_forward(addr, proc, prog); return (FALSE); } if (verboselog) log_client(addr, proc, prog); return (TRUE); } I think it nails exactly where the problem is coming from. The Filer is sending a forward request and gets denied. Why does the filer do that after the broadcast, I don't know. I am not sure if the problem comes from the filer or from my portmap implementation on my NIS server (or even my server itsef). I do really hope someone out there has a clue. Thank you for reading this and I hope to get an answer soon. Haim. -- @o=qw(Nu Wjoepxt2l Mjdsptpgu);@p=("jt gvdlfe vq","jt tiju","tvdlt"); for($i=0;$i<@p;$i++){$o[$i]=~y/b-y/a-z/;$p[$i]=~y/b-y/a-z/;} while(){print $o[((rand)*3)]." ".$p[((rand)*3)]."\n";}

3 6

NetApp 202: Advanced System Admin
by Douglas Ritschel 09 May '00

09 May '00

Has anyone taken the "NetApp 202: Advanced System Administration and Troubleshooting for Network Appliance Filers class. And if so, was it useful? -- Douglas Ritschel Fujitsu Network Communications Two Blue Hill Plaza, Sixth Floor P.O. Box 1609 Pearl River, NY 10965 Ph: 914.731.2101 Douglas.Ritschel(a)fnc.fujitsu.com

4 3

RE: NetApp 202: Advanced System Admin
by Mohler, Jeff 09 May '00

09 May '00

I might add to this, that the 202 class has been rewritten top-to-bottom and is now a much more complete 2-day class than it was in the old format. It gets much deeper into the how and _why_ things happen in ONTAP, and the applies that to how to troubleshoot failures or performance issues as they come up in the field. It covers a lot of background for what will be considered 'certification' material in the future. -----Original Message----- From: Douglas Ritschel [mailto:Douglas.Ritschel@fnc.fujitsu.com] Sent: Monday, May 08, 2000 2:22 PM To: toasters(a)mathworks.com Subject: NetApp 202: Advanced System Admin Has anyone taken the "NetApp 202: Advanced System Administration and Troubleshooting for Network Appliance Filers class. And if so, was it useful? -- Douglas Ritschel Fujitsu Network Communications Two Blue Hill Plaza, Sixth Floor P.O. Box 1609 Pearl River, NY 10965 Ph: 914.731.2101 Douglas.Ritschel(a)fnc.fujitsu.com

1 0

revert_to
by jmiddlebrooks＠datalink.com 08 May '00

08 May '00

If you are at 5.3.4r2 and you want to back down to 5.3.4 do you first have to run revert_to 5.2 and then upgrade to 5.3.4? When you run revert_to is says you can only revert to 5.0, 5.1, or 5.2 Thanks for any help. Jason Middlebrooks Systems Engineer Datalink Corp. 888-933-9327 x2970

3 2

Re: Error from filer; bad RAM?
by Jamie A. Lawrence 08 May '00

08 May '00

>> Hi - >> >> Once again, Netapp tech support seems to be taking their sweet >> time about responding to my support email, so I'm going to folks >> that actually respond... >> >> Got this in the logs of one of my 720s. Is this telling me >> I've got bad RAM? > >There was an error in the J28 DIMM that was corrected, a couple of times. > >> It hasn't recurred since that date, but still worries me. > >Since it hasn't happened again, I wouldn't worry about it. >The timing seems to indicate that perhaps something was >going on unusual at that time, perhaps a raid scrub or a >heavy load from cron or somesuch? It is not unusual to >see more errors during times of heavier stress. > >You might want to consider reseating that DIMM just >to make sure it has a good connection. Then I wouldn't >worry unless you start seeing a LOT more errors. But >support may tell you different. > >Bruce Thanks, Bruce. Actually, it repeated several hundred times that night, never since. First time for that error in over a year in owning it, which is why it made me twitchy. Cron-wise, nothing interesting changed. Scrubbing has been going on forever. Yikes, I hate to play this loose with it, but it will be mirrored to another 720 in a few weeks, so hopefully it won't matter. We're extremely dependent on this filer. I know we're a minor player in Netapp's realm ( we own 4 720s ), but the lack of response for such a critical piece of machinery for me makes me wonder. Guess I won't blow off the next EMC call that is due to hit voice mail in a couple of weeks. Thanks again for the note, Bruce. -j

3 2

RE: Solaris 7 & NFS2/NFS3/TCP/UDP....
by Rainchik, Aleksandr (MED, Non GE) 08 May '00

08 May '00

Thank you, That really helped (boosted TPS from 38 to 83 :). Is this option documented or not? I can't find it in the manual... P.S. Still a big problem with NFS2 performance. We have (besides of Solaris) lots of IRIX boxes, and (surprise) if you use automount on IRIX all mounts are NFS2 only... -----Original Message----- From: Keith Brown [mailto:keith@netapp.com] Sent: Wednesday, March 22, 2000 4:23 PM To: Rainchik, Aleksandr (MED, Non GE) Subject: Re: Solaris 7 & NFS2/NFS3/TCP/UDP.... > b) There is no way to use w/rsize=32768 with > NetApp with NFS3 over UDP. Why? I can do it > when mounting from Solaris. Did you set the nfs.udp.xfersize set to 32768? Like so.... filer> options nfs.udp.xfersize 32768 Keith

5 5

RE: autosupport retries (was Re: Apology and Request)
by Hackworth, Brian 08 May '00

08 May '00

: From: dnb(a)ccs.neu.edu [mailto:dnb@ccs.neu.edu] : Quick question: once upon a time, machine-gone-kablooey autosupport : mail was only sent when a filer booted. It was the Yoda scenario : ("there is no retry, only do!"). If something went awry in that : sending, the message was just dropped on the floor, no queuing, no : retrying. Beginning in ONTAP 5.3.4, autosupport that can't be sent is queued and retried periodically, with messages written to /etc/messages describing what's going on. The autosupport mail eventually gets dropped if the net or NIS (or whatever) situation isn't fixed, and it's dropped if the filer reboots before the mail goes out, but when the filer eventually comes up, we can patch together much of what happened from the message log. The retry window is 15 minutes in 5.3.4, lengthened to an hour in the "next major release". - Brian -- Brian Hackworth hackwort(a)netapp.com Network Appliance 408.822.6654 Sunnyvale, CA USA

3 2

RE: 18GB drive performance versus 36BG
by Mohler, Jeff 08 May '00

08 May '00

The new 9G drive is a 10K RPM drive from the same family as the Hi-Po 18 and 36G drive, and can only be used in the new FC9 storage shelves. ONTAP, firmware, and head/model limitaion apply. See now.netapp.com or your salesdude for more info. -----Original Message----- From: Brian Tao [mailto:taob@risc.org] Sent: Friday, May 05, 2000 12:10 AM To: Mohler, Jeff Cc: toasters(a)mathworks.com Subject: RE: 18GB drive performance versus 36BG On Thu, 4 May 2000, Mohler, Jeff wrote: > > There is also a new high-performance (spindle rate/seek rate) 9G > drive now as well for those special environments. Which drive is this? -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

1 0

Budtool
by Jay Orr 08 May '00

08 May '00

Humm.. I was visiting PDC's web site to see if there was any new info about the migration of Budtool (will be EOL'd Jan 2001), and noticed the one year mark for the beginning of their migration program has passed : http://www.pdc.com/BTMigration.html Still am unable to find out anything - has anyone else? Wondering if they're ignoring everyone or just us... ----------- Jay Orr Systems Administrator Fujitsu Nexion Inc. St. Louis, MO

2 2

Error from filer; bad RAM?
by Jamie Lawrence 06 May '00

06 May '00

Hi - Once again, Netapp tech support seems to be taking their sweet time about responding to my support email, so I'm going to folks that actually respond... Got this in the logs of one of my 720s. Is this telling me I've got bad RAM? It hasn't recurred since that date, but still worries me. Sun Apr 30 12:01:28 PDT [de1]: 11 CORR SYS ERR 201 eia:6cfce0058930000 fs:1ee0015 eis:0 isr:80000001 Sun Apr 30 12:01:28 PDT [de1]: ...SYS ECC error: address=0x6cfce00, bit=19, DIMM=J28 Sun Apr 30 12:02:43 PDT [de3]: 12 CORR SYS ERR 201 eia:3ced0058930000 fs:1ee0015 eis:0 isr:80000001 Sun Apr 30 12:02:43 PDT [de3]: ...SYS ECC error: address=0x3ced00, bit=19, DIMM=J28 Sun Apr 30 12:02:50 PDT [de3]: 13 CORR SYS ERR 201 eia:47634058930000 fs:1ee0015 eis:0 isr:80000001 Sun Apr 30 12:02:50 PDT [de3]: ...SYS ECC error: address=0x476340, bit=19, DIMM=J28 Sun Apr 30 12:03:09 PDT [de2]: 14 CORR SYS ERR 201 eia:6cfce0058930000 fs:1ee0015 eis:0 isr:80000001 Sun Apr 30 12:03:09 PDT [de2]: ...SYS ECC error: address=0x6cfce00, bit=19, DIMM=J28 Sun Apr 30 12:03:37 PDT [de3]: 15 CORR SYS ERR 201 eia:6cfce0058930000 fs:1ee0015 eis:0 isr:80000001 Sun Apr 30 12:03:37 PDT [de3]: ...SYS ECC error: address=0x6cfce00, bit=19, DIMM=J28 -j

2 1

Re: raid failure
by G D Geen 06 May '00

06 May '00

I have lived through this harrowing experience. Yes there were warning signs but as I was busy performing other tasks I did not see them. The moral of my story is to read your weekly message logs and have good back ups. I also file every weekly autosupport message. I have message logs from everyone of my filers, we currently have twenty-one, dating back to 1996 when I started this position. It began with a phone call in the middle of the night. On the other end was a co-worker confused as to why the filer was no longer serving data. She had made the determination that there was a failed disk, but little did she know what the next fifteen hours would bring. The reported disk failure was being reconstructed but would never complete. That is when I got the phone call. By this time it was just after 10:00 PM and I rushed into work. I immediately got the run down on the problem she was seeing and what actions were taken. From that point I made a few stabs at getting the RAID to reconstruct. My attempts also failed, now we had to call NetApp support. I made the priority one call and was soon contacted by a NetApp engineer. After a couple of hours poking around on the filer, we were able to determine the sequence of events leading up to the nights exercises in futility. Approximately two weeks prior, the filer had reported in the messages logs that a disk in RAID group zero on volume zero, the root volume, had an unrecoverable read error but did not fail the disk. This night, now closer to morning, the system failed a different disk in RAID group zero on volume zero. See the connection? The net result was the filer could not reconstruct the data because of the unrecoverable read error on the earlier disk. The filer could not make any sense of the data coming off the corrupted sector of the disk. By this time our local support people were awaken by the central support team and had joined us. We were starting to draw a crowd. It was closing in on 2:00 AM when we tried to reconstruct the disk with the bad read sector manually but after a couple of failed attempts even the NetApp engineer was beginning to sound depressed. Then came the question. The one that all data managers hate to hear. How good are your backups? To this question I replied, "we are about to find out." Since our root volume failed, the first step was to make a new root volume. I made /vol/vol1 our new root volume. Next we destroyed /vol/vol0 and removed all the troubled disk drives. Since all of these disks are now spares, we may create a new RAID group and a new /vol/vol0. Here it is important to note that there must be a /etc on the volume *before* Veritas can begin its data restore. Once the volume was recreated, we began our restore of approximately 150 Gigabytes of data which took us well into the morning. The NetApp engineer in California and I had a long conversation over the phone while the data restores were beginning. He was certain that there should have been some sort of sign that this was about to happen. I assured him that I would look and would forward my results to our local support people, who are copied on the autosupport messages too. As I went back through the autosupport logs that are e-mailed to me each week, I found that the problem began approximately two weeks earlier. Every time a the disk tried to read a particular sector of the disk, an error messages would appear the messages log indicating such an event had occurred. Had I not been busily working other issues, to the detriment of my filers, I would have failed this disk at lease a week prior. -gdg Mark D Fowle wrote: > I have heard a few horror stories lately about netapps and multi-disk raid > failures. Has anyone out there experienced this > and what did you do for recovery ? Where there any warnings? I have not had > this happen and would like to do as much > as possible to prevent it. > > Thanks, > =============================================================================== > ======= > Mark Fowle > Caterpillar/BCP > Cary North Carolina > =============================================================================== > ======= -- --------------------------------------------------------------- G D Geen mailto:geen@ti.com Texas Instruments Phone : (214)480.7896 System Administrator FAX : (214)480.7676 --------------------------------------------------------------- Life is what happens while you're busy making other plans. -J. Lennon

7 7

Re: raid failure
by Richard L. Rhodes 06 May '00

06 May '00

On 3 May 2000, at 18:29, owner-toasters(a)mathworks.com wrote: > Unfortunately, this only works if we get the autosupport in the first > place. Apparently there are a number of customers who think we don't > want to be bothered. We do! If your filer or NetCache doesn't list > 'autosupport(a)netapp.com' in the 'autosupport.to' option, please add > it if your policies allow this. > I'm a new netapp customer (less than a year). I've found autosupport a little frustrating. For myself, the problem is the lack of feedback. I set up autosupport to send messages to several internal addresses and NetApp. I get the email just fine, but I have no way of knowing if NetApp got the email. I'd use the "options autosupport.doit just testing" command to send a test. I'd get the email, but I had no way to know if NetApp got the email. I almost called support to ask if anyone could tell me whether they got the emails! I'd like to see several things: 1) an auto reply message sent back from NetApp acknowledging that they got the autosupport email. 2) If you run it through some tool for analysis, I'd like to have the output emailed back to me. Here's another example. Since upgrading DataOntap, the autosupport email says that my gigabit ethernet cards are in the wrong slots. These cards are in the slots that the factory put them in. NetApp support has said nothing and the filers are working fine - so I've done nothing. Am I wrong? Rick

4 3

Raid groups
by Sateesh Mucharla 06 May '00

06 May '00

I am buying a F760 with 35 drives (all 36GB). As there is limitation of 28 drives per raid group ( i read it NetApp Sysadmin manual), i am thinking of having two raid groups one with 26 and the other with 7 drives. Rest two will be hot spares. But i am open for better configuration. I would like to know whether i can configure all 33 drives into one raid group - Is that possible? If so what are the disadvantages. (With 33 drives in one raid group, i loose only one drive as a parity drive - this is an advantage). Can somebody suggest a better configuration ? Thanks Sateesh Mucharla National Semiconductors

3 2

autosupport RE: Apology and Request (was Re: raid failure)
by Klinkner, Steve 05 May '00

05 May '00

> -----Original Message----- > From: dnb(a)ccs.neu.edu [mailto:dnb@ccs.neu.edu] > Dave Hitz <hitz(a)netapp.com> writes: > > > I also have a request. Please turn on autosupport. That's > > extremely important to us for two reasons: > > Quick question: once upon a time, machine-gone-kablooey autosupport > mail was only sent when a filer booted. It was the Yoda scenario > ("there is no retry, only do!"). If something went awry in that > sending, the message was just dropped on the floor, no queuing, no > retrying. > > We had a situation where our filer bounced twice, but on the first > return to service it didn't have good net (or NIS, or name resolution, > can't recall which). This meant that the first "here's the problem" > mail never got to the mothership, but the "just booted, everything is > peachy" mail did. Does the crash autosupport facility do anything more > sophisticated these days? (he asks, because his filer hasn't > crashed in > many moons...). ONTAP 5.3.4 got a change which has autosupport retry delivery for about 15 minutes. This should help with transient failures such as the mailhost rebooting, temporary loss of DNS, et cetera. In the "next major release" the retry interval has been boosted to an hour. In addition, autosupport will wait until boot is fully complete before trying to do *anything*. This will prevent autosupport from issuing silly syslog messages saying it can't deliver mail because the network isn't up (prior to 5.3.4, that behavior could cause loss of a message, in 5.3.4 it is annoying/silly, and in the "next major release" it will go away completely). ---------------------------------------------------------------------- steve klinkner klink(a)netapp.com

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