toasters May 2000

toasters@lists.teaparty.net

122 participants
148 discussions

storageshelf questions
by Rob Windsor 12 May '00

12 May '00

Has anyone successfully mixed FC8s and FC9s on the same FCAL loop? We currently have four FC8s connected to our F740, one FC8 not connected (no drives in it), and two FC9s just arrived (we ordered FC8s, but tech said that they'll co-exist just fine). The instructions indicate that when you connect one FC9 to an existing loop containing FC8s, you have to make it ID-0. What about the second one? (I'm assuming that we just make it ID-1, but the documentation isn't clear.) I'll probably just price what NetApp would charge to just upgrade your existing FC8s to FC9s. I'd rather have a homogeneous set of shelves, honestly. Also, I heard a nasty rumor that the F740 actually maxes out at 7 trays worth of (18Gig) disks. Is this true or can we order our 8th tray without worries? -- Rob ---------------------------------------- Rob Windsor E-Mail - mailto:rob_windsor@adc.com Senior Unix Systems Administrator Voice - phone:972-680-6919 Computer Services Fax - phone:972-680-0370 Broadband Access and Transport Group __o ADC Telecommunications _`\<,_ Richardson, TX 75082 (_)/ (_)

4 6

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

← Newer
1
...
7
8
9
10
11
12
13
14
15
Older →

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 May 2000