toasters

toasters@lists.teaparty.net

3 participants
13514 discussions

SUMMARY: Off Subject: Net App Mailing List
by grdodson＠lexmark.com 06 Aug '99

06 Aug '99

The following went out on sun-managers today...... Graydon Dodson ----- Begin Included Message ----- From sun-managers-relay(a)sunmanagers.ececs.uc.edu Fri Aug 6 14:55:38 1999 Date: Thu, 5 Aug 1999 21:49:49 -0700 (PDT) From: Ping Wei <wei(a)sfo.erg.sri.com> Subject: SUMMARY: Off Subject: Net App Mailing List To: sun-managers(a)sunmanagers.ececs.uc.edu Hi, Thanks to Bernhard Weinelt mgx(a)spruce.lsd.ornl.gov Darren Dunham The list is: toasters(a)mathworks.com. To subscribe: Sending email to lists(a)mathworks.com with 'subscribe toasters' as the body of the email. Marc Summers has different suggestion: As long as you are considering file servers I would seriously consider MDL corp. They are the Mother of Network Appliance and have a similar file server for about half the price, and it is rich with features, and is more flexable than the Network Appliance filer. Check out www.mdlcorp.com I think you will be very pleased. ------------- Original Question ------------- Hi, Sorry this is off subject. I have seen couple of discussion about Network Appliance File Server. Does anybody know any mailing list regarding Net App Servers? Thanks. -- Ping Wei wei(a)erg.sri.com ------------- End ------------- ----- End Included Message -----

1 0

Re: Disk death rate by usage pattern
by sirbruce＠ix.netcom.com 06 Aug '99

06 Aug '99

On 08/06/99 14:44:03 you wrote: > >"Soren S. Jorvang" <soren(a)t.dk> writes: > >> For instance, I wouldn't be surprised if parity disks had different >> failure patterns than data disks. > > >Interesting, the disks I have seen the *least* ammount of failures >has been on the parity drive. Usually, any new generation of drives >has some issues that need to be shaken out, so the first few months >proove to have higher infant-mortality-rates for (new) drives. In my experience, parity drives were the most likely to fail, although the ratio of failures of parity:data may have been as slim as 3:2. Most failures were *not* correlated with load, mainly because Netapp load tests all the drives before selling them, and any such failures are usually seen within the first few days. So you're left with fairly normal disks that just decide to fail whenever in the middle of the night just to annoy you. :) The exception would be a greater chance of a failure during the intense load caused during disk reconstruction, but mainly that was due, I think, to a priori problems with the disk that went undetected. RAID scrubbing took care of that issue for the most part. This is just my experience. I'm sure Netapp has data on all of their parts and their relative failure rates; this would also address the earlier question about NIC failures. (BTW, I agree with the general consensus that the onboard NIC seems to be the most likely to fail among various models.) They might be willing to share it if you ask them (probably under NDA). Bruce

1 0

Re: Disk death rate by usage pattern
by alexei＠mindspring.net 06 Aug '99

06 Aug '99

"Soren S. Jorvang" <soren(a)t.dk> writes: > For instance, I wouldn't be surprised if parity disks had different > failure patterns than data disks. Interesting, the disks I have seen the *least* ammount of failures has been on the parity drive. Usually, any new generation of drives has some issues that need to be shaken out, so the first few months proove to have higher infant-mortality-rates for (new) drives. YMMV. Alex

1 0

Disk death rate by usage pattern
by Soren S. Jorvang 06 Aug '99

06 Aug '99

Hi, I was idly wondering if you (the NetApp guys) have statistics on which disk usage patterns in filers are most likely to cause disks to die or fail otherwise. For instance, I wouldn't be surprised if parity disks had different failure patterns than data disks. -- Soren

1 0

None
by Gilles TOURPE 06 Aug '99

06 Aug '99

subscribe toasters ------------------------------------------------------------ Gilles TOURPE - System and Network Administrator APS BNP ARBITRAGE - Salle des marches ACTIONS - PARIS - France Phone : (33)-1-40-14-24-03 e-mail : gilles(a)bnpcn.com

1 0

(no subject)
by Matt Reynolds 06 Aug '99

06 Aug '99

subscribe toasters

1 0

subtle changes cause problems
by Graham C. Knight 06 Aug '99

06 Aug '99

A "df" on a 5.2.1P2D14 system shows: Filesystem kbytes used avail capacity Mounted on vol0 396529396 302447476 94081920 76% /vol/vol0/ snap reserve 69975772 66004776 3970996 94% /vol/vol0/.. nosnap 15813736 8979244 6834492 57% /vol/nosnap/ snap reserve 0 0 0 ---% /vol/nosnap/.. On a 5.2.3 system it shows: /vol/vol0/ 549255588 211150080 338105508 38% /vol/vol0/ /vol/nosnap/ 78241536 67460044 10781492 86% /vol/nosnap/ The "snap reserve" line has disappeared. That makes my SNMP query of the percentage of snap space being used return a bogus number (which happens to be 100% which sets off various alarms) :-( Is there any way to get the snap reserve lines back *without* turning nosnapdir off? Or is there a better way to get the nunmber via SNMP? I'm using mib numbers that appear to use the same output that the "df" command uses ie: Target[ast-h-dcf01.snapshot]: 1.3.6.1.4.1.789.1.5.4.1.6.2&1.3.6.1.4.1.789.1.5.4.1.6.2:public@ast-h-dcf01 Thanks, Graham

1 0

None
by Hiu-Man Cheung 06 Aug '99

06 Aug '99

subscribe toasters

1 0

Re: disk_fw_update
by Michael Salmon 06 Aug '99

06 Aug '99

+----- On Thu, 05 Aug 1999 13:06:37 PDT, kevin graham writes: | | I was reading the docs prior to upgrading to 5.2.3, and I realized that I get | to upgrade everything, os, filer fw, and disk fw.. | | The thing that occured to me as unfortunate was from na_disk_fw_update(1): | | This command makes disks inaccessible for up to 2 minutes, so network | sessions using the filer should be closed down before running it. We have noticed that the ATM driver also shuts down when disk_fw_update is run in 5.3. Again it isn't a big deal as you shouldn't need to run the command often but it doesn't make me feel warm inside. On a related note, I note that disk_fw_update can be run from telnet and rsh in 5.3. My understanding was that disk_fw_update wasn't a security problem because it could only be run from the console. /Michael

1 0

Re: tape drives in a cluster
by Michael Salmon 06 Aug '99

06 Aug '99

+----- On Thu, 05 Aug 1999 10:43:51 PDT, kevin graham writes: | | Does anyone know if there's a way to modify the scsi id of the tape | controller in a 760? It would be nice if our clustered 760's could share | a tape drive, or pair of drives, especially given how there's a whole | controller set aside for it.. I am interested in a related problem and I have found the following SCSI switches: http://www.digital-interact.co.uk/site/html/switches/switch_matrix.html http://www.peripheral-vision.com/switch.htm The Peripheral Visions switch looks particularly promising. /Michael

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