toasters

toasters@lists.teaparty.net

13531 discussions

Deleting snapshot
by Premanshu Jain 08 Sep '00

08 Sep '00

I have some snapshots created by failed backup processes and shows them busy still. How can I delete them..? Volume sw working..................................................................... ............................................................................ .................................... %/used %/total date name ---------- ---------- ------------ -------- 3% ( 3%) 2% ( 2%) Sep 07 18:04 bot_sw.1 4% ( 3%) 3% ( 2%) Sep 07 16:12 hourly.0 4% ( 4%) 3% ( 3%) Sep 07 12:10 hourly.1 5% ( 4%) 3% ( 3%) Sep 07 08:10 hourly.2 5% ( 4%) 4% ( 3%) Sep 07 00:11 nightly.0 6% ( 4%) 4% ( 3%) Sep 06 20:11 hourly.3 7% ( 4%) 5% ( 3%) Sep 06 16:12 hourly.4 7% ( 4%) 5% ( 3%) Sep 06 12:10 hourly.5 8% ( 4%) 6% ( 3%) Sep 06 00:08 nightly.1 19% (15%) 17% (12%) Aug 20 21:52 snapshot_for_backup.32 (busy) 20% (15%) 17% (12%) Aug 19 22:46 snapshot_for_backup.30 (busy) 21% (15%) 19% (12%) Aug 17 04:08 snapshot_for_backup.23 (busy)

2 1

RE: Deleting snapshot
by Premanshu Jain 08 Sep '00

08 Sep '00

NDMP or Veritas Netbackup. All these snapshots were a part of failed backups prem -----Original Message----- From: J. Bryan Kelsch [mailto:mrb@netapp.com] Sent: Friday, September 08, 2000 11:13 AM To: Premanshu Jain Cc: toasters(a)mathworks.com Subject: Re: Deleting snapshot This is not a function the filer, it is an error in the backup software that is not cleaning up properly. > > > >You have to reboot first. > > >On Fri, 8 Sep 2000 10:42:26 -0700 , you wrote: > >>I have some snapshots created by failed backup processes and shows them busy >>still. How can I delete them..? >> >> >>Volume sw >>working................................................................... .. >>.......................................................................... .. >>.................................... >> >> %/used %/total date name >>---------- ---------- ------------ -------- >> 3% ( 3%) 2% ( 2%) Sep 07 18:04 bot_sw.1 >> 4% ( 3%) 3% ( 2%) Sep 07 16:12 hourly.0 >> 4% ( 4%) 3% ( 3%) Sep 07 12:10 hourly.1 >> 5% ( 4%) 3% ( 3%) Sep 07 08:10 hourly.2 >> 5% ( 4%) 4% ( 3%) Sep 07 00:11 nightly.0 >> 6% ( 4%) 4% ( 3%) Sep 06 20:11 hourly.3 >> 7% ( 4%) 5% ( 3%) Sep 06 16:12 hourly.4 >> 7% ( 4%) 5% ( 3%) Sep 06 12:10 hourly.5 >> 8% ( 4%) 6% ( 3%) Sep 06 00:08 nightly.1 >> 19% (15%) 17% (12%) Aug 20 21:52 snapshot_for_backup.32 (busy) >> 20% (15%) 17% (12%) Aug 19 22:46 snapshot_for_backup.30 (busy) >> 21% (15%) 19% (12%) Aug 17 04:08 snapshot_for_backup.23 (busy) ------------------------ J. Bryan Kelsch, PSE Network Appliance 5220 Spring Valley Road - Suite 350 Dallas, TX 75240 972.759.7528 Office 817.821.0350 Cell 888.374.6422 Pager

1 0

RE: vif between 740 & 520 problems & questions
by Thompson, Arnold 08 Sep '00

08 Sep '00

Hi John, You're not doing anything wrong - it's the load-balancing algorithm used by etherchannel that's causing you to use only one interface. In a nutshell, etherchannel does a hash on the last two bits of the source MAC address and comes up with one of four possible combinations. Your NDMPcopy connection starts up on only one port, using a single MAC address, so essentially there are no multiple MAC addresses to load-balance. Additionally, the balancing decision based on this hash is made by an etherchannel-enabled switch, not the Netapp box itself. Etherchannel requires all ports to be on the same switch and only really works when you have multiple clients (and consequently multiple possible hash combinations) accessing one server - it fails completely when you have a single "client" accessing a single server. In brief, to get the best migration performance, use gigabit ethernet between two systems. You can simply reverse the optical cable leads - you don't even need a switch. The good news is that more sophisticated load-balancing algorithms are under consideration, although I can't give you specifics or tell you when Netapp will have them available. Good luck, Arnie > -----Original Message----- > From: John Stoffel [mailto:john@casc.com] > Sent: Friday, September 08, 2000 7:11 AM > To: toasters(a)mathworks.com > Subject: vif between 740 & 520 problems & questions > > > > Hi all, > > I've got a couple of questions on setting up and using vifs between > two filers to help speed up data migration from the old F520 to a new > F740. > > They're configed like this: > > F520 F740 > OnTap: 5.2.1 OnTap: 5.3.6p2 > RAM: 256Mb RAM: 512Mb > Quad Ethernet Quad Ethernet > Gigabit Ethernet > > I've networked the two systems together using three ports on each Quad > Ethernet board, but due to distance limitations, I'm going through > three seperate hubs. So the two filers are basically hooked up > back-to-back over a private network. > > I did the various vif commands, and they are setup correctly, and they > are passing traffic properly, but just over one of the three links. I > know I need to upgrade the F520 to match OnTap versions, and will do > so next weekend when I have some down time, but I wanted to play > around with ndmpcopy beforehand to see how the performance will be. > > Doing a test this morning, I managed to crash the new F740 with a PCI > Parity error while doing another test of ndmpcopy. Whee! > > My questions: > > - will vifs work properly across direct connections between filers? > > - Has anyone used a Lucent Cajun P220 switch to implement a VIF? I > could easily run a fiber link from the F740 to a Cajun which would > then run the three ethernet links. > > And while I work for Lucent, the Cajun wasn't made in our division and > I haven't used it. > > Thanks, > John > John Stoffel - Senior Unix Systems Administrator - Lucent > Technologies > stoffel(a)lucent.com - http://www.lucent.com - 978-952-7548 > john.stoffel(a)ascend.com - http://www.ascend.com >

1 0

SUMMARY: vif between 740 & 520 problems & questions
by John Stoffel 08 Sep '00

08 Sep '00

Hi all, The general consensus is that a VIF won't help me at all, since all the data will just go via the primary interface, and won't use the two other interfaces at all. This is what I'm seeing on the system anyway, so I guess I'm out of luck. Thanks for all your comments! John John Stoffel - Senior Unix Systems Administrator - Lucent Technologies stoffel(a)lucent.com - http://www.lucent.com - 978-952-7548 john.stoffel(a)ascend.com - http://www.ascend.com

1 0

vif between 740 & 520 problems & questions
by John Stoffel 08 Sep '00

08 Sep '00

Hi all, I've got a couple of questions on setting up and using vifs between two filers to help speed up data migration from the old F520 to a new F740. They're configed like this: F520 F740 OnTap: 5.2.1 OnTap: 5.3.6p2 RAM: 256Mb RAM: 512Mb Quad Ethernet Quad Ethernet Gigabit Ethernet I've networked the two systems together using three ports on each Quad Ethernet board, but due to distance limitations, I'm going through three seperate hubs. So the two filers are basically hooked up back-to-back over a private network. I did the various vif commands, and they are setup correctly, and they are passing traffic properly, but just over one of the three links. I know I need to upgrade the F520 to match OnTap versions, and will do so next weekend when I have some down time, but I wanted to play around with ndmpcopy beforehand to see how the performance will be. Doing a test this morning, I managed to crash the new F740 with a PCI Parity error while doing another test of ndmpcopy. Whee! My questions: - will vifs work properly across direct connections between filers? - Has anyone used a Lucent Cajun P220 switch to implement a VIF? I could easily run a fiber link from the F740 to a Cajun which would then run the three ethernet links. And while I work for Lucent, the Cajun wasn't made in our division and I haven't used it. Thanks, John John Stoffel - Senior Unix Systems Administrator - Lucent Technologies stoffel(a)lucent.com - http://www.lucent.com - 978-952-7548 john.stoffel(a)ascend.com - http://www.ascend.com

1 0

FC card slot exchange helped us [Was : gigabit ethernet performance]
by kubek 08 Sep '00

08 Sep '00

I do not have a solution but maybe these experiments done with a 720 may help (I must thank our local reseller support here :). We received an F720 some weeks ago (quad ethernet / FC9) A 'systat 1' showed a really bad performance on the administrative Ethernet (100M) interface : the filer was inputting ~4MB/s when creating a 100MB file from a Sparc. By moving the FC card from the slot 8 to the slot 2 and rebooting the (little:() beast we are now going to ~11MB/s . Seems that netapp hardware layer is as poor as some PC cards builders :( Maybe the trick will work for you : try to move your FC card from its current slot (8?) to another one. Jean-Marie

1 0

Budtool woes
by Clawson, Simon 07 Sep '00

07 Sep '00

Hi! We have Budtool 4.6.1, and are currently looking for a replacement. However... I am bacing up a single volume filer with nearly 200GB of data - my backup is constanlty failing due to the process running out of time..anyone seen this? Is there a way round it? Can I increse the allowable time? Can I split the backup into several levels? HELP! Simon Simon Clawson Renoir Group Systems Administrator Mentor Graphics Uk Rivergate London Road Newbury Berkshire RG14 2QB <<Clawson, Simon.vcf>>

4 4

question1:exportfs -au crash ORACLE daemon; question2:snapshot di r. confusion
by Li, Jack 07 Sep '00

07 Sep '00

Hi, Question#1: We have a F740 filer used as the Oracle DB storage. Our platform is : Sun-Solaris 2.7, SUN 420R,using Giga-bit private connection into filer; using recommended NFS mount options for Oracle 816. Situation: when we have a request to "expand" our filer for sharing (exportfs), and as the time the Oracle daemons were running. We changed the filer's /etc/exports, then executed "exportfs -au", "exportfs -a". And, right after those 2 command to the filer, ALL our Oracle daemons crashed and died. Is that supposed to happen? Question#2: We tried to write a SHELL script to automate our daily (filer) snapshot operation. During the course of testing, we found out a very annoying situation. (The HW/SW specification are the same as above.) There is a Q-tree called "/vol/vol01/ismis_oracle_u1" and is mounted under this machine at the mount point of "/oracle/u1". The problem happened after the snapshot was taken. One of our team member set the source PATH (wrong) to /oracle/u1/oradata/.snapshot in the script (supposed to be "/oracle/u1/.snapshot"). And, this PATH actually worked some of the time. But, when it failed , it showed the error message as "cp: can not find files /oracle/u1/oradata/.snapshot/*". Interesting thing is if we insert a "/bin/ls /orcale/u1/oradata/.snapshot/*" right before the "cp" command, the directory seems to be there after the command , hence the "cp" operation was happy. Any idea? Thanks! Jack Li UNIX System Admin. Team, Toronto Production Support, Capital Markets, Nesbitt Burns Emf!sys, Division of Bank of Montreal Group of Company 416-867-3527,(fax)416-867-7157 <mailto:Jack.Li@bmo.com> Jack.Li(a)bmo.com

3 2

RE: dlt autoloaders
by Premanshu Jain 07 Sep '00

07 Sep '00

I would like to discuss with you in detail about implementing NDMP via gig bit .Let me know the best time I should call. thanks prem Premanshu Jain IS Engineering Support Lead Nortel Networks, Carrier Packet Solutions IP Services Division 2305, Mission College Blvd, Santa Clara, CA 95054 Direct: (408) 565-3573 ESN: 655-3573 eMail: prjain(a)shastanets.com Web: http://www.nortelnetworks.com/ipservices -----Original Message----- From: Kamenzin, Marcus [mailto:kamenzin@netapp.com] Sent: Thursday, September 07, 2000 1:57 PM To: Premanshu Jain; 'Stephen J. Wilcox'; neil lehrer Cc: toasters Subject: RE: dlt autoloaders Hi there, a) AIT II is really good!! b) Quick Restore is the best NDMP-Solution (best NDMP-implementation - really 3-way) c) Don't use FC-Backup, only if you really want the advantage of tape sharing. The supported FC-Backup-solution has a lot of limitations. So, use direct att. SCSI or new Libraries with implemented NDMP-Servers via GBit. Regards Marcus Marcus Kamenzin System Engineer Network Appliance GmbH Unterreut 6 D-76135 Karlsruhe Tel.: (0721) 86901-17 Fax: (0721) 86901-11 Mobile: (0170) 4464341 Mail: kamenzin(a)netapp.com > -----Original Message----- > From: Premanshu Jain [SMTP:PrJain@shastanets.com] > Sent: Thursday, September 07, 2000 6:15 PM > To: 'Stephen J. Wilcox'; neil lehrer > Cc: toasters > Subject: RE: dlt autoloaders > > a) Why don't you try AIT II instead of DLT. I am getting excellant > performance on those 8 mm. Writing more that 100 GB per tape. We are using > Qualstar and spectra logic tape libraries. > > b) Veritas seems to be OK. With lot of limitations and bugs. I have heard of > a better s/w from www.worksta.com > > c) You may use a Vixel Fibre channal switch with fibre channal interfaces on > the concerened servers and the Filers. This will enable accessing tpaes from > anywhere. > > -----Original Message----- > From: Stephen J. Wilcox [mailto:steve@opaltelecom.co.uk] > Sent: Thursday, September 07, 2000 1:07 AM > To: neil lehrer > Cc: toasters > Subject: Re: dlt autoloaders > > > Actually on that subject I am looking to buy a system soon, I'm thinking > of getting an HP surestore library and using Veritas. Theres a lot of > systems to back up altho they dont have that much data on them, then I > have (for now 1) netfiler, does anyone > > a) think surestore are good? > b) think veritas is good? > c) know if i can do anything to save time by directly connecting the tape > library to the filer hence bypassing the server but still keeping the tape > accessible from the server in order to do my network backups? > > Steve > > -- > Stephen J. Wilcox > Internet Manager, Opal Telecom > http://www.opaltelecom.co.uk/ > Tel: 0161 222 2000 > Fax: 0161 222 2008 > > On Wed, 6 Sep 2000, neil lehrer wrote: > > > hi, > > > > i'd like recommendations for a dlt autoloader to be attached to an f760 > > and controlled by legato. thanks. > > -- > >

1 0

RE: dlt autoloaders
by Kamenzin, Marcus 07 Sep '00

07 Sep '00

Hi there, a) AIT II is really good!! b) Quick Restore is the best NDMP-Solution (best NDMP-implementation - really 3-way) c) Don't use FC-Backup, only if you really want the advantage of tape sharing. The supported FC-Backup-solution has a lot of limitations. So, use direct att. SCSI or new Libraries with implemented NDMP-Servers via GBit. Regards Marcus Marcus Kamenzin System Engineer Network Appliance GmbH Unterreut 6 D-76135 Karlsruhe Tel.: (0721) 86901-17 Fax: (0721) 86901-11 Mobile: (0170) 4464341 Mail: kamenzin(a)netapp.com > -----Original Message----- > From: Premanshu Jain [SMTP:PrJain@shastanets.com] > Sent: Thursday, September 07, 2000 6:15 PM > To: 'Stephen J. Wilcox'; neil lehrer > Cc: toasters > Subject: RE: dlt autoloaders > > a) Why don't you try AIT II instead of DLT. I am getting excellant > performance on those 8 mm. Writing more that 100 GB per tape. We are using > Qualstar and spectra logic tape libraries. > > b) Veritas seems to be OK. With lot of limitations and bugs. I have heard of > a better s/w from www.worksta.com > > c) You may use a Vixel Fibre channal switch with fibre channal interfaces on > the concerened servers and the Filers. This will enable accessing tpaes from > anywhere. > > -----Original Message----- > From: Stephen J. Wilcox [mailto:steve@opaltelecom.co.uk] > Sent: Thursday, September 07, 2000 1:07 AM > To: neil lehrer > Cc: toasters > Subject: Re: dlt autoloaders > > > Actually on that subject I am looking to buy a system soon, I'm thinking > of getting an HP surestore library and using Veritas. Theres a lot of > systems to back up altho they dont have that much data on them, then I > have (for now 1) netfiler, does anyone > > a) think surestore are good? > b) think veritas is good? > c) know if i can do anything to save time by directly connecting the tape > library to the filer hence bypassing the server but still keeping the tape > accessible from the server in order to do my network backups? > > Steve > > -- > Stephen J. Wilcox > Internet Manager, Opal Telecom > http://www.opaltelecom.co.uk/ > Tel: 0161 222 2000 > Fax: 0161 222 2008 > > On Wed, 6 Sep 2000, neil lehrer wrote: > > > hi, > > > > i'd like recommendations for a dlt autoloader to be attached to an f760 > > and controlled by legato. thanks. > > -- > >

1 0

RE: dlt autoloaders
by Premanshu Jain 07 Sep '00

07 Sep '00

a) Why don't you try AIT II instead of DLT. I am getting excellant performance on those 8 mm. Writing more that 100 GB per tape. We are using Qualstar and spectra logic tape libraries. b) Veritas seems to be OK. With lot of limitations and bugs. I have heard of a better s/w from www.worksta.com c) You may use a Vixel Fibre channal switch with fibre channal interfaces on the concerened servers and the Filers. This will enable accessing tpaes from anywhere. -----Original Message----- From: Stephen J. Wilcox [mailto:steve@opaltelecom.co.uk] Sent: Thursday, September 07, 2000 1:07 AM To: neil lehrer Cc: toasters Subject: Re: dlt autoloaders Actually on that subject I am looking to buy a system soon, I'm thinking of getting an HP surestore library and using Veritas. Theres a lot of systems to back up altho they dont have that much data on them, then I have (for now 1) netfiler, does anyone a) think surestore are good? b) think veritas is good? c) know if i can do anything to save time by directly connecting the tape library to the filer hence bypassing the server but still keeping the tape accessible from the server in order to do my network backups? Steve -- Stephen J. Wilcox Internet Manager, Opal Telecom http://www.opaltelecom.co.uk/ Tel: 0161 222 2000 Fax: 0161 222 2008 On Wed, 6 Sep 2000, neil lehrer wrote: > hi, > > i'd like recommendations for a dlt autoloader to be attached to an f760 > and controlled by legato. thanks. > -- >

1 0

Re: gigabit ethernet performance
by Marcus Smiley 07 Sep '00

07 Sep '00

two of 'em (450MHZ), with 2GB RAM. On Wed, 06 Sep 2000, Jim Patterson wrote: ! Marcus, ! ! How many CPUs do you have in your 220R? We have found that a single CPU ! is needed just to keep the network interface busy so the minimum ! configuration to get better than 10MB/sec is two CPUs. ! ! Jim ! -- ! Jim Patterson ! Pfizer Global Research and Development, La Jolla ! ! Marcus Smiley | Ericsson Wireless Communications, Inc. Unix Sys Admin | 6210 Spine Rd. Boulder, CO 80301 | Ph (303) 473-6903

1 0

Re: gigabit ethernet performance
by Darrell Fuhriman 07 Sep '00

07 Sep '00

Premanshu Jain <PrJain(a)shastanets.com> writes: > Oh..That's even better. We got a max of 8 mbytes/sec. Never more than that. > Interestingly, we get the same throughput between any sun boxes as well... No offense, but you must be doing something wrong. Our Suns (E450s) can do at least 60MB/second over gigabit. Darrell

1 0

RE: gigabit ethernet performance
by Premanshu Jain 07 Sep '00

07 Sep '00

Oh..That's even better. We got a max of 8 mbytes/sec. Never more than that. Interestingly, we get the same throughput between any sun boxes as well... prem -----Original Message----- From: Marcus Smiley [mailto:marcus.smiley@ericsson.com] Sent: Wednesday, September 06, 2000 2:41 PM To: toasters(a)mathworks.com Subject: gigabit ethernet performance Does anyone have any benchmarks/suggestions for poor performace with gigabit ethernet between Sun enterprise 220R and NetApp 740 with Intel GBII card? I have an open ticket w/Netapp and it's been open forever. These machines are directly attached (private network), and I've tried a mkfile and copying that file back during the day and at night (no load) and it makes no difference. The performance is ~ 10 MB/s, no matter what. The Sun is running Solaris 8, with latest GB Ethernet 3.0 drivers and patches. Also, the Sun box's only function is Legato server, so I've even stopped all nsr daemons while the test copy/mkfile is in progress, & it makes no difference. I've tried NFSv2 vs. NFSv3, with 32k size packets and 8k size packets. I've tried tcp and udp, with the same results. The /etc/system file on the E220R looks like this, for the ge adapter: * Increase size of STREAMS syncronized queues to increase network * performance. Release notes for qfe card recommends setting this * to 25 per 64Mbytes of RAM in the system. It also prevents * receive overrun on the GbE interface. msmiley 7/20/00 set sq_max_size=775 set ge:ge_adv_1000autoneg_cap=0 set ge:ge_adv_1000fdx_cap=1 set ge:ge_adv_pauseTX=1 Also, I've set tcp/udp specific stuff per the Netapp tech suppt. folks: ndd -set /dev/udp udp_recv_hiwat 65535 ndd -set /dev/udp udp_xmit_hiwat 65535 ndd -set /dev/tcp tcp_recv_hiwat 65535 ndd -set /dev/tcp tcp_xmit_hiwat 65535 The netapp is a 740 (5.3.6R1P1) with over 100GB of free space available on the volume I'm copying to/from. Interestingly enough, I have done a packet trace (pktt) on the GBII card and it looks OK. Also, the throughput from my 100BaseT card to the netapp (thru a catalyst 5500) does ~ 7.5 MB/s. *Any* input here would be much appreciated. -Marc Marcus Smiley | Ericsson Wireless Communications, Inc. Unix Sys Admin | 6210 Spine Rd. Boulder, CO 80301 | Ph (303) 473-6903

1 0

Re: gigabit ethernet performance
by Marcus Smiley 06 Sep '00

06 Sep '00

no there is no switch between the filer and Sun box, using crossover fiber jumper scenario. yes, both machines are set to FULL flow control. Here's a sysstat 1 before, during & after I create a 100MB file, using mkfile: CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 3% 52 0 0 19 43 0 0 0 0 38 3% 65 2 0 11 10 0 0 0 0 38 4% 35 2 0 51 13 0 0 0 0 38 3% 6 23 0 167 10 0 0 0 0 38 4% 36 23 0 14 5 0 0 0 0 38 4% 29 79 0 72 28 52 0 0 0 38 38% 10 260 0 22 57 4412 10316 0 0 38 6% 20 2 0 36 136 3 0 0 0 38 59% 601 1 0 13398 374 0 0 0 0 38 82% 398 16 0 9009 291 4684 14874 0 0 38 73% 572 23 0 12229 363 2972 7208 0 0 38 87% 457 2 0 10112 326 3688 16404 0 0 38 80% 327 0 0 9509 284 5980 14176 0 0 38 73% 520 15 0 14158 405 1093 5053 0 0 38 93% 342 0 0 8070 269 7148 18589 0 0 38 68% 356 2 0 9640 283 5428 11073 0 0 38 82% 591 0 0 11667 346 4112 9208 0 0 38 88% 562 3 0 8520 506 6740 15836 0 0 38 32% 135 1 0 4585 271 1077 4032 0 0 38 3% 19 0 0 4 4 0 0 0 0 38 CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 3% 64 0 0 3 2 0 0 0 0 38 3% 48 0 0 14 12 0 0 0 0 38 3% 17 2 0 13 10 0 0 0 0 38 3% 4 12 0 30 5 0 0 0 0 38 3% 4 12 0 4 2 0 0 0 0 38 On Wed, 06 Sep 2000, Paul Albers wrote: ! Marcus, ! ! Do you have flow control enabled on both Rx and Tx on the ! port the filer is connected to on the switch? If not, try enabling ! it and retest. How does the filer look during writes and ! reads ( sysstat 1 )? Also, what is the configuration of the ! filer ( cards in what slots? ). ! ! Regards, ! ! -paul ! ! Marcus Smiley wrote: ! ! > slot 8 ! > ! > On Wed, 06 Sep 2000, Larry Armstrong wrote: ! > ! > ! Howdy! ! > ! ! > ! Out of curiousity, what slot do you have your GbE card in? ! > ! ! > ! ---larry >:) ! > ! _ ! > ! * Marcus Smiley (marcus.smiley(a)ericsson.com) done spit this rhetoric: ! > ! > Does anyone have any benchmarks/suggestions for poor performace with ! > ! > gigabit ethernet between Sun enterprise 220R and NetApp 740 with Intel ! > ! > GBII card? I have an open ticket w/Netapp and it's been open ! > ! > forever. These machines are directly attached (private network), and ! > ! > I've tried a mkfile and copying that file back during the day and at ! > ! > night (no load) and it makes no difference. ! > ! > ! > ! > The performance is ~ 10 MB/s, no matter what. ! > ! > ! > ! > The Sun is running Solaris 8, with latest GB Ethernet 3.0 drivers ! > ! > and patches. Also, the Sun box's only function is Legato server, ! > ! > so I've even stopped all nsr daemons while the test copy/mkfile ! > ! > is in progress, & it makes no difference. ! > ! > ! > ! > I've tried NFSv2 vs. NFSv3, with 32k size packets and 8k size packets. ! > ! > I've tried tcp and udp, with the same results. ! > ! > ! > ! > The /etc/system file on the E220R looks like this, for the ge adapter: ! > ! > ! > ! > * Increase size of STREAMS syncronized queues to increase network ! > ! > * performance. Release notes for qfe card recommends setting this ! > ! > * to 25 per 64Mbytes of RAM in the system. It also prevents ! > ! > * receive overrun on the GbE interface. msmiley 7/20/00 ! > ! > ! > ! > set sq_max_size=775 ! > ! > set ge:ge_adv_1000autoneg_cap=0 ! > ! > set ge:ge_adv_1000fdx_cap=1 ! > ! > set ge:ge_adv_pauseTX=1 ! > ! > ! > ! > Also, I've set tcp/udp specific stuff per the Netapp tech suppt. folks: ! > ! > ! > ! > ndd -set /dev/udp udp_recv_hiwat 65535 ! > ! > ndd -set /dev/udp udp_xmit_hiwat 65535 ! > ! > ndd -set /dev/tcp tcp_recv_hiwat 65535 ! > ! > ndd -set /dev/tcp tcp_xmit_hiwat 65535 ! > ! > ! > ! > The netapp is a 740 (5.3.6R1P1) with over 100GB of free space available on the ! > ! > volume I'm copying to/from. ! > ! > ! > ! > Interestingly enough, I have done a packet trace (pktt) on the GBII ! > ! > card and it looks OK. Also, the throughput from my 100BaseT card to ! > ! > the netapp (thru a catalyst 5500) does ~ 7.5 MB/s. ! > ! > ! > ! > *Any* input here would be much appreciated. ! > ! > ! > ! > -Marc ! > ! > ! > ! > ! > ! > ! > ! > Marcus Smiley | Ericsson Wireless Communications, Inc. ! > ! > Unix Sys Admin | 6210 Spine Rd. Boulder, CO 80301 | Ph (303) 473-6903 ! > ! > ! > ! ! > ! -- ! > ! Larry Armstrong ! > ! <surfer(a)netapp.com> ! > ! ! > ! bovarism n. - A magnified opinion of one's own abilities. ! > ! > Marcus Smiley | Ericsson Wireless Communications, Inc. ! > Unix Sys Admin | 6210 Spine Rd. Boulder, CO 80301 | Ph (303) 473-6903 ! ! -- ! "Nothing will benefit human health and increase the chances of survival ! of life on earth as much as the evolution to a vegetarian diet." ! ! -Albert Einstein !

1 0

Re: gigabit ethernet performance
by Marcus Smiley 06 Sep '00

06 Sep '00

slot 8 On Wed, 06 Sep 2000, Larry Armstrong wrote: ! Howdy! ! ! Out of curiousity, what slot do you have your GbE card in? ! ! ---larry >:) ! _ ! * Marcus Smiley (marcus.smiley(a)ericsson.com) done spit this rhetoric: ! > Does anyone have any benchmarks/suggestions for poor performace with ! > gigabit ethernet between Sun enterprise 220R and NetApp 740 with Intel ! > GBII card? I have an open ticket w/Netapp and it's been open ! > forever. These machines are directly attached (private network), and ! > I've tried a mkfile and copying that file back during the day and at ! > night (no load) and it makes no difference. ! > ! > The performance is ~ 10 MB/s, no matter what. ! > ! > The Sun is running Solaris 8, with latest GB Ethernet 3.0 drivers ! > and patches. Also, the Sun box's only function is Legato server, ! > so I've even stopped all nsr daemons while the test copy/mkfile ! > is in progress, & it makes no difference. ! > ! > I've tried NFSv2 vs. NFSv3, with 32k size packets and 8k size packets. ! > I've tried tcp and udp, with the same results. ! > ! > The /etc/system file on the E220R looks like this, for the ge adapter: ! > ! > * Increase size of STREAMS syncronized queues to increase network ! > * performance. Release notes for qfe card recommends setting this ! > * to 25 per 64Mbytes of RAM in the system. It also prevents ! > * receive overrun on the GbE interface. msmiley 7/20/00 ! > ! > set sq_max_size=775 ! > set ge:ge_adv_1000autoneg_cap=0 ! > set ge:ge_adv_1000fdx_cap=1 ! > set ge:ge_adv_pauseTX=1 ! > ! > Also, I've set tcp/udp specific stuff per the Netapp tech suppt. folks: ! > ! > ndd -set /dev/udp udp_recv_hiwat 65535 ! > ndd -set /dev/udp udp_xmit_hiwat 65535 ! > ndd -set /dev/tcp tcp_recv_hiwat 65535 ! > ndd -set /dev/tcp tcp_xmit_hiwat 65535 ! > ! > The netapp is a 740 (5.3.6R1P1) with over 100GB of free space available on the ! > volume I'm copying to/from. ! > ! > Interestingly enough, I have done a packet trace (pktt) on the GBII ! > card and it looks OK. Also, the throughput from my 100BaseT card to ! > the netapp (thru a catalyst 5500) does ~ 7.5 MB/s. ! > ! > *Any* input here would be much appreciated. ! > ! > -Marc ! > ! > ! > ! > Marcus Smiley | Ericsson Wireless Communications, Inc. ! > Unix Sys Admin | 6210 Spine Rd. Boulder, CO 80301 | Ph (303) 473-6903 ! > ! ! -- ! Larry Armstrong ! <surfer(a)netapp.com> ! ! bovarism n. - A magnified opinion of one's own abilities. Marcus Smiley | Ericsson Wireless Communications, Inc. Unix Sys Admin | 6210 Spine Rd. Boulder, CO 80301 | Ph (303) 473-6903

1 0

quad ethernet -> gigabit on Cisco switches
by Todd C. Merrill 06 Sep '00

06 Sep '00

We are considering moving our F740 and F760 toasters from quad 100-Mbit ethernet EtherChannel'ed on a Cisco 5500 switch to the gigabit NICs on a new Cisco switch, a 6509. We're doing this 'cause: 1. We need more ports. Period. 2. The 6509 has a higher density of ports and gig ports. 3. The gigabit NICs are supposedly much faster, and you can offload the checksum processing from the main CPU to the gigabit card. (We're not even close to saturating the quad link now; I'm just talking latencies. Plus, we beat the crap out of our toasters; if the CPU can do less overhead and more data serving, I want it.) Anybody have any experience with the 6509 and NetApp's gigabit cards? Just want to assuage our concerns before placing the PO's. Until next time... The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

3 2

Re: quad ethernet -> gigabit on Cisco switches
by Rick Hulsey 06 Sep '00

06 Sep '00

We use the F-760 in a cluster and Cisco 6509 switches with Gigabit connectivity to Suns and HP-UX boxes. We haven't had any problems with Gig-e or the switches, but we haven't got them spun up to full production usage levels yet. I would say that you need to make sure that you get the Intel NICs for the filer, but if you are order new gear now from Netapp, that should be a given. Rick Hulsey Southwest Airlines 2425 Wyman Mail Stop 4DC Dallas, Tx., 75235 rick.hulsey(a)wnco.com (214) 792-7188 Office (972) 880-6882 Cell (800) 915-3747 Pager >>> "Todd C. Merrill" <tmerrill(a)mathworks.com> 09/06/00 10:14AM >>> We are considering moving our F740 and F760 toasters from quad 100-Mbit ethernet EtherChannel'ed on a Cisco 5500 switch to the gigabit NICs on a new Cisco switch, a 6509. We're doing this 'cause: 1. We need more ports. Period. 2. The 6509 has a higher density of ports and gig ports. 3. The gigabit NICs are supposedly much faster, and you can offload the checksum processing from the main CPU to the gigabit card. (We're not even close to saturating the quad link now; I'm just talking latencies. Plus, we beat the crap out of our toasters; if the CPU can do less overhead and more data serving, I want it.) Anybody have any experience with the 6509 and NetApp's gigabit cards? Just want to assuage our concerns before placing the PO's. Until next time... The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

1 0

RE: ESTALE
by Strange, Steve 06 Sep '00

06 Sep '00

Deletion-handling of open files in NFS V2 and V3 (such as it is) is handled at the NFS client. The NFS server isn't aware of which clients have a file open, or how many processes on those clients have a particular file open (I'm assuming no NFS locking here). If a process on NFS client "A" has a file open, then another process on that same client deletes the file, the NFS client sends a "RENAME" to the NFS server, instead of a "REMOVE", so that the file sticks around until that first process closes the file (at least this is the case for NFS clients with which I'm familiar). The file is renamed to ".nfsXXXX", or something of that ilk, but the NFS file handle remains the same, so the first process can continue to read/write/etc. However, if a process on a different NFS client, "B", deletes the file, client "B" has no way of knowing that the file is open by a process on client "A". So client "B" will go ahead and remove the file completely, resulting in ESTALE the next time the process on client "A" attemts an operation on the file. Do you have just one NFS client accessing the file in question? What NFS client are you using? Hope this chatter is of some use. Cheers, Steve > -----Original Message----- > From: Edward Hibbert [mailto:EH@dataconnection.com] > Sent: Wednesday, September 06, 2000 4:39 AM > To: toasters(a)mathworks.com > Subject: ESTALE > > > Does anyone know under precisely what circumstances NetApp > returns ESTALE? > > I have a file open in my application to which I have just > done a write; I > issue another write very shortly thereafter and I get ESTALE back. > > Now, I believed that ESTALE was returned when a file handle > was presented > where the file had really been deleted and the inode for the > file was reused > for a new file. But since my process has the file open, even > if it's been > deleted by some other process (which is possible), I don't > think I should > get ESTALE returned. > > So this means I don't understand what is going on. But > perhaps you do :-). > > > Edward Hibbert. >

1 0

NetApp 9gb FC/AL drives available for sale
by ScottUCE＠aol.com 06 Sep '00

06 Sep '00

A leasing company has SEVEN 9gb FC/AL fiber disk drives (NetApp Model X219F) available; NetApp no longer offers these drives. They are asking $4,500.00 for the seven drives, shelf/power supply and cabling. Please contact me if you have any interest. Scott Fischmann Union Computer Exchange, Inc. 6233 Idylwood Lane Minneapolis, MN 55436 (612) 935-7282 (612) 935-5056 - FAX www.unioncomputer.com

1 0

ESTALE
by Edward Hibbert 06 Sep '00

06 Sep '00

Does anyone know under precisely what circumstances NetApp returns ESTALE? I have a file open in my application to which I have just done a write; I issue another write very shortly thereafter and I get ESTALE back. Now, I believed that ESTALE was returned when a file handle was presented where the file had really been deleted and the inode for the file was reused for a new file. But since my process has the file open, even if it's been deleted by some other process (which is possible), I don't think I should get ESTALE returned. So this means I don't understand what is going on. But perhaps you do :-). Edward Hibbert.

1 0

RE: Budtool woes
by Clawson, Simon 05 Sep '00

05 Sep '00

Hi! Thanks for the info! Scary stuff this backup! I have just checked the logs to find that the backup ran for 32 hours this weekend! Anyway, How have you achived the spliting of your file system? I think this is going to cause us problems due to the rather unitelligent autoloader we use to drive the backup...any advise on this? Simon -----Original Message----- From: Marion Hakanson [mailto:hakanson@cse.ogi.edu] Sent: 01 September 2000 18:24 To: Clawson, Simon Cc: toasters(a)mathworks.com Subject: Re: Budtool woes > . . . > I am bacing up a single volume filer with nearly 200GB of data - my backup > is constanlty failing due to the process running out of time..anyone seen > this? Is there a way round it? Can I increse the allowable time? Can I split > the backup into several levels? > . . . Simon, I see that you've probably solved your timeout problem, but you've probably got another problem as well. I've just upgraded to bt-4.6.1a, and the Release Notes state that it does not support backups that get split across more than 3 tapes. I'll spare you the details right now, since you can go look at my original posting to "toasters" on this topic: http://teaparty.mathworks.com:1999/toasters/6612.html Apparently a large backup of this type will work fine, but you may not be able to do recoveries from it, under certain mysterious circumstances (which I've not yet experienced, thankfully). The workaround is to break up that single backup into backups of subdirectories of that large volume (you don't have to breakup the volume itself). Solaris ufsdump can do this, but doesn't support incremental (non-full) dumps of subdirectories; Fortunately (by the tests I've done here), NetApp's dump (both console/cmd-line and NDMP) can do both fulls and incrementals of subdirectories. I've since noticed that NetApp themselves recommend against backing up large volumes (>100GB) in a single "dump" run. Here's where: http://now.netapp.com/NOW/knowledge/docs/ontap/rel536r2/html/sag/dump7.htm Luckily for us, our large volume (185GB, currently) is broken up into about ten qtrees & a couple other directories. I think the 10-12 dumps actually complete slightly faster than the previous single large dump. BTW, how's it going in your search for a BudTool replacement? A PDC engineer told me that the new Legato Networker 6.0 NDMP support will only do backups to either a NetApp-attached library, or to another NDMP enabled system (and _not_ to a Networker media server). It doesn't support a split-library configuration at all (which is what we have our BudTool/NetApp setup doing). Because of that, they want to sell me Veritas NetBackup instead. I've got a few other leads in the works, and I'd be happy to compare notes on what you've found so far. Good luck and regards, -- Marion Hakanson <hakanson(a)cse.ogi.edu> CSE Computing Facilities

2 1

RE: Splitting large volumes
by Krause, Oliver 04 Sep '00

04 Sep '00

If you used the "-level 0" option when doing the initial transfer then subsequent incrementals do the expected: If you delete a file on the source and do a incremental it is also gone on the destination. Don't omit "-level 0" for doing the level 0 dump if you want this working that way. Oliver > -----Original Message----- > From: Cliff.Dobbs(a)arm.com [mailto:Cliff.Dobbs@arm.com] > Sent: Montag, 4. September 2000 17:12 > To: toasters(a)mathworks.com > Subject: Re: Splitting large volumes > > > > Folks, > > I can't seem to find any info on what ndmpcopy does when a > file is removed > from the source filer after a level 0 dump. > > Does it remove the said file from the destination filer ( as > per rdist -R) > or do you end up with loads of files which the users thought they had > deleted :-( > > Cheers > > > Cliff Dobbs Systems Administrator ARM Ltd > Tel: +44 1223 400430 Fax: +44 1223 400410 e-mail: Cliff.Dobbs(a)arm.com > > > > > > > The easiest solution, that also demands minimal downtime is > > using ndmpcopy/rsync altogether... > > > > This will work only if you have free volumes on the new machine... > > > > > > 1. Copy a baseline copy of the seperate parts of your current > > volume to the target volumes, using ndmpcopy/rsync/tar/whatever > > (ndmpcopy will be the fastest probably). > > This can be done while users are working, a few hours/days > > before the migration downtime is planned. > > 2. In something like a few hours before the downtime, use > > the utility "rsync" and/or ndmpcopy to copy incrementally > > the changes since the baseline. > > 3. DOWNTIME - while in downtime, just do a final syncing, again > > using ndmpcopy incremental/rsync, and change the > relevant settings: > > NIS maps, filer's /etc/exports, /etc/quotas... > > > > In theory, this is the way to go and is what we ended up > doing when we > copied a volume to a new volume about a couple weeks ago. We > did a level > 0 dump/restore with ndmpcopy while the filer was up and during the > downtime we picked up the changes with rsh filer dump | rsh > filer restore. > We didn't use rsync because we didn't want to lose any CIFS file > attributes. > > Let me warn you about some problems we ran into. We've submitted bug > reports where appropriate. > > 1) We are running 5.3.5R2P2 and there is a known bug in > incremental NDMP > where it fails to dump files that should be dumped because > NDMP dump only > looks at the mtime and not the mtime and the ctime. To work > around the > bug, which is only in NDMP dump, we used "rsh filer dump | rsh filer > restore". We ran into some serious problems where the > restore would stop > working and drop into an infinite loop. This would happen > often, but not > always. I'm talking to netapp about this one. > > 2) We discovered a bug where a level 0 subtree dump skips files dated > before 00:00:00 Jan 1, 1970 GMT, i.e., files with negative timestamps. > Don't ask me how they got there, they are user files and we > had over 500 > of them. This problem does not happen with a full volume dump, just a > subtree. So I suggest either doing a full volume dump or > running a find > to locate all such files and "touch" them to a time after 1970. > > 3) Very minor bug -- one of our users has the unix uid 65535, > which has > the bit pattern 0xffff which is -1 in a 16 bit signed int. After the > restore, this user's files were all owned by root instead of 65535. > Nearby uids both above and below worked correctly. > > 4) Our original filesystem was created under DOT 5.0.2 and > the filer was > upgraded at least twice since. We run a mixed NFS and CIFS > environment. > In some of the older versions of DOT were some bugs in the > WAFL directory > format. One bug allowed two different files to be created in the same > directory with the exact same name. Even though our version of DOT no > longer has this bug, our volume still had three such pairs of > files on it. > The full dump/restore had no problems with these files, but the > incremental restore -r could not cope and failed without restoring > anything. If you can find these file pairs the fix is simple. Just > rename one of the files. You have no control over which one > of the two > the filer picks, but afterward, you can see both files. This is a > particularly insidious problem because any incremental dump > of a volume > with duplicate filenames CANNOT BE RESTORED with "restore > -r". You will > be forced to use "restore -x" which is less than desirable. > Dump does not > issue any errors, either. It's only when you restore that > you discover > the problem. > > You can locate duplicate files like this: > > find dir -print | sort > out1 > sort -u out1 > out2 > diff out1 out2 > > MORAL: Before a big volume copy, do some dry runs to be sure > you won't > run into problems during your downtime. Be sure to test both the full > dump/restore and incremental dump/restore. We discovered > many of these > problems during the two weeks leading up to our downtime. > Even still, we > hit a couple snags during the downtime that cost us at least 2 hours. > > One final tip: Before running restore -r on an incremental dump, > be sure to save a copy of the restore_symboltable file since > restore -r modifies it. If the restore modifies the file and then > fails, you can't rerun the "restore -r" unless you put back the > original file. Even then you may have problems, and will need to > use "restore -x". > > > Steve Losen scl(a)virginia.edu phone: 804-924-0640 > > University of Virginia ITC Unix Support > > >

1 0

Re: Splitting large volumes
by Cliff.Dobbs＠arm.com 04 Sep '00

04 Sep '00

Folks, I can't seem to find any info on what ndmpcopy does when a file is removed from the source filer after a level 0 dump. Does it remove the said file from the destination filer ( as per rdist -R) or do you end up with loads of files which the users thought they had deleted :-( Cheers Cliff Dobbs Systems Administrator ARM Ltd Tel: +44 1223 400430 Fax: +44 1223 400410 e-mail: Cliff.Dobbs(a)arm.com > The easiest solution, that also demands minimal downtime is > using ndmpcopy/rsync altogether... > > This will work only if you have free volumes on the new machine... > > > 1. Copy a baseline copy of the seperate parts of your current > volume to the target volumes, using ndmpcopy/rsync/tar/whatever > (ndmpcopy will be the fastest probably). > This can be done while users are working, a few hours/days > before the migration downtime is planned. > 2. In something like a few hours before the downtime, use > the utility "rsync" and/or ndmpcopy to copy incrementally > the changes since the baseline. > 3. DOWNTIME - while in downtime, just do a final syncing, again > using ndmpcopy incremental/rsync, and change the relevant settings: > NIS maps, filer's /etc/exports, /etc/quotas... > In theory, this is the way to go and is what we ended up doing when we copied a volume to a new volume about a couple weeks ago. We did a level 0 dump/restore with ndmpcopy while the filer was up and during the downtime we picked up the changes with rsh filer dump | rsh filer restore. We didn't use rsync because we didn't want to lose any CIFS file attributes. Let me warn you about some problems we ran into. We've submitted bug reports where appropriate. 1) We are running 5.3.5R2P2 and there is a known bug in incremental NDMP where it fails to dump files that should be dumped because NDMP dump only looks at the mtime and not the mtime and the ctime. To work around the bug, which is only in NDMP dump, we used "rsh filer dump | rsh filer restore". We ran into some serious problems where the restore would stop working and drop into an infinite loop. This would happen often, but not always. I'm talking to netapp about this one. 2) We discovered a bug where a level 0 subtree dump skips files dated before 00:00:00 Jan 1, 1970 GMT, i.e., files with negative timestamps. Don't ask me how they got there, they are user files and we had over 500 of them. This problem does not happen with a full volume dump, just a subtree. So I suggest either doing a full volume dump or running a find to locate all such files and "touch" them to a time after 1970. 3) Very minor bug -- one of our users has the unix uid 65535, which has the bit pattern 0xffff which is -1 in a 16 bit signed int. After the restore, this user's files were all owned by root instead of 65535. Nearby uids both above and below worked correctly. 4) Our original filesystem was created under DOT 5.0.2 and the filer was upgraded at least twice since. We run a mixed NFS and CIFS environment. In some of the older versions of DOT were some bugs in the WAFL directory format. One bug allowed two different files to be created in the same directory with the exact same name. Even though our version of DOT no longer has this bug, our volume still had three such pairs of files on it. The full dump/restore had no problems with these files, but the incremental restore -r could not cope and failed without restoring anything. If you can find these file pairs the fix is simple. Just rename one of the files. You have no control over which one of the two the filer picks, but afterward, you can see both files. This is a particularly insidious problem because any incremental dump of a volume with duplicate filenames CANNOT BE RESTORED with "restore -r". You will be forced to use "restore -x" which is less than desirable. Dump does not issue any errors, either. It's only when you restore that you discover the problem. You can locate duplicate files like this: find dir -print | sort > out1 sort -u out1 > out2 diff out1 out2 MORAL: Before a big volume copy, do some dry runs to be sure you won't run into problems during your downtime. Be sure to test both the full dump/restore and incremental dump/restore. We discovered many of these problems during the two weeks leading up to our downtime. Even still, we hit a couple snags during the downtime that cost us at least 2 hours. One final tip: Before running restore -r on an incremental dump, be sure to save a copy of the restore_symboltable file since restore -r modifies it. If the restore modifies the file and then fails, you can't rerun the "restore -r" unless you put back the original file. Even then you may have problems, and will need to use "restore -x". Steve Losen scl(a)virginia.edu phone: 804-924-0640 University of Virginia ITC Unix Support

1 0

migrating from nfs to cifs
by neil lehrer 01 Sep '00

01 Sep '00

hi, we are migrating from our sun servers to filers by doing an nfs cp -p. our user environment is primarily nt wkstations and we want to eventually convert to cifs access and to an ntfs security model. does anyone have any suggestions on how to automatically create the appropriate acls for both home and shared directories[including group aces]? thanks. -- regards +++++++++++++++++++++++++++++++++++++++++++++++++ + Neil Lehrer + + United States International Broadcasting Bureau + System Development Division + + voice 202 619-2524 + fax 202 619-3576 + nlehrer(a)ibb.gov + + " is this crisis an opportunity or just + another grab the fire extinguisher moment?" + +++++++++++++++++++++++++++++++++++++++++++++++++

1 0

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