toasters

toasters@lists.teaparty.net

13515 discussions

None
by pwalker2＠csc.com 28 Mar '00

28 Mar '00

Can anyone help with this problem I have. We have a F760 Ontap 5.3.2rd4. I have a Sun 5500 server that we NFS mount volumns on the Filer for Unix people. The complain I have heard is that copying large files from on directory to another on the filer takes to long. for example a 40-50meg file may take 3 or 4 minutes. I have never heard this complaint from the NT side. We have a person trying to install an oracle database and this problem was discovered. I have both Nics on the filer trunked and I have checked mosr everything netapps suggested. This filer does not have that much traffic on it and it seems to be doing alote of writes. The Nt people are using the 9gig drives and the UNIX voumns are 18gig drives. If you transfere these files out over the network it only takes a few seconds. Is there an answer to this problem, I have not been able to find one yet. pwalker2(a)csc.com

2 1

Re:
by Paul Wiltsey 28 Mar '00

28 Mar '00

decrease the rsize and wsize to less than 32k try 16k or 8192 ----- Original Message ----- From: pwalker2(a)csc.com Date: Tuesday, March 28, 2000 10:19 am > > > Can anyone help with this problem I have. We have a F760 Ontap > 5.3.2rd4. I have > a Sun 5500 server that we NFS mount volumns > on the Filer for Unix people. The complain I have heard is that > copying large > files from on directory to another on the filer takes to long. > for example a 40-50meg file may take 3 or 4 minutes. I have never > heard this > complaint from the NT side. We have a person trying to install an > oracledatabase and this problem was discovered. I have both Nics on > the filer trunked > and I have checked mosr everything > netapps suggested. This filer does not have that much traffic on it > and it seems > to be doing alote of writes. The Nt people are using the 9gig > drives and the > UNIX voumns are 18gig drives. If you transfere these files out over > the network > it only takes a few seconds. Is there an answer to this problem, I > have not been > able to find one yet. > > > pwalker2(a)csc.com > > >

1 0

RE: NIS and netgroup file
by Bond, Andrew 28 Mar '00

28 Mar '00

The filer does not copy the NIS maps into /etc. NIS group information is cached, but otherwise the filer acts as a NIS client only, and will query the NIS server it has bound to ("nis info" will tell you which this is). Regards, Andrew > -----Original Message----- > From: owner-dl-toasters(a)netapp.com > [mailto:owner-dl-toasters@netapp.com]On Behalf Of Timothy Demarest > Sent: 28 March 2000 09:32 > To: toasters(a)mathworks.com > Subject: NIS and netgroup file > > > Is there any magic in getting a Filer running 5.3.4R3 with NIS on > to do netgroup lookups via NIS? Or do you always have to manually > copy the netgroup file to filer:/etc? > > I've tried putting just "nis" in the nsswitch.conf file > for netgroup, but this didn't work. The nis_group file > is updated just fine, but this seems o be the only NIS > file that the Filer updates in /etc. > > Thanks. > > -- > Timothy Demarest ArrayComm, Inc. > demarest(a)arraycomm.com 2480 N. 1st Street, Suite 200 > http://www.arraycomm.com San Jose, CA 95131 >

3 2

NIS and netgroup file
by Timothy Demarest 28 Mar '00

28 Mar '00

Is there any magic in getting a Filer running 5.3.4R3 with NIS on to do netgroup lookups via NIS? Or do you always have to manually copy the netgroup file to filer:/etc? I've tried putting just "nis" in the nsswitch.conf file for netgroup, but this didn't work. The nis_group file is updated just fine, but this seems o be the only NIS file that the Filer updates in /etc. Thanks. -- Timothy Demarest ArrayComm, Inc. demarest(a)arraycomm.com 2480 N. 1st Street, Suite 200 http://www.arraycomm.com San Jose, CA 95131

1 0

Re: 3rd party NFS client
by Jen Hamilton 27 Mar '00

27 Mar '00

Did you have to install the hclnfsd or pcnfsd on the netapp? We get no HCLNFSD/PCNFSD running on host when we try to connect. Jen Hamilton On Mon, 27 Mar 2000, Fred Ab wrote: > We use Hummingbird's NFS Maestro on NT but have problems > with locking issues. All can be read just fine; however, many > locking issues for writing of course. I haven't looked into > the cause or resolution because I'm concerned with UNIX NFS > connections. > > If somebody has an idea for me to check and test I'm willing. > > > ===}Date: Mon, 27 Mar 2000 13:07:32 -0800 (PST) > ===}From: Jen Hamilton <jhamilto(a)n2h2.com> > ===}X-Sender: jhamilto(a)herald.bess.net > ===}To: toasters(a)mathworks.com > ===}Subject: 3rd party NFS client > ===}Mime-Version: 1.0 > ===} > ===} > ===}Has anyone used a third party NFS Client application on the NT side such > ===}as Hummingbird's NFS Maestro to connect to a NetApp instead of using > ===}CIFS? > ===} > ===} > ===}Jen H. > >

3 2

RE: 3rd party NFS client
by Benn, Paul 27 Mar '00

27 Mar '00

I've tried Microsoft's Services for UNIX (by Intergraph) in place of CIFS and it seemed to work fine. SFU Version 1.0 is an add on for NT 4 and SFU version 2.0 is included as a service with W2K server versions. For Intergraph's version, see: http://www.intergraph.com/nfs/ Here's a link to Microsoft's SFU: http://www.microsoft.com/NTServer/nts/exec/overview/sfu.asp -----Original Message----- From: Jen Hamilton [mailto:jhamilto@n2h2.com] Sent: Monday, March 27, 2000 1:08 PM To: toasters(a)mathworks.com Subject: 3rd party NFS client Has anyone used a third party NFS Client application on the NT side such as Hummingbird's NFS Maestro to connect to a NetApp instead of using CIFS? Jen H. pp instead of using ===}CIFS? ===} ===} ===}Jen H.

1 0

3rd party NFS client
by Jen Hamilton 27 Mar '00

27 Mar '00

Has anyone used a third party NFS Client application on the NT side such as Hummingbird's NFS Maestro to connect to a NetApp instead of using CIFS? Jen H.

1 0

Re: ndmpcopy problem (long)
by kevin＠interq.or.jp 27 Mar '00

27 Mar '00

This is not actually a good test. If you notice, the user has deleted the snapshot each time instead of using the same directory. The deletion of the directory is causing the filer to reset the directory information in the restore_symboltable. "restore_symboltable" keeps track of inode numbers and directory information. With the re-creation of the snapshot and a new directory in the snapshot, the user is causing the filer to want to perform a logical level0 even though he has specified an explicit level1. I don't think his test is relevant to our level1 problems because since we did not change the important parent directories, i.e., /o/w/1/2/owNNNN12/, the level1 would have only changed items that indeed did change using the same filesystem. For Deron, I would suggest repeating the test with a slightly different preparation of data. I think the NetApp is interpreting the entirely new snapshot, even though the filenames are the same, as a fresh set of data that should be restored over the destination data. Or do I have it wrong? On Mon, 27 Mar 2000, Peter Chow wrote: > might be relevant to our Level 1 NDMPcopy problems > > ---------- Forwarded message ---------- > Date: Sun, 26 Mar 2000 14:09:55 -0800 > From: Deron Johnson <djohnson(a)amgen.com> > To: toasters(a)mathworks.com > Subject: ndmpcopy problem (long) > > I had a need to transfer transfer a large amount of data between two > filers, one running OnTAP 5.3.4 and one running OnTAP 5.3.4R2. I ran a > level 0 ndmpcopy the day before the cutover, and then a level 1 the > night of the cutover, in order to minimize downtime. However, after > doing a compare of file sizes after the transfer, I found that some > files which had been modified since the level 0 did not have the proper > size on the destination. > > Here is an example. Toaster1 is the source, and toaster2 is the > destination. I have added some comments in UPPER CASE. > > -------- > # cd /toaster1/test > # ls -l > total 80 > -rw-r--r-- 1 root other 37817 Jan 31 15:54 testfile > SIZE OF ORIGINAL FILE IS 37817 BYTES. > > # rsh toaster1 snap create vol0 testndmp > creating snapshot.................................... > > # ndmpcopy toaster1:/vol/vol0/.snapshot/testndmp/test toaster2:/vol/vol0/test -level 0 > Password: > Connecting to toaster1. > Connecting to toaster2. > toaster1: CONNECT: Connection established. > toaster2: CONNECT: Connection established. > toaster1: LOG: DUMP: toaster1: LOG: Using subtree dump > toaster1: LOG: DUMP: toaster1: LOG: Date of this level 0 dump: Mon Jan 31 15:55:38 2000. > toaster1: LOG: DUMP: toaster1: LOG: Date of last level 0 dump: the epoch. > [NORMAL LOOKING DUMP/RESTORE OUTPUT] > toaster1: LOG: DUMP: toaster1: LOG: DUMP IS DONE > toaster1: HALT: The operation was successful! > Waiting for toaster2 to halt too. > toaster2: HALT: The operation was successful! > The transfer is complete. > Elapsed time: 0 hours, 0 minutes, 37 seconds. > > # rsh toaster1 snap delete testndmp > deleting snapshot.................................... > > # cd /toaster2/test > # ls -l > total 68928 > -rw-r--r-- 1 root other 37817 Jan 31 15:54 testfile > -rw-rw-rw- 1 root root 35213312 Jan 31 15:57 restore_symboltable > SIZE OF COPY IS 37817 BYTES, AS EXPECTED. > > # cd /toaster1/test > # vi testfile > # ls -l > total 80 > -rw-r--r-- 1 root other 37639 Jan 31 16:02 testfile > I HAVE MODIFIED THE FILE, SO IT IS NOW SHORTER (37639 BYTES). > > # rsh -n toaster1 snap create vol0 testndmp > creating snapshot.................................... > > # ndmpcopy toaster1:/vol/vol0/.snapshot/testndmp/test toaster2:/vol/vol0/test -level 1 > Password: > Connecting to toaster1. > Connecting to toaster2. > toaster1: CONNECT: Connection established. > toaster2: CONNECT: Connection established. > toaster1: LOG: DUMP: toaster1: LOG: Using subtree dump > toaster1: LOG: DUMP: toaster1: LOG: Date of this level 1 dump: Mon Jan 31 16:03:47 2000. > toaster1: LOG: DUMP: toaster1: LOG: Date of last level 0 dump: Mon Jan 31 15:55:38 2000. > [NORMAL LOOKING DUMP/RESTORE OUTPUT] > toaster1: LOG: DUMP: toaster1: LOG: DUMP IS DONE > toaster1: HALT: The operation was successful! > Waiting for toaster2 to halt too. > toaster2: HALT: The operation was successful! > The transfer is complete. > Elapsed time: 0 hours, 0 minutes, 38 seconds. > > # cd /toaster2/test > # ls -l > total 68928 > -rw-r--r-- 1 root other 37817 Jan 31 16:02 testfile > -rw-rw-rw- 1 root root 35213312 Jan 31 16:05 restore_symboltable > THE TIMESTAMP ON THE COPY HAS CHANGED, BUT IT IS STILL 37817 BYTES! > > # cd / > # umount /toaster2 > # mount toaster2:/vol/vol0 /toaster2 > # cd /toaster2/test > # ls -l > total 68928 > -rw-r--r-- 1 root other 37817 Jan 31 16:02 testfile > -rw-rw-rw- 1 root root 35213312 Jan 31 16:05 restore_symboltable > UNMOUNTED AND REMOUNTED TO MAKE SURE IT WASN'T A CACHING ISSUE. > -------- > > Can anyone tell me what I might have done wrong? >

1 0

(Fwd) (Fwd) Re: nas storage
by Percy Tzelnic 26 Mar '00

26 Mar '00

Dave: It seems to me that innuendo and insinuation, pointed at your competitors, is not quite worthy of an officer of a company proudly claiming the position of market leadership. As much as I am trying to justify your remark in a context of levity, the continuation of this thread (below) seems to have pushed to the point where it is embarrassing and demeaning. Yael Melman at EMC was not even aware of the existence of this mailing list. (Now she is, of course; BTW, the name Yael, two syllables, ya-'el, is originally a Hebrew name, always uni-gender.) Perhaps the actual Yael Hellmann would eventually come out and dispel the affiliation mystery... However, that's very much a moot point, even if, contrary to evidence, we assumed that Ms. Hellmann worked for EMC. The actual indictment by innuendo in this thread was that EMC was inimical to NAS, since, allegedly, EMC was exclusively a SAN company. This is simply untrue: EMC is the fastest growing vendor in the NAS market. Percy On 23 Mar 00, at 9:58, Dave Hitz wrote: <color><param>7F00,0000,0000</param>> ... <color><param>0000,0000,0000</param>> (Hey Yael! Are you the same Yael Hellmann who works at EMC?) <color><param>7F00,0000,0000</param>> > Dave > <color><param>0000,0000,0000</param>On 23 Mar 00, at 13:06, Keith Brown wrote: <color><param>7F00,0000,0000</param>> ... <color><param>0000,0000,0000</param>> We do need to clear up this last name thing though, because Yael <color><param>7F00,0000,0000</param>> would look more than a little silly if he'd got that wrong on his > Yahoo sign-up page . I mean... What next? A false beard? A blond > wig, evening gown and high heels? No... I'm sure this was just a > mistake, and probably yours Christian, right? We all make mistakes, > and you're usually so conscientious about getting your facts > straight here. > > So to show that there was clearly no malicious intent, is it > Melmann or Hellmann? Also, in order that we can all get some > perspective on any vested interests that might have been behind > young Yael's comments trashing network attached storage, perhaps > you could tell us what he does for EMC? That would be both helpful > and enlightening. <color><param>0000,0000,0000</param>> ... <color><param>0100,0100,0100</param>------- End of forwarded message ------- <nofill>

2 1

(Fwd) (Fwd) Re: nas storage
by Percy Tzelnic 26 Mar '00

26 Mar '00

1 0

test
by bar-lev benjamin 24 Mar '00

24 Mar '00

:-) __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com

1 0

Re: mini-core
by Jeff Krueger 24 Mar '00

24 Mar '00

From Chris Thompson on Fri, 24 Mar 2000 14:49:50 GMT: > >I remember asking about moving the "savecore" after the "nfs on" back >in the days of FASware 3.1.6 (or had they renamed it ONTAP by then?) We have been putting "savecore" after "nfs on" for quite a while now. It works as expected allowing client connections while the the core is being saved into the file system. Unfortuantely, CIFS doesn't come on until after the completion of all commands in "/etc/rc", so the only way to get it on first is to not have "savecore" in there at all and just run it manually. This doesn't seem like a good idea.. >and got a generally discouraging response, along the lines of "if >turning NFS on provokes another crash, you could be in trouble". Actually if you crash a second time before "savecore" has run, you merely can't dump the new core. In fact, it says something like "Dupming core... Can't dump, core already present on disk." IMHO, a problem that crashes your filer that quickly should be visible in the first core. If not, just boot off floppy and do a savecore. 99% of our NetApp crashes involve a sucessful core dump and reboot cycle. >Eventually I did make the change: the main problem turned out to be >that savecore thrashed the filing system so hard (this was on an >FAServer 450) that NFS hardly got a look-in, just at the time when >the clients were retrying all their outstanding requests. That could have been the fact that it was an FAServer 450. =) Our 300, 500, 600, and 700 series filers don't seem to have a problem handling NFS and "savecore" simultaneously. -- Jeff -- ---------------------------------------------------------------------------- Jeff Krueger E-Mail: jeff(a)qualcomm.com NetApp File Server Lead Phone: 858-651-6709 IT Engineering and Support Fax: 858-651-6627 QUALCOMM, Incorporated Web: www.qualcomm.com

1 0

RE: nas storage
by Adams_Christian＠emc.com 23 Mar '00

23 Mar '00

> (Hey Yael! Are you the same Yael Hellmann who works at EMC?) > > Dave [Adams, Christian] Hey Dave - Yael Melmann works for EMC. /Christian Adams EMC P.S. Nice re-telling of Auspex's "Myth of MIPS for I/O".

2 1

re: nas support
by Yael Hellmann 23 Mar '00

23 Mar '00

Regardless of a specific application and configuration, I am looking for an architecture that will support nas. Setting all components equal, comparing apples to apples, you end up with either going through a server for each operation or accessing a disk directly and an architecture that lets you access the disk directly must be faster. If you could have fast disk channels, getting information from that disk must be faster than getting the information through the server. It is not completely true for all applications. You still need the server for co-ordination and then it is a trade off. But I believe that each storage vendor will need this capability to be competitive. Some applications that would need this capability are publisher consumers messaging model, backup, source control. -----Original Message----- From: Josh McCormick [mailto:jmccorm@mail.wcg.net] Sent: Thursday, March 23, 2000 9:02 AM To: mkeller(a)mail.wcg.net Cc: toasters(a)mathworks.com Subject: Re: nas storage > Necessary to yell? > I use what I received. I am required to stick with it for a while yet. > You make a blanket statement without supporting facts. Here's what I'm wondering, Michael. When they are comparing the Netapp Filers to local storage, what exactly are they comparing? * Are they comparing 100mbit NFS delivery to a SCSI variant? * Are they comparing their raid and caching to a(n anonymous) local disk solution? JBOD or something else? * Are they comparing their NFS filesystem implementation to UFS and/or VxFS? Are the comparing the whole solution against something when it is claimed to be on par with local disks, and if so, what solutions are they comparing against? Of course, it would be a surprise is the Netapp Filers were on par with local storage in all cases. What I want to know is, what are the edge cases? What are the filers particually better at, and what are they particularly worse at? __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com

2 1

5.3.5
by Dave Atkin 23 Mar '00

23 Mar '00

1. We just started to run 5.3.5 on one of our 740s in order to test compatibility with Windows 2000. Is anyone else doing this successfully? 2. With 5.3.5 we are getting lots of messages on the console like: GMT [CIFSAdmin]: oplock break timed out to station CST209 for file \\NTCR2\w95apps\APPLICATIONS\SPSS\9\spssprod.inf We support some 1200 Windows 95 PCs, and at peak times we get several messages per minute for different files and PCs. Does anyone know what this means, should we care about it, and if not, can we turn them off! 3. Finally, I still don't think NetApp have quite got their early access releases sorted out properly. I looked at the NOW site and downloaded 5.3.5, but when I talked to a support engineer today he said "Why aren't you running 5.3.5P2?" Dave Atkin ------------------------------------------------------ Dave Atkin, Head of Technical Services Computing Service, University of York, YORK YO10 5DD Phone: +44-1904-433804 (ddi) Fax: +44-1904-433740 Email: D.Atkin(a)york.ac.uk ------------------------------------------------------

3 3

RE: mini-core
by Watanabe, Steve 23 Mar '00

23 Mar '00

> From: Jeff Krueger [mailto:jkrueger@qualcomm.com] > > >From "Watanabe, Steve" on Thu, 23 Mar 2000 06:05:13 PST: > > > >In a coming release compression of the core will be deferred > >if there is enough space available on the disk. In addition > > Cool. So in 5.3.5, does it check to see if an uncompressed dump is > possible, or does it compress regardless of available space? In 5.3.5 the core is always compressed. The "coming release" I refer to doesn't have a number yet. -steve > > >the core will be sprayed to multiple disks in parallel (it > >currently is written synchronously to one disk at a time). > > Sweet! That's what we like to hear! =) > > -- Jeff > >

1 0

RE: mini-core
by Watanabe, Steve 23 Mar '00

23 Mar '00

> From: Chris Thompson [mailto:cet1@cus.cam.ac.uk] > > Ethan Torretta <ejt(a)tellme.com> writes: > > "Michael J. Tuciarone" <tooch(a)netapp.com> wrote: > > > As filers have received more main memory, we began running out of > > > reserved disk areas before the whole core was dumped. The actual > > > ratio of memory to disk depends on memory size and disk model; > > > the larger the ratio the more likely you'll be unable to dump the > > > whole core. In response, we implemented the compressed > core feature. > > > Now if the filer computes there isn't enough disk space > to save the > > > entire core uncompressed, we compress the core before > writing it out. > > > > This makes me very interested in providing enough disks to allow > > uncompressed cores. However, looking at the documentation > I don't think > > that's going to happen. According to the SAG, each disks > provides only > > 20 MB of dump space, so for an F760 with 1024 MB of main > memory, fifty-two > > disks will be necessary for an uncompressed dump. Is this > correct? > > The chart still says only fourteen for "256 or more." I've > got fourteen > > on each filer; if twenty, say, would do it, I'd rearrange > filers so that > > the most sensitive ones had twenty, but fifty-two is out of > the question. > > The problem would seem to be that the 20 MB reserved area > hasn't altered > from the days of 2 GB, maybe 1 GB, discs, and so things have > got out of > proportion. > > How about using the space wasted by "right-sizing" for dumps? > Only if it > exists, of course, but in practice it will, and will be a lot > more than > 20 MB per disc! > As you said above, the 20MB reserved area is the same on all sized disks. However we do use the space that is left over after right-sizing. The size of the space varies with the capacity of the disk. In a coming release compression of the core will be deferred if there is enough space available on the disk. In addition the core will be sprayed to multiple disks in parallel (it currently is written synchronously to one disk at a time). This is for fibre channel disks only. -steve

2 1

RE: nas storage
by Cormier, Darleen 23 Mar '00

23 Mar '00

Gentlemen, I really must protest. Network Appliance plays very nicely in a SAN environment and is working very actively on solutions and with partners in that area. May I respectfully refer you all to www.netapp.com/news/press to the announcement dated 02/02/2000. Six leading Storage Vendors Introduce the first NAS & SAN Data Protection Solution for Network Attached Storage Solutions, and may I respectfully refer you to www.vixel.com/NAS_SAN_EVENT/NAS_html which has a variety of articles and white papers, discussing their relationship with Network Appliance and how they work with us in SAN enviroments, and may I repectfully refer you to www.spectralogic.com/NetApp which also explains their relationship to Network Appliance and our integrated SAN solutions, and may I respectfully refer you to www.legato.com/News/index.html which has articles explaining their relationship with Network Appliance and our combined SAN-based architecture and solutions, and may I respectfully refer you to www.snia.org which has a new NAS work group and is also working on developing SAN standards. I would also like to reassure those of you, who have expressed a concern that Network Appliance is not planning future competitive products, that you are mistaken. Network Appliance is continuing to develop products which will compete sucessfully in both NAS and SAN environments. -----Original Message----- From: Yael Hellmann [mailto:yael_hellmann@yahoo.com] Sent: Thursday, March 23, 2000 6:56 AM To: toasters(a)mathworks.com Subject: re: nas storage Jeff probably hit the point - NetApp do not have a solution for SAN and I think that NetApp should re-think their direction. With more and more vendors competing in the nas /san domain, these products will be better and provide more functionality and better performance. The current connectivity limitations will be eliminated. With fibre fabric you will not be limited to the current limited implementation. I think that NetApps products are great but I am disappointed that they don't plan for future competitive products. -----Original Message----- From: Jeff Van Cleave [mailto:jeffvc@icopyright.com] Sent: Wednesday, March 22, 2000 6:13 PM To: toasters(a)mathworks.com Subject: RE: nas storage NetApp is not designed to compete with SAN - and yes, you cannot say that 100mb ethernet will compete with fiber channel. However, direct attach has limitations in the number of servers it can connect to. At last check, EMC can connect with 32 systems. Hitachi can connect to a large number with a channel box (I don't know the high end limit). But you are limited by the length of cable between the SAN and the server. Basically we approached using NetApp as a replacement for all of our NFS servers, and to some extent our data servers. For direct attach, we will probably go with Hitachi. I think in any environment, both SAN and NetApp can be used effectively. It is not really an argument of which one is better, but what is your functional requirement and how will those needs be met. Jeff __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com

1 0

RE: nas storage
by Kirschner, Lewis 23 Mar '00

23 Mar '00

ABSOLUTELY NOT TRUE DESPITE WHAT THE GENTLEMAN SAYS BELOW!!!!!!!!!!!!!!!!!!! WE'VE GOT SEVERAL THOUSAND CUSTOMER WHO WILL TELL YOU OTHERWISE!!! -----Original Message----- From: Yael Hellmann [mailto:yael_hellmann@yahoo.com] Sent: Wednesday, March 22, 2000 2:59 PM To: michael.alvarado(a)netapp.com; toasters(a)mathworks.com Subject: RE: nas storage You are still limitted by the network and netapp will not be able to compete with products which provide direct disk attachment. Products in mind are SANergy and CXFS. Below is a message from a user who supports my assumtion that you cannot get local performance over a network link. "From: Michael S. Keller [mailto:mkeller@mail.wcg.net] Sent: Tuesday, March 21, 2000 10:56 AM To: toasters(a)mathworks.com Subject: Re: nas storage I do not get performance on par with my perception of local disk storage. Would you care to elaborate on what you mean by "on par with local disk storage"? When I run Usenet news spools from Solaris 2.6 on a NetApp filer, I must throttle NFS to get it to work reliably. " --- "Alvarado, Michael" <michael.alvarado(a)netapp.com> wrote: > Network Appliance's current customer experience is > that they do get performance > on par with local disk storage already. > > Our current plans do not include any interoperation > with the SANenergy products. > > -----Original Message----- > From: Yael Hellmann [mailto:yael_hellmann@yahoo.com] > Sent: Monday, March 20, 2000 6:02 PM > To: toasters(a)mathworks.com > Subject: nas storage > > > I am currently investigating the market for nas > storage. What is netapp plans in providing a > solution > which will deliver local disk performance for nas > storage? Does netapp have plans for products with > SANergy functionality or performance? > > __________________________________________________ > Do You Yahoo!? > Talk to your friends online with Yahoo! Messenger. > http://im.yahoo.com > __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com

6 7

RE: nas storage
by Yael Hellmann 23 Mar '00

23 Mar '00

You are still limitted by the network and netapp will not be able to compete with products which provide direct disk attachment. Products in mind are SANergy and CXFS. Below is a message from a user who supports my assumtion that you cannot get local performance over a network link. "From: Michael S. Keller [mailto:mkeller@mail.wcg.net] Sent: Tuesday, March 21, 2000 10:56 AM To: toasters(a)mathworks.com Subject: Re: nas storage I do not get performance on par with my perception of local disk storage. Would you care to elaborate on what you mean by "on par with local disk storage"? When I run Usenet news spools from Solaris 2.6 on a NetApp filer, I must throttle NFS to get it to work reliably. " --- "Alvarado, Michael" <michael.alvarado(a)netapp.com> wrote: > Network Appliance's current customer experience is > that they do get performance > on par with local disk storage already. > > Our current plans do not include any interoperation > with the SANenergy products. > > -----Original Message----- > From: Yael Hellmann [mailto:yael_hellmann@yahoo.com] > Sent: Monday, March 20, 2000 6:02 PM > To: toasters(a)mathworks.com > Subject: nas storage > > > I am currently investigating the market for nas > storage. What is netapp plans in providing a > solution > which will deliver local disk performance for nas > storage? Does netapp have plans for products with > SANergy functionality or performance? > > __________________________________________________ > Do You Yahoo!? > Talk to your friends online with Yahoo! Messenger. > http://im.yahoo.com > __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com

5 4

NOW website
by Jay Orr 23 Mar '00

23 Mar '00

Dunno if anyone had noticed, but as of the 11th they got rid of JavaScript. I just logged in with LYNX and it let me. Still gives lots of cookies, though. I'm going to check it out some more, but nice to see they finally took care of this. ----------- Jay Orr Systems Administrator Fujitsu Nexion Inc. St. Louis, MO

1 0

RE: Solaris 7 & NFS2/NFS3/TCP/UDP....
by Fox, Adam 23 Mar '00

23 Mar '00

> -----Original Message----- > From: Justin [mailto:Justin.Acklin@sv.sc.philips.com] > Sent: Wednesday, March 22, 2000 7:21 PM > To: toasters(a)mathworks.com > Subject: Re: Solaris 7 & NFS2/NFS3/TCP/UDP.... > > > I just looked at our main filer and realized we are using 8k NFS > packets. With almost exclusively > solaris 2.6 and 2.7 clients. I bet we would see a significant speed > increase if we upped it, particularly > with the large regressions being done on this Netapp. But, can I just > log in and change the value? > Will that affect existing mounts, and at what point would the new > blocksize take effect? > Or, can I only set it on reboot -- but even then the clients > would have > to remount > the filesystem right? Someone help me out on the proper way > to do this, > and let me > know if doing this causes harm in any way. Looking at nfsstat most of > our operations are indeed > nfs3. In my real-world experience, some sites do well with 32K transaction sizes, some do better with 8K. It depends on the typical amounts of retransmissions you have on your network. What people need to remember is that regardless of how big your transaction size is, if you are using Ethernet, you are bound to a 1500 byte packet size. So with a larger transaction size you are generating fewer NFS requests, but layers 2 and 3 still have to deal with the consequenses. Layer 3 has to break the requests into multiple IP packets, and layer 2 is responsible for holding those packets until the transaction is complete in the case of retransmission. Now let's add UDP to the mix. UDP doesn't have a concept of a packet count. Therefore, retransmissions are more expensive in a UDP environment because you have to start from the beginning. Now, with 8K transactions you're only talking about a small number of packets that would have to be retransmitted. What with 32K, you can have many more (in the range of 16-18 packets) and this can be expensive. So what's the bottom line? You may want to experiment with a client or two and see how these parameters affect your network. In some cases, 32K/UDP works great. In others, it's not so great. Use what works on your network. Hope this helps. -- Adam Fox NetApp Professional Services, NC adamfox(a)netapp.com

1 0

re: nas storage
by Yael Hellmann 23 Mar '00

23 Mar '00

Jeff probably hit the point - NetApp do not have a solution for SAN and I think that NetApp should re-think their direction. With more and more vendors competing in the nas /san domain, these products will be better and provide more functionality and better performance. The current connectivity limitations will be eliminated. With fibre fabric you will not be limited to the current limited implementation. I think that NetApps products are great but I am disappointed that they don't plan for future competitive products. -----Original Message----- From: Jeff Van Cleave [mailto:jeffvc@icopyright.com] Sent: Wednesday, March 22, 2000 6:13 PM To: toasters(a)mathworks.com Subject: RE: nas storage NetApp is not designed to compete with SAN - and yes, you cannot say that 100mb ethernet will compete with fiber channel. However, direct attach has limitations in the number of servers it can connect to. At last check, EMC can connect with 32 systems. Hitachi can connect to a large number with a channel box (I don't know the high end limit). But you are limited by the length of cable between the SAN and the server. Basically we approached using NetApp as a replacement for all of our NFS servers, and to some extent our data servers. For direct attach, we will probably go with Hitachi. I think in any environment, both SAN and NetApp can be used effectively. It is not really an argument of which one is better, but what is your functional requirement and how will those needs be met. Jeff __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com

4 3

RE: mini-core
by Klinkner, Steve 23 Mar '00

23 Mar '00

> From: Eyal Traitel [mailto:eyal.traitel@motorola.com] > Where/What/Who... :) > How do I enable it ? First time I've ever heard about it > being in 5.3 These were introduced in 5.3.4. It is a summary form of a full core. > "Graham C. Knight" wrote: > > Does anyone know if there is a way to > > have the mini-core files that are > > introduced in 5.3 mailed to a > > list *other* than my autosupport list > > - or to disable them being mailed at all? Currently these get delivered to the recipients on the "autosupport.to" list, and there isn't a way to tweak that. We plan to make this type of thing more configurable in the future. Do you like getting copies of all the other autosupports, but want to avoid having the mini cores delivered to your mailbox? Or would you also like more flexibility regarding whether and where they get delivered? ---------------------------------------------------------------------- steve klinkner klink(a)netapp.com

6 7

RE: VIF and Volume Questions
by Mohler, Jeff 23 Mar '00

23 Mar '00

There are no drawbacks at all, clients only see what you export, and you shouldnt be exporting /vol/vol0 by itself to your clients..but creating directories or qtrees inside there for your clients to play in. The volume-to-spindle contention issues dont apply on a Filer the way you probly see them in a UFS/NT environment. The only pro to separate..is you can use advanced tools/utilities like SnapRestore to backdate an entire volume, without affecting the boot volume. Adding shelves is trivial, and done properly doesnt even require a shutdown (RTFM before you even think 'bout it tho). And you can vol copy your boot to somewhere else, make it the boot volume, and go from there, but the only way to shrink a volume is to destroy it and rebuild it. Your VIF question..I dont follow. You have a single VIF using two ports. You dont need two hostnames for the two ports, because in a VIF they appear as one..same IP and hostname. You dont need to do anything with DNS, just forget they are two RJ45 connections..and see them as a 200Mbit single port. The VIF is at layer-2..and nothing above that needs adjusted to use it properly once the switch is configured. The main IP of the netapp..IS both ports acting as one assuming you only are using the VIF for connectivity. :-----Original Message----- :From: Timothy Demarest [mailto:demarest@arraycomm.com] :Sent: Wednesday, March 22, 2000 10:14 PM :To: toasters(a)mathworks.com :Subject: VIF and Volume Questions : : :Hello All: : :I have two questions: : :I am setting up a new F740. When I ordered the unit, I slightly :underestimated the number of disks required for our storage :requirements. Essentially, I forgot that the boot volume :requires two disks. What are the drawbacks to using the root/boot :volume for other data, such as home directories? I have enough :disks to create volumes & qtrees for other stuff, but am interested :in the pros/cons of NOT keeping the root/boot volume segragated :form other data. How do you have your volumes/qtrees setup? Is it :easy to add another shelf and disks later, and volcopy /vol/vol0 :to a new volume, then reduce the number of disks in the boot volume? : :Second, I have VIF working on a C5500. The first interface is named :f740-eng0, and the second f740-eng1. The VIF is named vifeng. What :should I be using in the DNS for the name of the F740? Do I create :a CNAME for the unit that points to the main IP for the F740? : :Thanks for your help. : :Tim : :-- :Timothy Demarest ArrayComm, Inc. :demarest@arraycomm.com 2480 N. 1st Street, Suite 200 :http://www.arraycomm.com San Jose, CA 95131 :

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