toasters

toasters@lists.teaparty.net

3 participants
13514 discussions

Start a nNew thread

(no subject)
by Alexandre Gomes (r7043c) 11 Aug '99

11 Aug '99

unsubscribe toaster

1 0

Power supply failure notifications
by Brian Tao 11 Aug '99

11 Aug '99

We had an F740 chassis power supply fail this morning (the second power supply was right there to keep things going of course, yay). The e-mail it sent out had a couple of oddities in it, but nothing really major: > ---------- Forwarded message ---------- > Date: Wed, 11 Aug 1999 12:39:59 -0400 > From: xxxxxxxxx(a)netcom.ca > To: xxxxxxxxx(a)netcom.ca > Subject: System Notification from pb ( Power Supply #1 Failed > > POWER_SUPPLY_DEG) > > GENERATED_ON=Wed Aug 11 12:39:59 EDT 1999 > VERSION=NetApp Release 5.1.2: Sat Sep 26 05:05:59 PDT 1998 [...] Is the subject line supposed to read "System Notification from pb ( Power Supply #1 Failed POWER_SUPPLY_DEG)" all on one line? It looks like that line was unintentionally split in two, so the "POWER_SUPPLY_DEG)" part appears in the message body. > Wed Aug 11 11:34:51 EDT [power_low_monitor]: Power Supply #1 Failed > Wed Aug 11 11:34:51 EDT [power_low_monitor]: Power supply is in degraded mode! > Wed Aug 11 11:34:51 EDT [asup_main]: System Notification mail sent > Wed Aug 11 11:34:51 EDT [asup_main]: System Notification mail sent > Wed Aug 11 12:35:31 EDT [power_low_monitor]: PS #1 Removed > Wed Aug 11 12:35:31 EDT [power_low_monitor]: Power supply is in degraded mode! > Wed Aug 11 12:35:31 EDT [asup_main]: System Notification mail sent > Wed Aug 11 12:35:31 EDT [asup_main]: System Notification mail sent > Wed Aug 11 12:36:14 EDT [power_low_monitor]: PS #1 Added > Wed Aug 11 12:36:15 EDT [power_low_monitor]: Power Supply #1 Failed > Wed Aug 11 12:36:15 EDT [power_low_monitor]: Power supply is in degraded mode! > Wed Aug 11 12:36:15 EDT [asup_main]: System Notification mail sent > Wed Aug 11 12:36:15 EDT [asup_main]: System Notification mail sent I swapped the failed power supply, but the filer syslogs a "Power Supply #1 Failed" message even when I insert/power up the replacement. According to the most recent syslog messages, the filer is still in degraded power mode. Can it log repair events as well as failure events, and is there a way (sysconfig?) to check the current power supply status? I had to go look at the filer LED's to make sure everything was indeed okay. Just to nitpick :) ... why does "System Notification mail sent" show up twice? Once for the e-mail and once for the short pager notification? Or is it because I have two addresses in autosupport.noteto?

2 1

Re: How does Netapps win and lose business? (cont.)
by Arvind K Aggarwal 11 Aug '99

11 Aug '99

Maybe our Auspex sales people don't know what is going on with CIFS. They have constantly pointed us to using SAMBA because of their inability to support CIFS. Overall Auspex is HIGHLY unreliable as compared to Network Appliances. At least that is OUR experience here. Arvind > To: toasters(a)mathworks.com > Subject: Re: How does Netapps win and lose business? (cont.) > Mime-Version: 1.0 > Date: Wed, 11 Aug 1999 07:39:30 +0200 > From: Michael Salmon <Michael.Salmon(a)uab.ericsson.se> > > +----- On Tue, 10 Aug 1999 12:24:31 CDT, Arvind K Aggarwal writes: > | > | > > One other thing that came to my mind is that Auspex does not support > | > > CIFS and HTTP. I believe they do FTP. I'm not interested in CIFS > | > > or HTTP myself as I use Filers with NFS exclusively, but I am glad > | > > that I have the option of turning on CIFS when my organization > | > > decides to use CIFS directly from storage appliances. You may say > | > > that the presence of the host processor on an Auspex enables one to > | > > do a variety of things like run Samba, but I assure you that Auspex > | > > is not optimized to perform any major file operations via its host > | > > processor. Also, if you think that you can rdist something quickly > | > > to an Auspex box you're in for a disappointment. Both NAC and > | > > Auspex are built with a small set of file services (NFS, etc.) in > | > > mind. If you don't go through these services in case of Auspex you > | > > suffer severe performance penalties. With NetApp this is not a > | > > problem as there is no way circumventing those services aside from > | > > their proprietary volume copy mechanism which is very robust itself. > | > > | > Tom, when was the last time you looked at an Auspex? > | > > | > CIFS is supported. (I also only use NFS :) > | > > | > | Really! Auspex was in our office (I work with Tom) last Friday and asked > | us to use SAMBA. > > Auspex has implemented AT&T's ASU, they call it NeTservices. As such it > is a couple of steps removed from M$ so you don't get the latest bugs. > There are some restrictions to using NeTservices with regards to OS > which I don't recall too well but I don't believe that any of our > machines qualified due to the hardware being too old. The 4front > machines do pretty well as CIFS servers. If Auspex had had the 4front > ready earlier then it would probably have tipped the scales from 49/51 > in Dell's favour to 51/49. > > /Michael

1 0

Re: How does Netapps win and lose business?
by sirbruce＠ix.netcom.com 11 Aug '99

11 Aug '99

On 08/10/99 17:46:04 you wrote: >So, in a conclusion, you can't bypass NFS, NetApps NFS servers are >performant, not expensive NFS/CIFS servers, but not very reliable. No >chance for 99% uptime. Despite your particular experiences, I believe that Netapp has a measured uptime far in excess of 99% over all of their customer base. You could ask them for the precise figures. Obviously some customers will fall below this level. A lot of components fail due to improper handling or shipping. Bruce

3 2

Re: How does Netapps win and lose business? (cont.)
by Michael Salmon 11 Aug '99

11 Aug '99

+----- On Tue, 10 Aug 1999 12:24:31 CDT, Arvind K Aggarwal writes: | | > > One other thing that came to my mind is that Auspex does not support | > > CIFS and HTTP. I believe they do FTP. I'm not interested in CIFS | > > or HTTP myself as I use Filers with NFS exclusively, but I am glad | > > that I have the option of turning on CIFS when my organization | > > decides to use CIFS directly from storage appliances. You may say | > > that the presence of the host processor on an Auspex enables one to | > > do a variety of things like run Samba, but I assure you that Auspex | > > is not optimized to perform any major file operations via its host | > > processor. Also, if you think that you can rdist something quickly | > > to an Auspex box you're in for a disappointment. Both NAC and | > > Auspex are built with a small set of file services (NFS, etc.) in | > > mind. If you don't go through these services in case of Auspex you | > > suffer severe performance penalties. With NetApp this is not a | > > problem as there is no way circumventing those services aside from | > > their proprietary volume copy mechanism which is very robust itself. | > | > Tom, when was the last time you looked at an Auspex? | > | > CIFS is supported. (I also only use NFS :) | > | | Really! Auspex was in our office (I work with Tom) last Friday and asked | us to use SAMBA. Auspex has implemented AT&T's ASU, they call it NeTservices. As such it is a couple of steps removed from M$ so you don't get the latest bugs. There are some restrictions to using NeTservices with regards to OS which I don't recall too well but I don't believe that any of our machines qualified due to the hardware being too old. The 4front machines do pretty well as CIFS servers. If Auspex had had the 4front ready earlier then it would probably have tipped the scales from 49/51 in Dell's favour to 51/49. /Michael

1 0

Re: How does Netapps win and lose business?
by sirbruce＠ix.netcom.com 10 Aug '99

10 Aug '99

On 08/10/99 15:01:55 you wrote: > > >On Tue, 10 Aug 1999, Stephen C. Losen wrote: > >> Actually, if you write N data blocks that correspond to the >> same parity block, you only do N+1 writes for the N blocks. > >That is certainly an optimization. In the most basic case you write one >block and update the parity block, which is two writes. One can also read >all the blocks that add up to the parity block and recheck, but I wonder >what that would do to performance. Given that Netapp's NVRAM allocates writes and then dumps them to disk periodically in stripes, this type of optimization would probably work well with them. Perhaps they do it already. :) Bruce

2 1

Re: How does Netapps win and lose business?
by alexei＠mindspring.net 10 Aug '99

10 Aug '99

Mike Horwath <drechsau(a)tiny.net> writes: > > > I ask because Auspex was just at my office touting their new NS2000 at > > > a price point that I haven't seen before. > > > > OK, here come the rants. > > Excellent, thanks! > For some interesting reading about the ns2000, check out deja.com and do a lookup (in past messages), specifically from Frank Durda. I found them interesting. Alex

1 0

Oracle performance on NetApp
by Itzik (Itzhak) Meirson DSc 10 Aug '99

10 Aug '99

One of our customers is looking into the possibility of using a toaster for the Oracle database. They expect a start point of about 100GB for the db with the potential growth to 1TB. I wonder if some one can share or point me to any performance numbers, success/disappointment stories when using a filer for Oracle database. Thanks, Itzik

1 0

RE: How does Netapps win and lose business? (cont.)
by Sam Schorr 10 Aug '99

10 Aug '99

This is not correct. Auspex does support NFS, CIFS and HTTP in the same manner as Netapps - in fact, instead of emulating the protocols, they are incorporated into the Auspex O/S. I have no idea if this is better or not. -----Original Message----- From: Arvind K Aggarwal [mailto:aggarwla@cig.mot.com] Sent: Tuesday, August 10, 1999 10:25 AM To: tkaczma(a)gryf.net; drechsau(a)tiny.net Cc: toasters(a)mathworks.com Subject: Re: How does Netapps win and lose business? (cont.) > > One other thing that came to my mind is that Auspex does not support > > CIFS and HTTP. I believe they do FTP. I'm not interested in CIFS > > or HTTP myself as I use Filers with NFS exclusively, but I am glad > > that I have the option of turning on CIFS when my organization > > decides to use CIFS directly from storage appliances. You may say > > that the presence of the host processor on an Auspex enables one to > > do a variety of things like run Samba, but I assure you that Auspex > > is not optimized to perform any major file operations via its host > > processor. Also, if you think that you can rdist something quickly > > to an Auspex box you're in for a disappointment. Both NAC and > > Auspex are built with a small set of file services (NFS, etc.) in > > mind. If you don't go through these services in case of Auspex you > > suffer severe performance penalties. With NetApp this is not a > > problem as there is no way circumventing those services aside from > > their proprietary volume copy mechanism which is very robust itself. > > Tom, when was the last time you looked at an Auspex? > > CIFS is supported. (I also only use NFS :) > Really! Auspex was in our office (I work with Tom) last Friday and asked us to use SAMBA. Arvind Aggarwal > -- > Mike Horwath Admin & Manager @ VISI.com WORK: drechsau(a)visi.com > IRC: Drechsau http://www.visi.com/ HOME: drechsau(a)geeks.org > The only Minnesota ISP with public statistics: http://noc.visi.com/ > Garbage In -- Gospel Out. - berkeley fortune(6)

2 1

Are we missing something? (was How does Netapps win and lose business?)
by Stephen C Woods 10 Aug '99

10 Aug '99

> > > > - Netapps are impossible to back up > > Not so. There are many ways to backup a filer. The fasted by far is > > direct attached SCSI though. If investing in large filers, one might > > consider the use of DLT for backups. Interestingly, there was brief discussion on toasters a few weeks ago about slow backups to a local SCSI tape, when the drive was made remote the backups went MUCH faster. It seems that the additional buffering provided by the network allowed the tape drive to stream better than when it was attached locally. > In a larger environment you probably don't want to backup each > fileserver separately with an attached DLT. And as NetApp doesn't > support a reasonable NDMP version which allows backup over the net the > only way to do a central backup is through NFS - not a very smart > solution. Hmmm, we've been using the native dump to a remote tape (DLT and 3590) using rmt protocol, we have found that we get good transfer rates (with 100Mbit and FDDI the drive streams nicely). We can restore the data using standard Unix restore (AIX and Solaris). In fact just to test our backups we routinely restore 2 Gig sections from dumps, we do other tests involving selecting a number of files at (pseudo)random and restoring them, then comparing them with the original data (first testing to see of the file has been modified since it was dumped). Clearly this is NOT backing up through NFS. We've been doing this for several years now, before we integrated it into our standard backup scheme (home grown, we backup filesystems from a wide range of unix systems) we had a set of scripts that were run by cron to back the filers up using knowledge of the sizes of the filesystems to ensure that any one piece would fit on a tape. Something to the effect of (our tapes are attached to stackers which load the next tape automaticly): rsh filer dump <level>ufbB <host>:<device> 32 35000000 filesys1 rsh filer dump <level>ufbB <host>:<device> 32 35000000 filesys2 rsh filer dump <level>ufbB <host>:<device> 32 35000000 filesys3 rsh filer dump <level>ufbB <host>:<device> 32 35000000 filesys4 rsh <host> mt -f <device> rewoffl; rsh filer dump <level>ufbB <host>:<device> 32 35000000 filesys5 rsh filer2 dump <level>ufbB <host>:<device> 32 35000000 filesys6 rsh filer2 dump <level>ufbB <host>:<device> 32 35000000 filesys7 rsh <host> mt -f <device> rewoffl rsh filer3 dump <level>ufbB <host>:<device> 32 35000000 filesys8 rsh <host> mt -f <device> rewoffl Clearly this produces reasonable backup volumes and is quite straight forward. If your filesystems are larger than will fit on a single tape, you have to be a little more creative (using expect to fake interaction), or run the backup interactively. ----- Stephen C. Woods; UCLA SEASnet; 2567 Boelter hall; LA CA 90095; (310)-825-8614 Finger for public key scw(a)cirrus.seas.ucla.edu,Internet mail:scw@SEAS.UCLA.EDU

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