toasters

toasters@lists.teaparty.net

13520 discussions

Re: The Promise Of SAN ???.....EMC answer....
by sirbruce＠ix.netcom.com 13 Aug '99

13 Aug '99

>No company left the FibreAlliance. This was a mis-interpretation of >only one reporter. Note that no other press reported the same story. Whether or not the story is true, the "only one press reported it" line is hardly a defense. Remember Woodward and Bernstein? >Finally, I have seen lots of presentations by analysts about NAS and >SAN and what is stated below is really focused on the point they make >of where do NAS and SAN meet. If you need to have file sharing, then >use NAS but even the NAS server will need the benefits of SAN >(connectivity, distance, scaleability, etc). So the analysts position >NAS as using SAN on their backend. This was clearly the direction 2 years ago, and if it wasn't for SAN vendor fud more customers would realize this. >There are still, and will continue >to be, a large installed set of application that do not use NAS and >they will use SAN directly. There will continue to be a far larger installed set of applications that use only NAS and not SAN. In fact, very few applications use *only* SAN directly, because that would largely be useless; the data still has to get to the end-user to be useful, even if it's through a secondary application, and that user is very likely to be connected over a network. Bruce

1 0

Re: NFS lock tools
by sirbruce＠ix.netcom.com 13 Aug '99

13 Aug '99

On 08/13/99 00:55:17 you wrote: >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. I'd like to second the recommendation of lsof, which is essentially the second incarnation of the ofiles command. I did some work on it for Vic as an undergrad. As the the locking issue, I had always found simply restarting lockd and statd on the client were sufficient, without the procedure of locking another file in-between. But perhaps it depends on the client and the filer OS version. Bruce

1 0

The Promise Of SAN ???.....EMC answer....
by Savini, Patrice 13 Aug '99

13 Aug '99

Here is EMC answer...Regards, Patrice ------- Forwarded Message Follows ------- From: "blumenau, steven" <blumenau_steven(a)emc.com> To: "'tzelnic(a)emc.com'" <tzelnic(a)emc.com> Copies to: "ofer, erez" <erez(a)emc.com> Subject: RE: (Fwd) FW: The Promise Of SAN ???..... Date sent: Thu, 12 Aug 1999 12:24:17 -0400 Percy, No company left the FibreAlliance. This was a mis-interpretation of only one reporter. Note that no other press reported the same story. The FibreAlliance is focused on managing SANs. The OSFI is focused on working on interoperability of the protocol for switches. Specifically, how do two different vendors switches talk to each other over eports. All the work that the FibreAlliance does is submitted to standards bodies (ANSI, IETF, DMTF, etc). So there is no reason that they can be considered proprietary. For example, the MIB is currently a proposed draft in IETF and changes to the protocols have been submitted to ANSI. The quote below from Roger (Reich) was mis-quoted out of context. Roger even sent in a letter to unigram about this and it was published. As to all the groups working on standards, it turns out that we are all working together very well. The FibreAlliance is focused on SAN management at the lower levels of protocols, APIs and MIBs. It turns out the SNIA has adopted the MIB that we submitted to IETF and have proposed changes which have been incorporated into it. Finally, I have seen lots of presentations by analysts about NAS and SAN and what is stated below is really focused on the point they make of where do NAS and SAN meet. If you need to have file sharing, then use NAS but even the NAS server will need the benefits of SAN (connectivity, distance, scaleability, etc). So the analysts position NAS as using SAN on their backend. There are still, and will continue to be, a large installed set of application that do not use NAS and they will use SAN directly. Steve > -----Original Message----- > From: Percy Tzelnic [mailto:tzelnic@emc.com] > Sent: Thursday, August 12, 1999 10:06 AM > To: blumenau_steve(a)emc.com > Cc: erez(a)emc.com > Subject: (Fwd) FW: The Promise Of SAN ???..... > > > What's the answer? > Thanks, > Percy > > ------- Forwarded Message Follows ------- > From: "Savini, Patrice" <p-savini(a)ti.com> > To: "'Tzelnic'" <tzelnic(a)emc.com> > Subject: FW: The Promise Of SAN ???..... > Date sent: Thu, 12 Aug 1999 14:39:25 +0200 > > Any comment ? Patrice > > ************************************************************** > ********* > > 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 ****** 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. > > >

2 1

RE: NetGroup issue..last time
by Mohler, Jeff 13 Aug '99

13 Aug '99

Yep, many of you bent me in the right direction, actually a sudden vision of clarity about11 last night got me to the same place, but this AM's Email confirms. I _really_ must admit, that Toasters isnt line any other technical mailing list where "Duh, its in the manual" is the most common answer. Thanks! -----Original Message----- From: Stephen C Woods [mailto:scw@seas.ucla.edu] Sent: Thursday, August 12, 1999 6:03 PM To: steveb(a)sh-gpl.ti.com; jeff.mohler(a)wilcom.com Subject: Re: NetGroup issue..last time Steve, If by 'netaccess' you really ment root access you are correct. Granting root access requires a specific list of hosts. <scw> > From steveb > According to my docs. You can't give netgroups netaccess. Just specific hosts. > Although I am only running version 3.1. this may have changed in later versions. > According to Mohler, Jeff : > :-) > :-) 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. > :-) ----- 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

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

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