toasters

toasters@lists.teaparty.net

13520 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

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