toasters

toasters@lists.teaparty.net

13531 discussions

NDMP
by grey jolly 24 Sep '02

24 Sep '02

Most of the folks we deal with have a lot of problems with NDMP. It would certainly be helpful if you could provide the list with some of your tricks to make NDMP work consistently. --- Mike Ball <MBall(a)datalink.com> wrote: > Go with NDMP on Legato. As others stated, NDMP and > Legato work very well. I > have setup a few environments with Legato Networker > and NDMP via Netapp. The > nice thing about NDMP is you directly dump off the > Netapp to tape which is > very quick. It will push LTO and SDLT tape drives to > the full performance > capabilities. In addition, the CPU overhead > required to do a NDMP backup vs > over NFS is much lower on the Netapp. Keep in mind > though that the tape > drives dedicated to the Netapp for NDMP can not be > shared by other non > Netapp Legato clients/storage nodes/servers (can be > shared by other Netapps > though). > Mike > > > -----Original Message----- > From: devnull(a)adc.idt.com > [mailto:devnull@adc.idt.com] > Sent: Thursday, September 19, 2002 9:57 AM > To: Toasters (E-mail) > Subject: Legato Backups. > > > Dear Toasters, > > I was wondering if any of you guys were using Legato > for backing up your > NetApps. I currently have 2 filers that i am backing > up to a Legato server > running Solaris 2.8 over NFS. I mount the NetApp > volumes onto the legato > server and then backup those mount points. > > I am not sure this is the best thing to do in terms > of performance. > > Is there an alternate, easier solution. > > Thanks, > > /dev/null > > devnull(a)adc.idt.com __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com

1 0

RE: Sun Solaris 8 optimal performance with F880
by Art Hebert 24 Sep '02

24 Sep '02

Deepak -- As I haven't been able to come up with any performance numbers for the 700, 800, 900 series, can you let us know how your oracle db performs on the 880? We are currently using an F760 with a gig network, tcp, etc and we are seeing a lot of I/O waits pertaining to Oracle temp and redos. I'd be interested in if you also see a bottleneck in that area. Thanks art hebert -----Original Message----- From: Deepak Soneji [mailto:sonejideepak@hotmail.com] Sent: Monday, September 23, 2002 8:08 PM To: Mike Sphar; toasters(a)mathworks.com Subject: Re: Sun Solaris 8 optimal performance with F880 I agree with you. Mostly I am going to use TCP and as you said about dropped packets, we are working with Cisco to identify the problem. At this moment, I am not confident of using UDP. We will have several Oracle databases running on the filer and I dont want to take any chances to corrupt the data. Thanks /Deepak ----- Original Message ----- From: "Mike Sphar" <mike.sphar(a)Remedy.COM> To: <toasters(a)mathworks.com> Sent: Monday, September 23, 2002 12:30 PM Subject: RE: Sun Solaris 8 optimal performance with F880 > There is of course some additional overhead associated with the TCP protocol > though, which is why it really depends on the reliability of your network > and clients to determine which of the two protocols is ideal for your > environment. > > Certainly in the situation being described, where a client is dropping > packets, TCP will likely be the better choice. (Though I'd also want to try > to address the dropped packet problem as well if possible.) > > -- > Mike Sphar - Sr Systems Administrator - Remedy Corporation > > -----Original Message----- > From: Michael Salmon [mailto:Michael.Salmon@uab.ericsson.se] > Sent: Monday, September 23, 2002 3:59 AM > To: toasters(a)mathworks.com > Subject: Re: Sun Solaris 8 optimal performance with F880 > > > > On Thursday, September 19, 2002 11:04:35 PM -0700 Deepak Soneji > <sonejideepak(a)hotmail.com> wrote: > +------ > | Brian/Tim > | > | Great ! READS are greatly improved upto 12-15 mbps after changing xfersize > | to 8k. > | Any idea about what magic numbers for read/write I should try to achieve > | while tuning ? > | > | Another question, why TCP ? > +-----X8 > > UDP has no retry mechanism so if you loose any of the 22 packets involved > in a 32k transfer then you need to start again. A powerful server sending > to a weaker client is a good way to ensure that packets are lost. TCP has > mechanism to ensure that packets are not lost and hence works better when > the packet recipient is the weaker partner. > > /Michael > -- > This space intentionally left non-blank. >

1 0

Why do different backup tools copy different amounts of data?
by Spencer Kantor 24 Sep '02

24 Sep '02

In both preparing for a data migration between filers as well as assessing a new backup program we've been comparing different backup tools. We're trying to rectify why different backup tools report wide variations in the amount of data they copy. Here's the setup. One F720 filer with two FC9 shelves attached. One volume (vol0) of approx. 180GB with 23 qtrees. Nfs-only, no CIFS. The volume report from FilerView reports there is 47GB of the 180GB total available. From the Unix admin host a df reports vol0 is 180GB and 140GB is used. The df also reports .snapshot is 33.3GB with 10GB used. Question 1: Why the difference in used and available space between the FilerView report and df? We employed three different backup tools to backup the entire volue; ndmpcopy (run from a Unix host, not the built-in Ontap verion), Omniback and Commvault Galaxy. Ndmpcopy was set as a filer to filer copy whereas Omniback and Galaxy backed up to tape. The Omniback and Galaxy backup policy was defined to backup the nightly.0 snapshot of the filer. After each approach was run ndmpcopy reported it copied approximately 125GB of data, Omniback reported copying approximately 130GB of data and Galaxy reported copying 115GB of data. Question 2: Why do different backup methodologies report such a wide disparity in the amount of data copied? Has anyone encountered this before and can provide a rational explanation. Thanks. Spencer Kantor Telcordia Technologies

1 0

RE: Sun Solaris 8 optimal performance with F880
by Mike Sphar 24 Sep '02

24 Sep '02

There is of course some additional overhead associated with the TCP protocol though, which is why it really depends on the reliability of your network and clients to determine which of the two protocols is ideal for your environment. Certainly in the situation being described, where a client is dropping packets, TCP will likely be the better choice. (Though I'd also want to try to address the dropped packet problem as well if possible.) -- Mike Sphar - Sr Systems Administrator - Remedy Corporation -----Original Message----- From: Michael Salmon [mailto:Michael.Salmon@uab.ericsson.se] Sent: Monday, September 23, 2002 3:59 AM To: toasters(a)mathworks.com Subject: Re: Sun Solaris 8 optimal performance with F880 On Thursday, September 19, 2002 11:04:35 PM -0700 Deepak Soneji <sonejideepak(a)hotmail.com> wrote: +------ | Brian/Tim | | Great ! READS are greatly improved upto 12-15 mbps after changing xfersize | to 8k. | Any idea about what magic numbers for read/write I should try to achieve | while tuning ? | | Another question, why TCP ? +-----X8 UDP has no retry mechanism so if you loose any of the 22 packets involved in a 32k transfer then you need to start again. A powerful server sending to a weaker client is a good way to ensure that packets are lost. TCP has mechanism to ensure that packets are not lost and hence works better when the packet recipient is the weaker partner. /Michael -- This space intentionally left non-blank.

2 1

23 Sep '02

1 0

Sun Solaris 8 optimal performance with F880
by Deepak Soneji 23 Sep '02

23 Sep '02

Toasters Configuration : Sun E6000 server running Solaris 8 latest patch level Filer : F880 Cisco Switch 6509(Flowcontrol turned on) We have recently bought 2- F880 filers and we are in the implementation phases. The weird performance results we are getting with following system settings and mount parameters. The output from "sysstat 1" on filer, shows writes 35 MBPS but reads just very slow or not even generate any traffic. Here are the settings 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 ndd -set /dev/ge instance 1 ndd -set /dev/ge adv_pauseTX 1 ndd -set /dev/ge adv_pauseRX 1 ndd -set /dev/ge adv_1000autoneg_cap 0 ndd -set /dev/ge adv_1000fdx_cap 1 set sq_max_size = 30 set nstrpush = 90 set ncsize 8000 set nfs:nfs3_max_threads = 24 set nfs:nfs3_nra =10 set nfs:nfs_max_threads = 24 set nfs:nfs_nra = 10 Mount file system : mount -o rw,bg,hard,intr,proto=udp,vers=3,rsize=32768,wsize=32768 filer01:/vol/test /test Test method dd if=/dev/zero of=/test/foo bs=32k count=50000 I have tried to search some documents on now site for the optimal performance but I could not find any optimal numbers which I should try to achieve. Why reads are chocking up ? anyone has any proven configuration which works optimally ? Thanks in advance for your inputs and thoughts. Regards -Deepak Soneji Flextronics International

3 3

RE: Legato Backups.
by Peter Bryant 23 Sep '02

23 Sep '02

*** Before acting on this e-mail or opening any attachment you are advised to read the disclaimer at the end of this e-mail *** Technically speaking (as we found out and are correcting) this is an unsupported Legato configuration. They'll not help you out if there is an issue. I consider this to be a marketing ploy as much as anything to sell NDMP licences. Legato's position is that they do not support ANY backup of NFS attached mounts (whether filer or another server). Practically speaking it works, but sometimes the load on the backup servers is just too great and a few things "pop loose" for the users. Peter -----Original Message----- From: devnull(a)adc.idt.com [mailto:devnull@adc.idt.com] Sent: 19 September 2002 14:57 To: Toasters (E-mail) Subject: Legato Backups. Dear Toasters, I was wondering if any of you guys were using Legato for backing up your NetApps. I currently have 2 filers that i am backing up to a Legato server running Solaris 2.8 over NFS. I mount the NetApp volumes onto the legato server and then backup those mount points. I am not sure this is the best thing to do in terms of performance. Is there an alternate, easier solution. Thanks, /dev/null devnull(a)adc.idt.com ******************************* Disclaimer ***************************** Confidentiality: This e-mail and any attachments are intended for the addressee(s) only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this e-mail and highlight the error. Viruses: Although we have taken steps to ensure that this e-mail and attachments are free from any virus, we advise that in keeping with good practice the recipient should ensure they are actually virus free. ********************** http://www.burallplastec.com ********************

3 2

SNMP Behaviour
by Ben Rockwood 22 Sep '02

22 Sep '02

Hello Toasterites, I've come across some odd behaviour in the SNMP reporting of OnTap. I have a script that uses Net-SNMP to check for failures on our Filers. This came about due to disks slipping offline silently rather than failing. The script does 3 checks: the failed count OID, the number of spares OID, and an overall comparison of total disks, spare disks, and active disks. Every saturday night (when the INFO report mail is sent out) I get a run of my script generating errors. To isolate the problem I put some debugging into the script and found that I get back the following numbers for one of my Filers: Active Disks: 50 Spare Disks: 2 Total Disks: 56 Some how 4 disks disappeared from the SNMP reporting for that run... and it's gotta be the parity disks. The Filers run great, no problems there, it's just a simple reporting issue. So the question: why? It's not a big issue, but it'd be nice to not get paged every saturday night for no reason, and I'd rather not have to work around this too in my script (which was written to work around a previous reporting issue, etc, etc). Oh, and I'm running OnTap 6.1R1, on several 760 and 840s. Ben Rockwood UNIX Systems Admin Homestead.com

1 0

RE: Sun Solaris 8 optimal performance with F880
by Art Hebert 20 Sep '02

20 Sep '02

I thought the 880's were supposed to get around 60MB writes. Seems that 12-15 would be worse than an F760. Is there any published numbers for read or write performance for the various models? I think the licensing forbids Netapp users from discussing performance numbers for some reason, am I mistaken on this? art -----Original Message----- From: Deepak Soneji [mailto:sonejideepak@hotmail.com] Sent: Thursday, September 19, 2002 11:05 PM To: Brian Long Cc: toasters(a)mathworks.com Subject: Re: Sun Solaris 8 optimal performance with F880 Brian/Tim Great ! READS are greatly improved upto 12-15 mbps after changing xfersize to 8k. Any idea about what magic numbers for read/write I should try to achieve while tuning ? Another question, why TCP ? Thanks -Deepak ----- Original Message ----- From: "Brian Long" <brilong(a)cisco.com> To: "Deepak Soneji" <sonejideepak(a)hotmail.com> Cc: <toasters(a)mathworks.com> Sent: Thursday, September 19, 2002 6:47 PM Subject: Re: Sun Solaris 8 optimal performance with F880 > UDP and 32K transfers don't mix. Reduce to 8K transfers (nfs.udp.xfersize > 8192) or change to TCP, the preferred method in which to use NFS. > > /Brian/ > > > Toasters > > > > Configuration : Sun E6000 server running Solaris 8 latest patch level > > Filer : F880 > > Cisco Switch 6509(Flowcontrol turned on) > > > > > > We have recently bought 2- F880 filers and we are in the implementation phases. The weird > > performance results we are getting with following system settings and mount parameters. > > The output from "sysstat 1" on filer, shows writes 35 MBPS but reads just very slow > > or not even generate any traffic. Here are the settings > > > > 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 > > ndd -set /dev/ge instance 1 > > ndd -set /dev/ge adv_pauseTX 1 > > ndd -set /dev/ge adv_pauseRX 1 > > ndd -set /dev/ge adv_1000autoneg_cap 0 > > ndd -set /dev/ge adv_1000fdx_cap 1 > > > > set sq_max_size = 30 > > set nstrpush = 90 > > set ncsize 8000 > > set nfs:nfs3_max_threads = 24 > > set nfs:nfs3_nra =10 > > set nfs:nfs_max_threads = 24 > > set nfs:nfs_nra = 10 > > > > Mount file system : > > > > mount -o rw,bg,hard,intr,proto=udp,vers=3,rsize=32768,wsize=32768 filer01:/vol/test /test > > > > Test method > > > > dd if=/dev/zero of=/test/foo bs=32k count=50000 > > > > > > I have tried to search some documents on now site for the optimal performance but I could not > > find any optimal numbers which I should try to achieve. > > Why reads are chocking up ? > > anyone has any proven configuration which works optimally ? > > > > Thanks in advance for your inputs and thoughts. > > > > Regards > > > > -Deepak Soneji > > Flextronics International > > > > > > -- > Brian Long | | | > Americas IT Hosting Sys Admin | .|||. .|||. > Phone: (919) 392-7363 | ..:|||||||:...:|||||||:.. > Pager: (888) 651-2015 | C i s c o S y s t e m s >

1 0

Moving data from NT to NetApp painfully slow
by Friedrich, Bernhard 20 Sep '02

20 Sep '02

Hi Toasters, we're in the process of consolidating NT file services on a NetApp Filer. We have an F810 where we want to store all our user's data which is now spread across multiple servers, some of which are close to being maxed out. We now have the problem of moving all the data while we're still servicing our users - we're on 24/7 here. We found that copying the data to the filer is painfully slow; we're suspecting that NT ACLs might be the culprit. We've tried robocopy, secure copy and xxcopy to no avail - moving a small part of the total data took 15 hours. Anybody out there willing to share their experiences with moving several hundreds of GB across the network? We need to keep NT permissions, obviously. On the mailing list I saw references to Fastlane and Aelita's SCW - any experience with those or other 3rd party products? Greetings and thanks in advance Bernhard -- Bernhard Friedrich ZIM Uniklinikum Heidelberg Unix/NT administration

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