toasters

toasters@lists.teaparty.net

13531 discussions

Re: NFS lock tools
by dnb＠ccs.neu.edu 13 Aug '99

13 Aug '99

Thanks, this gets me a little closer. What you write below leads me to believe that I need to grovel around in statd source (or sniff the wire) to find our just what it is sending at this moment. "Keith Brown" <keith(a)netapp.com> writes: > 4. Restart statd. Statd will send a STATMON packet to the filer > that causes the filer to blow away all of the locks for that > client. Here's another quick tip for folks: Vic Abell, the author of the o-so-useful lsof program (which knows about locks in some cases), also has a program called lslk for listing existing locks. Both lsof and lslk can be found at <ftp://vic.cc.purdue.edu:/pub/tools/unix/>. I've communicated with Mr. Abell, and he does not know of any specific tool to do what we've been discussing. Peace, dNb

1 0

NFS lock tools
by dnb＠ccs.neu.edu 13 Aug '99

13 Aug '99

Howdy- I have a quick question which is marginally connected to NetApp-land. I was wondering if anyone had a tool for spoofing the RPC call(s) necessary to tell an NFS server to let go of a lock. Barring that, any pointers (besides OS source, which is my next stop) to documentation of the necessary dance would also be appreciated. I'd like to deal with the cases where a server thinks a file is locked, but the client has forgotten all about it (in a more graceful way than changing the file's inode by moving the data to another new file and then back again). I'm guessing the folks in NetApp engineering must have a lock make/break tool handy for their regression testing, hence my request here. I'd also be interested in knowing if there are any magic OnTap commands for showing all of the exisiting locks that the box is holding. Thanks! Respectfully, David N. Blank-Edelman Director of Technology College of Computer Science Northeastern University

2 1

NetGroup issue..last time
by Mohler, Jeff 12 Aug '99

12 Aug '99

Ok..sendmail ate my brain today, so a simple netgroup insertion..NO problem. My /etc/netgroup file on the filer: dgrmouse# more netgroup News-Feeders (news-feeder2-qfe1.wiltec.twc.com,,) (news-feeder2-qfe0.wiltec.t wc.com,,) (news-feeder-qfe0.wcg.net,,) (news-feeder-qfe1.wcg.net,,) News-Readers (news-reader-qfe0.wcg.net,,) (news-reader-qfe1.wcg.net,,) (news- reader3-qfe1.wcg.net,,) (news-reader3-qfe0.wcg.net,,) All hosts resolve, and are also entered in /etc/hosts on the filer. My attempted export: /vol/NetMaint -access=News-Feeders,root=News-Feeders Output: ratbert> exportfs -a export: Can't find address for host News-Feeders ? Everything Ive looked at, "feels" ok, looks OK, but the filer dont think it's ok. Netgroup is told to look in 'files' initially in Name Services/DNS as well.

3 3

How does Netapps win and lose business?
by Jeffrey Skelton 12 Aug '99

12 Aug '99

I'm interested in hearing any stories on how Netapps wins or loses your business. I'm currently shopping for storage and a Netapps filer seems to fit the bill. I've talked to other storage system vendors -- that big one, EMC (or is it Data General), MTI, and some others. They all emphasize that: - SAN is the future of storage - Netapps and NFS is a lock in to old technology - Netapps is JBOD - that Eurologic is an unknown scrap vendor - Netapps are impossible to back up - RAID 4 is unreliable - WAFL is slow - WAFL is impossible to recover when it becomes corrupt - wack takes all day to report that you're still in trouble - the cluster failover takes too long - the cluster failover is unreliable at best - the Netapps performance is terribly slow - the software is big pile of patches that are impossible to keep track of They've also given me references of companies that have switched from Netapps to other solutions. In general three themes came from the references: - they lost data with Netapps. Why? Because they could not take a backup with their enterprise backup software and then they suffered a multiple disk failure from a set of disks with problem firmware. I've seen a lot of griping on this least lately about backups. How much of a problem is the backup situation and does the situation become a problem when it requires a patch for the Netapps software that may introduce other instabilities? - the Netapps filer was too slow for database use. I could understand how some of the storage arrays directly attached to a server could be faster. This isn't my application space, so I'm not outright concerned with it. But, I have seen some of the recent messages on performance and throughput. How would you rate the Netapps for performance for things like home directory storage? - the clustering did not work. Paid for cluster and the failover did not work as advertised. This concerns me, because I am willing to pay the extra money for a cluster. As long as I'm shelling out, should I go to EMC for reliability or hope that the Netapps failover can work? I can get more Netapps for the money. I'm not dumb enough to believe all of the claims that sales droids make. But, I'd like to hear some opinions as to what makes you buy Netapps, what keeps you on Netapps, and what will drive you away from Netapps. --jeff skelton

12 25

To 5.2.3 or 5.3.2?
by Chuck Hilyard 12 Aug '99

12 Aug '99

I'm faced with an upgrade to my F520. 5.2.3 is a recommended release. 5.3.2 is early access, but has been around for a while now. 5.3.2 has features that I want, such as UID to SID mapping. Are there any reasons why I should or shouldn't go to 5.3.2? Thanks in advance, -- Chuck Hilyard (chuck.hilyard(a)engineering-e.com)

1 0

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

12 Aug '99

+----- On Wed, 11 Aug 1999 07:48:28 CDT, Arvind K Aggarwal writes: | 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. I've worked with Auspices for over 5 years now and some of the machines that we have here are even older than that. My toaster experience is much less, about 18 months. I find that Auspices are extremely reliable if you leave them alone, part of that is due to some of the OS releases that come out of Auspex, particularly the odd releases for some unknown reason. We have only rarely had any hardware problems with them and I don't recall that we ever had a big outage as a result. We haven't had many OS problems with our toasters with the exception that they seem just out of the ark in some respects (e.g. ntp). There have been some hardware problems though, one particular example was a faulty qfe card, the system refused to boot and gave a cryptic error message that neither I and our netapp representative understood. The qfe card turned out to be the only one that wasn't on site but even without that the down time was too long. I feel that netapp feels that they don't have too worry about rebooting because they do it so well, Auspex takes a lot longer so they have to be more careful. Taking everything into account, I feel happier with Auspex than we netapp. As a sysadmin I feel even better with having Sun's but I can't satisfy all of our requirements that way. We bought Dell toasters because they satisfied our user's perceived needs and have to accept that it'll take more work on our part to keep things working. /Michael

2 1

RE: [Fwd: The Promise Of SAN ???.....]
by Savini, Patrice 12 Aug '99

12 Aug '99

I will verify information with EMC. Regards, Patrice -----Original Message----- From: G D Geen [mailto:geen@msp.sc.ti.com] Sent: Thursday, August 12, 1999 3:06 PM To: Toasters Maillist; storage(a)list.ti.com - Share information on Storage config and prices Subject: [Fwd: The Promise Of SAN ???.....] Hi, I just received this message from Auspex and thought that I would share it. I do not make any claims to the validity of the message. I only pass it along so that it may be verified. The writer does not quote the source, thus I am at first sceptical. Comments and suggestions on ways to verify are, of course, welcomed. -gdg -------- Original Message -------- Just had to put this out as food for thought. As Auspex begins building SAN gateways we are even more confident the analysts are correct about the convergence of NAS/SAN. Hope you enjoy. Kevin Kirksey Auspex Systems EMC's Fibre Alliance Woes and the state of SAN Interoperability On 7/23 Jo Maitland announced in UNIGRAM, that more than half of the Fibre Channel switch manufacturers (McData, Brocade, Ancor, Gadzoox and Vixel) defected from EMC's Fibre Alliance, "fed-up with its slow pace on standardization". These 5 vendors have created their own, independent group, (the Open Standards Fabric Initiative - OSFI) charged with settings standards of interoperability between their own products and between their products and third party products. Key points: 1. Standards exist for interoperability between switches, and third party products, but each vendor was using their own interpretation of those standards. This led to a lack of interoperability between different manufacturers switch products and the need for customers to purchase proprietary SAN solutions - something they are not interested in doing. This also led to lack of plug-and-play interoperability between switches and third party products (such as the HBAs needed in servers to connect to the SAN) - in turn forcing vendors of SANs to go through exhaustive interoperability testing every time a new product revision was released or a new product line was added to their suite of SAN products. 2. EMC set up the Fibre Alliance in February with great fanfare, splitting off from the SNIA to develop interoperability between components. Notably absent from the group were any other storage vendors such as IBM or Hitachi. As a result it was seen by many in the industry as a way for EMC to force it's own standards on the rest of the Fibre and SAN community. An effort that has obviously failed - at least for now. 3. Despite the fact that the OSFI has stated that it is a subgroup within the FibreAlliance, EMC has stated that they will monitor the group to see if their work conflicts with what the Fibre Alliance is doing - in other words EMC will do what they're doing, without input or feedback from the OSFI, leading yet again to dual (and dueling!) standards. An indication of this is contained with the report: "One analyst on the call said that working on device level interoperability is fine but without an overall framework for managing those devices, the storage area network is still way off. A spokesperson for McData, a member of OSFI said, "We have to crawl before we can walk." " 4. A third group working on standards is the SNIA (Storage Network Industry Association) with over 100 members. A quote from the SNIA and from a member of the OSFI sums up the situation with multiple standards committees working on the same issues but in opposite directions. SNIA chairman, Roger Reich, director of Compaq's network storage division said of the new group: "I don't know where they are going or what they are doing, but if they need backing in the form of money or talent we would be happy to speak to them." He added that the Fibre Alliance was a closed, profit-making group with a different agenda to the SNIA. In response to Reich, Greg Reyes, CEO of Brocade and a member of the OSFI said: "We are not interested in his offer." Summary 1. Despite their protestations to the contrary, EMC is proprietary, will continue to be proprietary and does not wish to work on a global scale with other vendors to open up interoperability of servers, storage devices and interconnect products such as switches, hubs and HBAs. Customer purchasing EMC storage devices or SAN implementations will be locking themselves into the high price leader and into a proprietary solution. 2. This lends further credence to Auspex stated vision (backed up by analysts) of NAS as the "Intelligent Gateway" to the SAN, and that NAS should be implemented today with an eye toward tomorrows SAN implementation (i.e. SAN should not be implemented today). Install SAN today at your own risk, if for no other reason than a lack of standards and a lack of a current methodology of moving toward a single set of globally accepted standards.

1 0

[Fwd: The Promise Of SAN ???.....]
by G D Geen 12 Aug '99

12 Aug '99

Hi, I just received this message from Auspex and thought that I would share it. I do not make any claims to the validity of the message. I only pass it along so that it may be verified. The writer does not quote the source, thus I am at first sceptical. Comments and suggestions on ways to verify are, of course, welcomed. -gdg -------- Original Message -------- Just had to put this out as food for thought. As Auspex begins building SAN gateways we are even more confident the analysts are correct about the convergence of NAS/SAN. Hope you enjoy. Kevin Kirksey Auspex Systems EMC's Fibre Alliance Woes and the state of SAN Interoperability On 7/23 Jo Maitland announced in UNIGRAM, that more than half of the Fibre Channel switch manufacturers (McData, Brocade, Ancor, Gadzoox and Vixel) defected from EMC's Fibre Alliance, "fed-up with its slow pace on standardization". These 5 vendors have created their own, independent group, (the Open Standards Fabric Initiative - OSFI) charged with settings standards of interoperability between their own products and between their products and third party products. Key points: 1. Standards exist for interoperability between switches, and third party products, but each vendor was using their own interpretation of those standards. This led to a lack of interoperability between different manufacturers switch products and the need for customers to purchase proprietary SAN solutions - something they are not interested in doing. This also led to lack of plug-and-play interoperability between switches and third party products (such as the HBAs needed in servers to connect to the SAN) - in turn forcing vendors of SANs to go through exhaustive interoperability testing every time a new product revision was released or a new product line was added to their suite of SAN products. 2. EMC set up the Fibre Alliance in February with great fanfare, splitting off from the SNIA to develop interoperability between components. Notably absent from the group were any other storage vendors such as IBM or Hitachi. As a result it was seen by many in the industry as a way for EMC to force it's own standards on the rest of the Fibre and SAN community. An effort that has obviously failed - at least for now. 3. Despite the fact that the OSFI has stated that it is a subgroup within the FibreAlliance, EMC has stated that they will monitor the group to see if their work conflicts with what the Fibre Alliance is doing - in other words EMC will do what they're doing, without input or feedback from the OSFI, leading yet again to dual (and dueling!) standards. An indication of this is contained with the report: "One analyst on the call said that working on device level interoperability is fine but without an overall framework for managing those devices, the storage area network is still way off. A spokesperson for McData, a member of OSFI said, "We have to crawl before we can walk." " 4. A third group working on standards is the SNIA (Storage Network Industry Association) with over 100 members. A quote from the SNIA and from a member of the OSFI sums up the situation with multiple standards committees working on the same issues but in opposite directions. SNIA chairman, Roger Reich, director of Compaq's network storage division said of the new group: "I don't know where they are going or what they are doing, but if they need backing in the form of money or talent we would be happy to speak to them." He added that the Fibre Alliance was a closed, profit-making group with a different agenda to the SNIA. In response to Reich, Greg Reyes, CEO of Brocade and a member of the OSFI said: "We are not interested in his offer." Summary 1. Despite their protestations to the contrary, EMC is proprietary, will continue to be proprietary and does not wish to work on a global scale with other vendors to open up interoperability of servers, storage devices and interconnect products such as switches, hubs and HBAs. Customer purchasing EMC storage devices or SAN implementations will be locking themselves into the high price leader and into a proprietary solution. 2. This lends further credence to Auspex stated vision (backed up by analysts) of NAS as the "Intelligent Gateway" to the SAN, and that NAS should be implemented today with an eye toward tomorrows SAN implementation (i.e. SAN should not be implemented today). Install SAN today at your own risk, if for no other reason than a lack of standards and a lack of a current methodology of moving toward a single set of globally accepted standards.

1 0

RE: backing up a filer w/Legato Networker
by Chambers, Carolyn 12 Aug '99

12 Aug '99

The NDMP version is in external test now. I think it's very flexible in that you can setup any number of Networker Storage Nodes and use them as backup servers. The plan is to have each NSN SCSI connected into a tape library. Then point them, through a logically or physically separate LAN, to filers for backup over the network. With a backup network and snapshots, your backup window should now be 7x24. Carolyn -----Original Message----- From: Geir Odden [mailto:etogod@ericsson.no] Sent: Thursday, August 12, 1999 3:02 AM To: toasters(a)mathworks.com Subject: Re: backing up a filer w/Legato Networker Michael Salmon wrote: > | I've perused the archives here, and checked out the netapp and legato > | websites, and have come up with no hard information about the > | availability of a networker client for my netapp. > > AFAIK networker cannot backup netapp filers, the functionality was > promised for february but by all accounts it appears to have > disappeared into the black hole at Legato. The only way that I know of > backing a filer is via NFS or CIFS and I presume that is what you have > done, you need to look carefully at your client specification to see > exactly what you are backing up. I found this at the Legato web. Our incorporation of an NDMP II compliant backup solution will occur in NetWorker release 6.0, due in Dec, 1999. This should better facilitate NetApp integration within a backup and restore strategy. Geir Odden

1 0

Re: backing up a filer w/Legato Networker
by Michael Salmon 12 Aug '99

12 Aug '99

+----- On Wed, 11 Aug 1999 19:07:33 EDT, "Marc C. Poulin" writes: | We have an f740 providing nfs to a bunch of sun boxes hard-mounted to it | over a private network. We have been *aparrently* backing up the | filer via Legato Networker to a DLT jukebox (i.e. the networker logs | claim to have backed things up). While perusing dejanews recently, I | noted some comments about Networker not backing up filers properly. | Sure enough, after several vain attempts to restore some files, | Networker complains that I am trying to restore files for a client | that is not registered. | | I've perused the archives here, and checked out the netapp and legato | websites, and have come up with no hard information about the | availability of a networker client for my netapp. AFAIK networker cannot backup netapp filers, the functionality was promised for february but by all accounts it appears to have disappeared into the black hole at Legato. The only way that I know of backing a filer is via NFS or CIFS and I presume that is what you have done, you need to look carefully at your client specification to see exactly what you are backing up. /Michael

2 1

backing up a filer w/Legato Networker
by Marc C. Poulin 11 Aug '99

11 Aug '99

We have an f740 providing nfs to a bunch of sun boxes hard-mounted to it over a private network. We have been *aparrently* backing up the filer via Legato Networker to a DLT jukebox (i.e. the networker logs claim to have backed things up). While perusing dejanews recently, I noted some comments about Networker not backing up filers properly. Sure enough, after several vain attempts to restore some files, Networker complains that I am trying to restore files for a client that is not registered. I've perused the archives here, and checked out the netapp and legato websites, and have come up with no hard information about the availability of a networker client for my netapp. Does anyone out there have any suggestions or ideas? Thanks, Marc Poulin

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 18:25:05 you wrote: > > >On Tue, 10 Aug 1999 sirbruce(a)ix.netcom.com wrote: > >> 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. :) > >I'm sure they do it. Does NetApp's NVRAM allocate writes? I though >NetApp held raw NFS packets in the NVRAM. Yes. I was sorta speaking in shorthand. My understanding is that the raw NFS packets get storied both in NVRAM and main memory; the point is once the NVRAM is half-full, or at 10 seconds, outstanding write data is collected and sent to disk, and the NVRAM flushed. There's some amount of allocation involved here and I think some parity stuff that actually gets stored in NVRAM as well; I didn't mean to imply, however, that actual SCSI commands or disk blocks are being stored there. My knowledge of exactly what happens in detail ends here, so I'll let someone else explain more thoroughly if you're really curious. Bruce

2 1

(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

(no subject)
by Tim McDonough 10 Aug '99

10 Aug '99

subscribe toasters

1 0

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

10 Aug '99

> > 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)

1 0

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

10 Aug '99

Jeffrey Skelton <jss(a)NET2PHONE.COM> writes: > - SAN is the future of storage Yes, but we are in the dark ages right now. Not all vendors support switched fibre channel, a must for any SAN to work as advertised. The lack of multiple vendors for fibre channel switches also makes for a hard sell right now. Some vendors are further ahead than others in this front. Compaq seems to have a nice, cohesive product. Their new HS{G,Z}80 raid array is slick. > - Netapps and NFS is a lock in to old technology Electricity is a lock in to an old technology. NFS and SMB(CIFS) are the way to share data on a network. Do you think all your clients will be part of the SAN? No way. The SAN is a method for large systems to have shared access to devices. NOTE: this does not mean shared access to the *data*. You need more smarts than SAN for that. Something like clustering would get it... The fact is that even when you have a SAN deployed, you will still need a common access method for the clients to hit the data. NFS/HTTP/CIFS or whatever your protocol du jour is. > - Netapps is JBOD Not quite. JBOD is a simplification. WAFL rocks and is what really lets the filers shine. > - that Eurologic is an unknown scrap vendor Vendor FUD. > - Netapps are impossible to back up Not really: vol copy works well. Sure, you cannot run Legato on the filer, so it makes backups more challenging, but NDMP is supposed to help. The JVM in the filer might prove to be useful in this area. > - RAID 4 is unreliable As compared with? Sure, it is not the same as hardware RAID 1+0, but it is also 1/2 the price (as far as number of disks required, etc). > - WAFL is slow Compared with? No way. UFS is a dog. AdvFS is a black box. Veritas is Sun only. XFS is not ported to other platforms (yet). WAFL is the way to get performance on these boxes. The white paper should shed some light on this. Seriously: the main drawback to any competing solution is the file system. Show me something else that has the ability to do snapshots, grow the filesystem on the fly, increase the ammount of files on the fly, do well with large directories and still be able to pump data out quickly. > - WAFL is impossible to recover when it becomes corrupt Given sufficient corruption, any filesystem is unrecoverable. I have seen some seriously bad situations and come out ok. > - wack takes all day to report that you're still in trouble Tough one. THis is true sometimes. If you do not run the right incantation of wack (version, etc), you could be faced with never-ending wacks. This is a pain. > - the cluster failover takes too long What do you call too long? > - the cluster failover is unreliable at best I cannot address this, as I have not used it in production. > - the Netapps performance is terribly slow Again, compared to what? Check the SPEC SFS numbers (what used to be LADDIS) at http://www.spec.org/ and see what the vendor numbers are. Sure, the f760 solution falls short of the 49k NFSops that an EMC Celera does, but it is also a small fraction of the price. Yes, you can hit a performance wall with the filers. My face has a brick wall imprint on it :( > - the software is big pile of patches that are impossible to keep > track of No. But NetApp could do better at alerting customers of bugs (especially evil bugs). If you do autosupport, the NetApp folks should be able to do some analysis of the data and make reccomendations (based on firmware revs, OS version, etc). > They've also given me references of companies that have > switched from Netapps to other solutions. I am sure there are plenty of companies that have done this. But this is more vendor FUD. The NetApp filers are great tools, but they are not a one-size-fits-all solution. Different needs call for different solutions, so sometimes people outgrow the filers (or the filers were never the right solution for the person to begin with). > - they lost data with Netapps. Why? Because they could not take > a backup with their enterprise backup software and then they > suffered a multiple disk failure from a set of disks with > problem firmware. This is more a problem of laziness. In my previous job, we backed up our filers with Alexandria. It worked well. It was not as fast as doing a raw dump to tape, but it worked. > - the Netapps filer was too slow for database use. I could Perhaps. > and throughput. How would you rate the Netapps for performance > for things like home directory storage? They would excel at this. The filers do very well in a high read to low write ratio environment. > - the clustering did not work. Paid for cluster and the failover > did not work as advertised. Some folks have misconceptions about what the cluster failover does. I think this is mainly NetApp's fault for not really being clear about what the product does (or setting proper expectations). Important details of the filer operation are buried in different locations. Clustering is not a simple thing to deploy. It may appear trivial, but it adds a layer of complexity which may not make all people comfortable. You need to make sure that the added reliability is worth the cost (not just money). > I'm not dumb enough to believe all of the claims that sales droids > make. But, I'd like to hear some opinions as to what makes you > buy Netapps, what keeps you on Netapps, and what will drive you > away from Netapps. I have used filers for close to 5 years now. The core competency of the company is the WAFL file system and the NFS code. These boxes are good at delivering data. Alex

1 0

Jump to page:

2026

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