toasters

toasters@lists.teaparty.net

13531 discussions

RE: benchmark
by Dani Tal 30 Mar '00

30 Mar '00

I think the original quotation is : There are two reasons why standards are wonderful: a. There are so many of them b. You can choose. Dani Tal -----Original Message----- From: Mitch Wright [mailto:mitch@larionov.netline.com] Sent: Thu, March 30, 2000 3:23 AM To: toasters(a)mathworks.com Subject: Re: benchmark /* Karl Swartz [kls(a)netapp.com] writes: */ >Aren't standards wonderful? :-) > I wish I could remember whom to attribute this quote to, but it goes: The wonderful thing about standards is that there are so many of them to choose from. -- do svidaniya, ~mitch

1 0

RE: add/remove users from NT4 domains [from unix]?
by Muhlestein, Mark 30 Mar '00

30 Mar '00

Check out "rpcclient" in the Samba stuff. Especially in the TNG branch. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: James N. Maze [mailto:mazejn@ornl.gov] Sent: Wednesday, March 29, 2000 8:38 PM To: toasters(a)mathworks.com Subject: add/remove users from NT4 domains [from unix]? Does anyone know of a library or set of utilities for Unix [commercial/free] that lets you add/remove users from NT4 global groups? Such would allow me to move a Web application from a NT Web server to my Unix/Apache/NetApp Web server. Thanks!

1 0

RE: Permissions
by Muhlestein, Mark 29 Mar '00

29 Mar '00

What version are you running? You may be hitting the issue described in bug 21019. If so, you need to get a version that supports the cifs.perm_check_ro_del_ok option (probably 5.3.4R3P2 or 5.3.5P2). The issue here is that some customers consider it a bug to allow a read-only file to be deleted, since that violates NT delete semantics, while others (like yourself) consider it to be a bug not to obey UNIX delete semantics (i.e. you just need w-x in the parent). The option was introduced to allow this behavior to be customized. Mark -----Original Message----- From: Jeff Stampes [mailto:Jeff.Stampes@xilinx.com] Sent: Wednesday, March 29, 2000 1:27 PM To: toasters(a)mathworks.com Subject: Permissions Situation: touch a file from a UNIX box chmod 444 file from UNIX box rm -f file from NT box over CIFS share Result: Permission Denied..Booooooo touch a file from a NT box chmod 444 file from UNIX box rm -f file from NT box over CIFS share Result: file is quietly removed...Yeeeeeah! The former behavior is undesirable, as we have multiple platforms in our compile releasing the same platform independent files at different times. Any suggestions? -Jeff

1 0

RE: NIS and netgroup file
by Nagaraj, Devi 29 Mar '00

29 Mar '00

We are looking into ways of improving the NIS implementation to be more efficient. We are not planning on implementing the slave functionality on the filer though. We are currently focussing on better response to netgroup queries. -Devi Netapp Engineering. -----Original Message----- From: Bruce Sterling Woodcock [mailto:sirbruce@ix.netcom.com] Sent: Tuesday, March 28, 2000 1:34 AM To: Bond, Andrew; Timothy Demarest Cc: toasters(a)mathworks.com Subject: Re: NIS and netgroup file > 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). Is full server (non-master) functionality going to be included in the future? It would be very useful and would allow the filer to be more robust. Bruce

7 8

Fwd: Re: NIS and netgroup file
by Jeff Innis 29 Mar '00

29 Mar '00

Sure why not add NIS server, why stop there though lets add DNS too. Hey these things are so reliable, let's put a full blown kernel in there, and start running user apps as well. Anyone ever hear of a little box called Auspex??? I actually thought the concept of "dedicated" NFS appliance was a good one. Jeff > > > We are looking into ways of improving the NIS implementation to be more > > efficient. We are not planning on implementing the slave functionality >on > > the filer though. > >That's too bad, because it essentially makes a network less robust. >See, if you rely on NIS files so you don't have to copy files to the >filer locally, then lets say you have a power outage. The filer comes >up and then can't do anything because it's waiting to talk to the NIS >server (it's probably the DNS server too). The NIS server can't do >anything because it's waiting to mount the filer. Stalemate. There are >ways around this, like having your NIS/DNS server hold the data on a >local disk, but then you have a kink in your whole centralized network >storage scheme. Altenatively, you can copy everything to the filer, but >then you've defeated the whole purpose of NIS. > >Making filers slave servers is an ideal solution. You don't have to >allow other clients to bind to them, but this way they can get data >updated from a master and still have a local copy in the event of >network problems. > >Bruce > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Permissions
by Jeff Stampes 29 Mar '00

29 Mar '00

Situation: touch a file from a UNIX box chmod 444 file from UNIX box rm -f file from NT box over CIFS share Result: Permission Denied..Booooooo touch a file from a NT box chmod 444 file from UNIX box rm -f file from NT box over CIFS share Result: file is quietly removed...Yeeeeeah! The former behavior is undesirable, as we have multiple platforms in our compile releasing the same platform independent files at different times. Any suggestions? -Jeff

1 0

HP-UX R11 L2000 / F740 NFS Performance
by Dave Mills 29 Mar '00

29 Mar '00

Has anyone tried maximizing file loading performance in the above environment. I will be installing the F740 with 18 - 36GB drives soon and want to solve the problem before it exists. We will be loading aobut 200GB on each of 2 consecutive weekends. Subsequent daily processing will be very heavy batch sequential. Any comments appreciated. Dave Mills Cypress Systems, LTD

1 0

Re: Server capacity and performance
by Brian Hostetter 29 Mar '00

29 Mar '00

2-3K usually. The total number of OPS has not increased very much, it seems like writes are taking forever. I was thinking it may have soemthing to do with WAFL looking for the next open block and when the filer is pretty full it is hard to find. --Bian >>> Mike Horwath <drechsau(a)tiny.net> 03/29 9:32 AM >>> On Wed, Mar 29, 2000 at 08:46:14AM -0600, Brian Hostetter wrote: > Could my performance problems be related to space, or are they > probably just sheer volume of ops problems. What are the numbers for the # of ops per second? -- 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

rc registry registry rc
by Jenkinson, John P (SAIC) 29 Mar '00

29 Mar '00

we get these messages on reboot of one netapp ** Option wafl.default_unix_user is being set to "pcuser" in /etc/rc, ** and this conflicts with a value - "root" - loaded from the registry. ** Commands in /etc/rc always override the registry at boot time, ** so the value of wafl.default_unix_user is now "pcuser". Fri Mar 24 16:15:10 AKS [rc]: Option wafl.default_unix_user with value "pcuser" in /etc/rc is overri from the registry. ** Option wafl.default_unix_user is being set to "root" in /etc/rc, ** and this conflicts with a value - "pcuser" - loaded from the registry. ** Commands in /etc/rc always override the registry at boot time, ** so the value of wafl.default_unix_user is now "root". the option line is not in the /etc/rc file anyone know what causes such schizo behaviour? wher is a netapp's registry? ======================== John Jenkinson BP Exploration (Alaska)

1 0

Re: Creating a RAID
by July at Zerowait 29 Mar '00

29 Mar '00

We're using 5.3.4R3. I'll be interested in hearing about your cautionary note regarding the usage of full disks or not. I'm pretty sure it's okay, though, because striping requires a parity drive and each RAID has its own parity drive. I don't see how WAFL can stripe across several RAIDs and properly maintain parity. July John Denholm wrote: > > > >From July at Zerowait on Tue, 28 Mar 2000 15:52:57 EST: > > > > > > > >Hello: The filer in question is an inherited box, an F760 with two > > > >shelves of 9GB SCSI drives, one shelf of 9GB FC-AL drives all in one > > > >RAID and one VOL. The single VOL also contains the root, I think. I've > > > >heard that you are supposed to separate SCSI and FC-AL drives into > > > >separate RAID groups, but this is how the box came and we can't change > > > >it. > > > > > > > >Anyway, my task is to add two shelves of 36GB drives to this unit. I > > > >know I need to create a separate RAID group for the 36GB drives. In the > > > >man pages I see instructions for adding disks to an existing volume and > > > >how to create a volume. I don't see anything that tells me how to create > > > >a new RAID group. I must be missing something obvious. > > July, (cool name :) > > A cautionary word... > > Someone from Netapp could perhaps address this one. > I'm not sure you'll get the full 36G out of your drives! > > I know it always used to be the case that if you had different raid sets with > different size drives in the raid sets, as long as the set was all the same > size, it didn't matter, all disks were fully used. This was because WAFL used > to round-robin between raid sets for writes. > > I heard a whisper that this wasn't the case any more, that now it fully striped > across ALL raid sets. Can someone from Netapp jump in with an AWOOGAH or an > all clear? > > So, what version of ONTAP are you running there July? > > J > > --------------------------------------------------------------------------- > # John Denholm johnd(a)theplanet.net # > # Webcache & Filer Administrator, Planet Online +44 113 207 6357 # > --------------------------------------------------------------------------- > > Error 404: There is no spoon -- ---------------------------------------------------------------- July A. J. Linett, VP Tech Mktg 302.266.9408 july(a)zerowait.com Zerowait: Best Of Breed Internet Core Technologies Web Acceleration ** Data Storage ** Load Balancing www.zerowait.com*www.loadbalancing.net*www.nas-san.com -------------------------------------------------------------------

1 0

RE: Re: NIS and netgroup file
by johnj.sasso＠ps.ge.com 29 Mar '00

29 Mar '00

I fully agree. Having experience with administering Auspex servers as well as NetApps, as well as administering a large, complex NIS environment, it would be a pity to start adding more overhead to the NetApp outside of what it was originally intended for (i.e. fileservice). The Auspex was was a pain to manage because its lack of simplicity, and I didn't see the dedication to fileservice that NetApp provides. As of 5.3.4 (?), NetApp provides the nis.servers option, where you can list all the possible NIS servers to bind to. This has worked quite well in our environment, esp. in the face of a failure of an NIS server the filer was bound to. Adding more overhead to the filer, such as NIS slave service, will only complexify the NetApp more, and as Jeff alluded to, bring it more into the Auspex realm (IMHO, this would only hurt NetApp). One of the features that makes the NetApp great to work with is its simplicity w.r.t. administration; if this isn't for you, then go with an Auspex or Sun (and buy enough Tylenol to boot). --john -----Original Message----- From: Jeff Innis [mailto:figaro911@hotmail.com] Sent: Tuesday, March 28, 2000 6:13 PM To: sirbruce(a)ix.netcom.com Cc: abond(a)netapp.com; demarest(a)arraycomm.com; toasters(a)mathworks.com Subject: Fwd: Re: NIS and netgroup file Sure why not add NIS server, why stop there though lets add DNS too. Hey these things are so reliable, let's put a full blown kernel in there, and start running user apps as well. Anyone ever hear of a little box called Auspex??? I actually thought the concept of "dedicated" NFS appliance was a good one. Jeff > > > We are looking into ways of improving the NIS implementation to be more > > efficient. We are not planning on implementing the slave functionality >on > > the filer though. > >That's too bad, because it essentially makes a network less robust. >See, if you rely on NIS files so you don't have to copy files to the >filer locally, then lets say you have a power outage. The filer comes >up and then can't do anything because it's waiting to talk to the NIS >server (it's probably the DNS server too). The NIS server can't do >anything because it's waiting to mount the filer. Stalemate. There are >ways around this, like having your NIS/DNS server hold the data on a >local disk, but then you have a kink in your whole centralized network >storage scheme. Altenatively, you can copy everything to the filer, but >then you've defeated the whole purpose of NIS. > >Making filers slave servers is an ideal solution. You don't have to >allow other clients to bind to them, but this way they can get data >updated from a master and still have a local copy in the event of >network problems. > >Bruce > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

RE: NIS and netgroup file
by Nagaraj, Devi 29 Mar '00

29 Mar '00

Jeff/Bruce, Your input is very valuable. We will take into account your suggestion while we improve the NIS services on the filer for the next release. Jeff - instead of binding using broadcast, you can secify the NIS servers you want to bind to in the order of preference. This will make sure that the same NIS server is not bombarded by all the filers. -Devi -----Original Message----- From: Jeff Krueger [mailto:jkrueger@qualcomm.com] Sent: Tuesday, March 28, 2000 4:00 PM To: Bruce Sterling Woodcock Cc: Nagaraj, Devi; Bond, Andrew; Timothy Demarest; toasters(a)mathworks.com Subject: Re: NIS and netgroup file We are in full accord with Bruce's comments below. Although recent enhancements to the NIS client have made it speedier and more robust, loss of communications with a NIS slave has consistently been one of our largest causes for NetApp services outages. Additionally, binding several NetApps to the same slave places tremendous strain on that slave due to continual hammering by the filers. A lightweight slave implementation inside DOT would be a welcome feature. As Bruce mentioned, it need not provide maps to other machines, but only for its own purposes. This would reduce network traffic and strain on existing boxes, free up an external dependency, and likely improve the speed of authentication which may make the filer run faster overall. As a side-note, our old Auspex ran a NIS slave for the same basic reason although it was horrible for machines to bind to. In broadcast mode, we found that our NetApps *loved* binding to it among the multitude of other slaves on that particular subnet. =) -- 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 >From "Bruce Sterling Woodcock" on Tue, 28 Mar 2000 14:10:10 PST: > > >----- Original Message ----- >From: Nagaraj, Devi <devi.nagaraj(a)netapp.com> >To: 'Bruce Sterling Woodcock' <sirbruce(a)ix.netcom.com>; Bond, Andrew ><abond(a)netapp.com>; Timothy Demarest <demarest(a)arraycomm.com> >Cc: <toasters(a)mathworks.com> >Sent: Tuesday, March 28, 2000 9:15 AM >Subject: RE: NIS and netgroup file > > >> We are looking into ways of improving the NIS implementation to be more >> efficient. We are not planning on implementing the slave functionality on >> the filer though. > >That's too bad, because it essentially makes a network less robust. >See, if you rely on NIS files so you don't have to copy files to the >filer locally, then lets say you have a power outage. The filer comes >up and then can't do anything because it's waiting to talk to the NIS >server (it's probably the DNS server too). The NIS server can't do >anything because it's waiting to mount the filer. Stalemate. There are >ways around this, like having your NIS/DNS server hold the data on a >local disk, but then you have a kink in your whole centralized network >storage scheme. Altenatively, you can copy everything to the filer, but >then you've defeated the whole purpose of NIS. > >Making filers slave servers is an ideal solution. You don't have to >allow other clients to bind to them, but this way they can get data >updated from a master and still have a local copy in the event of >network problems. > >Bruce > >

1 0

RE: 3rd Party NFS Clients
by Jen Hamilton 29 Mar '00

29 Mar '00

For those of you using NFS Maestro to log onto NetApps from NT workstations, what authenticates the user? I get "Authorization Error" when logging in, unless I'm user "nobody" with no password. Thanks, Jen Hamilton

2 1

ndmpcopy problem (long)
by Deron Johnson 28 Mar '00

28 Mar '00

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? -- Deron Johnson djohnson(a)amgen.com

3 3

RE: NIS and netgroup file
by Nagaraj, Devi 28 Mar '00

28 Mar '00

Do you have NIS for netgroup lookup in your /etc/nsswitch.conf file? The group information ( not netgroup) can be obtained using the command ypgroup. -Devi -----Original Message----- From: Timothy Demarest [mailto:demarest@arraycomm.com] Sent: Tuesday, March 28, 2000 9:30 AM To: Bond, Andrew Cc: toasters(a)mathworks.com Subject: Re: NIS and netgroup file >>>>> "Andrew" == Bond, Andrew <abond(a)netapp.com> >>>>> wrote the following on Tue, 28 Mar 2000 00:53:07 -0800 Andrew> The filer does not copy the NIS maps into /etc. NIS group Andrew> information is cached, but otherwise the filer acts as a NIS Andrew> client only, and will query the NIS server it has bound to ("nis Andrew> info" will tell you which this is). Andrew: Thanks for the info. I can't seem to get the Filer to lookup netgroup information via NIS. If I manually place a system's name in the exports file, the system can then mount the volume. If I use an NIS netgroup name for which the system is a member, I cannot mount the volume. Is there a way to see what NIS information the Filer thinks it has cached? Tim

3 2

Re: NIS and netgroup file
by Timothy Demarest 28 Mar '00

28 Mar '00

>>>>> "Mark" == Mark Stoltzfus <stoltzfu(a)susq.com> >>>>> wrote the following on Tue, 28 Mar 2000 13:41:23 -0500 Mark> Do you use FQDNs in your netgroup map? If so, you're getting hit Mark> by bug #19922 (same as us :P ). We eventually threw our hands in Mark> the air and hacked our yp make script to just stick a copy of Mark> netgroup into our filers' /etcs. Sigh. Thanks, Mark. That seems to be the problem. I guess I'll hack the makefile to copy over the netgroup file. Tim

1 0

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

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