toasters

toasters@lists.teaparty.net

13520 discussions

options cift.home_dir question
by Jones, Bill 20 Nov '99

20 Nov '99

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 How do I turn it off??? It seemed like a good idea at the time, but now users are concerned that their homedirs are a share for everyone to see. The question load is getting very repetitive and annoying!!!! Thanks in advance. Bill -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.1 iQA/AwUBODX4t/poFdhjwhvjEQL8pgCfZx9qsvekgCGtS11y79pLADYCvRMAnijQ V88oVOycQszl87SJ2zFwC7F5 =kZjI -----END PGP SIGNATURE-----

1 0

Mailing list
by dennism＠dtn.com 19 Nov '99

19 Nov '99

Can I be added to the toasters mailing list? Thank you, dennis

1 0

SCSI bus timeout
by Dave Toal 19 Nov '99

19 Nov '99

Folks, Ignorance question here, if you don't mind. We're seeing this timeout error -- "relog syslog SCSI drive 6.0 max timeout count exceeded" followed by "Resetting SCSI bus 6 (ha #3)". However, sysconfig -r doesn't show drive 6.0 on ha id 3 anywhere. Could someone please explain what's going on here? Thanks much. Dave Stephen Lasseter wrote: > Fri Nov 19 00:00:01 GMT [smith: statd]: 12:00am up 25 days, 2:48 169239880 NFS ops, 0 CIFS ops, 63 HTTP ops > Fri Nov 19 01:00:01 GMT [smith: statd]: 1:00am up 25 days, 3:48 169345577 NFS ops, 0 CIFS ops, 63 HTTP ops > Fri Nov 19 02:00:01 GMT [smith: statd]: 2:00am up 25 days, 4:48 169451567 NFS ops, 0 CIFS ops, 63 HTTP ops > Fri Nov 19 02:20:08 GMT [smith: isp_timeout]: 6.0(0xfffffc0000e84180): command timeout, retrying request > Fri Nov 19 02:20:08 GMT [smith: isp_timeout]: Resetting SCSI bus 6 (ha #3) > Fri Nov 19 02:25:34 GMT [smith: isp_timeout]: 6.0(0xfffffc0000e84660): command timeout, retrying request > Fri Nov 19 02:25:34 GMT [smith: isp_timeout]: Resetting SCSI bus 6 (ha #3) > Fri Nov 19 02:32:05 GMT [smith: rc]: de_main: e0 : Link up. > Fri Nov 19 02:32:05 GMT [smith: rc]: relog syslog Fri Nov 19 02:30:53 GMT [smith: isp_timeout]: 6.0(0xfffffc0000e84b40): command timeout, retrying request > > Fri Nov 19 02:32:05 GMT [smith: rc]: relog syslog SCSI drive 6.0 max timeout count exceeded - system resetting to recover! > > Fri Nov 19 02:32:05 GMT [smith: rc]: NetApp Release 5.2.1P2 boot complete. Last disk update written at Fri Nov 19 02:30:22 GMT 1999 > > smith> sysconfig -r > Volume brs1 > > RAID group 0 > > RAID Disk HA.ID HA SHELF BAY CHAN Used (MB/blks) Phys (MB/blks) > --------- ----- ------------ ---- -------------- -------------- > parity 0a.8 0a 1 0 FC:A 17000/34816000 17366/35566480 > data 0a.1 0a 0 1 FC:A 17000/34816000 17366/35566480 > data 0a.4 0a 0 4 FC:A 17000/34816000 17366/35566480 > data 0a.0 0a 0 0 FC:A 17000/34816000 17366/35566480 > data 0a.5 0a 0 5 FC:A 17000/34816000 17366/35566480 > data 0a.13 0a 1 5 FC:A 17000/34816000 17366/35566480 > data 0a.10 0a 1 2 FC:A 17000/34816000 17366/35566480 > data 0a.3 0a 0 3 FC:A 17000/34816000 17366/35566480 > data 0a.11 0a 1 3 FC:A 17000/34816000 17366/35566480 > data 0a.9 0a 1 1 FC:A 17000/34816000 17366/35566480 > data 0a.2 0a 0 2 FC:A 17000/34816000 17366/35566480 > data 0a.28 0a 3 4 FC:A 17000/34816000 17366/35566480 > data 0a.29 0a 3 5 FC:A 17000/34816000 17366/35566480 > data 0a.30 0a 3 6 FC:A 17000/34816000 17366/35566480 > > Volume spool (root) > > RAID group 0 > > RAID Disk HA.ID HA SHELF BAY CHAN Used (MB/blks) Phys (MB/blks) > --------- ----- ------------ ---- -------------- -------------- > parity 0a.12 0a 1 4 FC:A 17000/34816000 17366/35566480 > data 0a.14 0a 1 6 FC:A 17000/34816000 17366/35566480 > data 0a.6 0a 0 6 FC:A 17000/34816000 17366/35566480 > > Volume inbox > > RAID group 0 > > RAID Disk HA.ID HA SHELF BAY CHAN Used (MB/blks) Phys (MB/blks) > --------- ----- ------------ ---- -------------- -------------- > parity 0a.17 0a 2 1 FC:A 17000/34816000 17366/35566480 > data 0a.16 0a 2 0 FC:A 17000/34816000 17366/35566480 > data 0a.18 0a 2 2 FC:A 17000/34816000 17366/35566480 > data 0a.21 0a 2 5 FC:A 17000/34816000 17366/35566480 > data 0a.22 0a 2 6 FC:A 17000/34816000 17366/35566480 > data 0a.24 0a 3 0 FC:A 17000/34816000 17366/35566480 > data 0a.25 0a 3 1 FC:A 17000/34816000 17366/35566480 > > Volume hostapp > > 0a 1 4 FC:A 17000/34816000 17366/35566480 > data 0a.14 0a 1 6 FC:A 17000/34816000 17366/35566480 > data 0a.6 0a 0 6 FC:A 17000/34816000 17366/35566480 > > Volume inbox > > RAID group 0 > > RAID Disk HA.ID HA SHELF BAY CHAN Used (MB/blks) Phys (MB/blks) > --------- ----- ------------ ---- -------------- -------------- > parity 0a.17 0a 2 1 FC:A 17000/34816000 17366/35566480 > data 0a.16 0a 2 0 FC:A 17000/34816000 17366/35566480 > data 0a.18 0a 2 2 FC:A 17000/34816000 17366/35566480 > data 0a.21 0a 2 5 FC:A 17000/34816000 17366/35566480 > data 0a.22 0a 2 6 FC:A 17000/34816000 17366/35566480 > data 0a.24 0a 3 0 FC:A 17000/34816000 17366/35566480 > data 0a.25 0a 3 1 FC:A 17000/34816000 17366/35566480 > > Volume hostapp > > RAID group 0 > > RAID Disk HA.ID HA SHELF BAY CHAN Used (MB/blks) Phys (MB/blks) > --------- ----- ------------ ---- -------------- -------------- > parity 0a.20 0a 2 4 FC:A 17000/34816000 17366/35566480 > data 0a.19 0a 2 3 FC:A 17000/34816000 17366/35566480 > > Spare disks > > RAID Disk HA.ID HA SHELF BAY CHAN Used (MB/blks) Phys (MB/blks) > --------- ----- ------------ ---- -------------- -------------- > spare 0a.27 0a 3 3 FC:A 0 17366/35566480 > spare 0a.26 0a 3 2 FC:A 0 17366/35566480 > > Partner disks > > RAID Disk HA.ID HA SHELF BAY CHAN Used (MB/blks) Phys (MB/blks) > --------- ----- ------------ ---- -------------- -------------- > partner 1.0 1 0 0 FC:B 0 17366/35566480 > partner 1.1 1 0 1 FC:B 0 17366/35566480 > partner 1.2 1 0 2 FC:B 0 17366/35566480 > partner 1.3 1 0 3 FC:B 0 17366/35566480 > partner 1.4 1 0 4 FC:B 0 17366/35566480 > partner 1.5 1 0 5 FC:B 0 17366/35566480 > partner 1.6 1 0 6 FC:B 0 17366/35566480 > partner 1.8 1 1 0 FC:B 0 17366/35566480 > partner 1.9 1 1 1 FC:B 0 17366/35566480 > partner 1.10 1 1 2 FC:B 0 17366/35566480 > partner 1.11 1 1 3 FC:B 0 17366/35566480 > partner 1.12 1 1 4 FC:B 0 17366/35566480 > partner 1.13 1 1 5 FC:B 0 17366/35566480 > partner 1.18 1 2 2 FC:B 0 17366/35566480 > partner 1.19 1 2 3 FC:B 0 17366/35566480 > partner 1.20 1 2 4 FC:B 0 17366/35566480 > partner 1.14 1 1 6 FC:B 0 17366/35566480 > partner 1.16 1 2 0 FC:B 0 17366/35566480 > partner 1.17 1 2 1 FC:B 0 17366/35566480 > partner 1.22 1 2 6 FC:B 0 17366/35566480 > partner 1.21 1 2 5 FC:B 0 17366/35566480 > partner 1.32 1 4 0 FC:B 0 17366/35566480 > partner 1.33 1 4 1 FC:B 0 17366/35566480 > partner 1.34 1 4 2 FC:B 0 17366/35566480 > partner 1.35 1 4 3 FC:B 0 17366/35566480 > partner 1.36 1 4 4 FC:B 0 17366/35566480 > partner 1.37 1 4 5 FC:B 0 17366/35566480 > partner 1.38 1 4 6 FC:B 0 17366/35566480 > smith> > -Steve

3 2

64-bit protocol ops counters?
by Brian Tao 19 Nov '99

19 Nov '99

Easy question... did anything change since 5.2.1 to give us 64-bit ops counters? A couple of our F740's are busy enough to roll 2^32 NFS ops every two weeks, and I get bogus stuff like: # rsh nfs3 nfsstat -l 10.35.10.2 tor-adm1-nfs NFSOPS = 759822365 (4294967087%) 10.35.10.3 tor-dev1-nfs NFSOPS = 79004302 (4294967275%) 10.35.10.17 tor-vs1-nfs NFSOPS = 2388554097 (528%) 10.35.10.18 tor-vs2-nfs NFSOPS = 3999698242 (82%) 10.35.10.19 tor-vs3-nfs NFSOPS = 1563148406 (4294966864%) 10.35.10.20 tor-vs4-nfs NFSOPS = 576153104 (4294967138%) 10.35.10.21 tor-vs5-nfs NFSOPS = 2690811725 (444%) 10.35.10.26 tor-fp1-nfs NFSOPS = 466426683 (4294967168%) Tue Nov 16 23:00:01 EST [nfs3: statd]: 11:00pm up 116 days, 2:53 4281632236 NFS ops, 0 CIFS ops, 0 HTTP ops Wed Nov 17 00:00:02 EST [nfs3: statd]: 12:00am up 116 days, 3:53 4291222987 NFS ops, 0 CIFS ops, 0 HTTP ops Wed Nov 17 01:00:01 EST [nfs3: statd]: 1:00am up 116 days, 4:53 4730533 NFS ops, 0 CIFS ops, 0 HTTP ops Wed Nov 17 02:00:01 EST [nfs3: statd]: 2:00am up 116 days, 5:53 12718144 NFS ops, 0 CIFS ops, 0 HTTP ops -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

1 0

Re: NetApp CEO
by Graydon Dodson 19 Nov '99

19 Nov '99

FYI. I know from personal experience that Dan Warmenhoven (Netapp's CEO) is a regular reader of this list..... Graydon Dodson grdodson(a)lexmark.com Lexmark International Inc.

1 0

where can I get F330 parts?
by Jay Orr 18 Nov '99

18 Nov '99

I was wondering with the EOL on the F330's, we had been thinking of adding more space, but to do so we'd need : 1) Another SCSI card. 2) More memory to handle it. 3) Another Tray. Anyone know where I can find this stuff? New or used... Anyone out there scrapping theirs? ----------- Jay Orr Systems Administrator Fujitsu Nexion Inc. St. Louis, MO

1 0

No more 4GB drives available??
by Dane Jasper 17 Nov '99

17 Nov '99

I've got an F230 that I need disks for, but Netapp is telling me that they don't have any to sell. I need the space, and would like to buy disks. Does anyone have a source for these, or some to sell? I'm looking for like four to six drives. -- Dane Jasper Sonic.net, Inc. (707)522-1000 mailto:dane@sonic.net http://www.sonic.net/ Key fingerprint = A5 D6 6E 16 D8 81 BA E9 CB BD A9 77 B3 AF 45 53

3 2

case #79131, Very Poor Backup performances: 1Gb/H with Veritas Netbackup through NFS
by Pierre Maubert 16 Nov '99

16 Nov '99

Hi, We have several F330 in TIF, 2 of them have an enourmous number of small files: over 3.5M for one single volume. We have increase the maxfiles value to 4328504. We have currently a significative degradation of backup performances on these 2 servers: backup are done at 1.5Gb, on both server, wheras we reach 5Gb/h for the 3 others. Servers are all running Dataontap5.2.3, and are all identical. F330, 128Mb Ram, 24*4Gb disks, I wonder what kind of fine tuning can be done to speed up the backup. -- Regards, Pierre . +------------------------------------------------------+ | Pierre Maubert, Sys_Admin Texas Instruments France | | email:p-maubert@ti.com Tel: +33 49322.2681 | | Fax: +33 49202.4669 Pager: 0606498982 | +------------------------------------------------------+

11 22

RE: FC-AL: Onboard vs. PCI Adapter Card
by Norman, Paul 16 Nov '99

16 Nov '99

> -----Original Message----- > From: Shaun T. Erickson [mailto:ste@research.bell-labs.com] > Sent: Monday, November 15, 1999 8:27 PM > To: Norman, Paul > Cc: toasters(a)mathworks.com > Subject: Re: FC-AL: Onboard vs. PCI Adapter Card > > > "Norman, Paul" wrote: > > > > Over the last couple days, there has been some discussion > about on-board FC-AL > > in our filers. This summer, NetApp started shipping > filers with an FC-AL > > adapter card rather than the on-board FC-AL to improve > reliability and > > performance. We did this because we found errors which, > though recoverable, > > potentially effect performance and loop stability. The > problem effected a very > > small fraction, just a few percent, of the installed base. > > Thank you for your reply. However, you didn't address the main > concern/perception of many folks here: that NetApp apparently shipped > many F700 series systems with onboard FC-AL controllers that had hard > failures shortly after being put into production, after which NetApp Perhaps I missed some e-mails, but I didn't see anyone suggesting that there were "many F700" filers that had "hard failures shortly after being put into production". As I said the number of filers with instability problems was quite small. We've shipped on the order of 5,000 F700 series filers, the vast majority of which run fine on on-board FC-AL. About one percent of these exhibited instability on the on-board FC-AL and not all of those the instant they were put into production. All that being said, as I look back on how we handled this problem I think NetApp should have been more aggressive in alerting the installed base. You can't be a chicken little crying the sky is falling every time you have a hiccup in the production line, but you also have to recognize when an issue is not just temporary problem. > apparently started sending out new filers with the PCI card > pre-installed, to be used in place of the onboard controller. That's > quite different from what you just described. > > Can you elaborate on and clarify this issue for us, please? I think I've been pretty clear, but please feel free to call me tomorrow if you want to discuss further. 408 822 6288 is my direct line. > > TIA, > -ste >

1 0

dump to Solaris tapehost w/ATL L200 fails
by Dennis Chandler 16 Nov '99

16 Nov '99

I am trying to use dump on a Network Appliance 230 (ontap 4.3.3) to dump to a remote tapehost. The remote tapehost is Solaris 2.5.1 with an ATL PowerStore L200 ( 5 tape loader). I realize that dump has reached the EOT. However, I'm having trouble getting dump to go to the next tape. If I list the /dev/nrst* files there is no /dev/nrst2. Here is the error message. Dennis Chandler > filer> dump 0ufb tapehost:/dev/nrst1 126 / > ... > DUMP: 66% done, finished in 2:23 > DUMP: Remote tape device write: expected 129024, got 0 > DUMP: write failed > DUMP: The ENTIRE dump is aborted. > DUMP: deleting "snapshot_for_dump.9" snapshot.

2 2

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