toasters

toasters@lists.teaparty.net

3 participants
13514 discussions

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

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