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

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