toasters August 1999

toasters@lists.teaparty.net

104 participants
129 discussions

RE: what's a good NFS write speed in MB/sec?
by Mohler, Jeff 05 Aug '99

05 Aug '99

Form an SGI Origin 2000 to Netapp F740, over 100Mbps Ethernet, I get 10MBytes/s consistent data transfer rate over nfs. However this is no good benchmark as the bottleneck here is ethernet speed and not filer. However if you can connect 3-4 NIC and get same performance an all four interfaces at the same time, this might suggest a very good performance. --- On a Sun U250, 2x300mhz, I can get about 80-90Mbits/sec if nothing is going on with the sun box. Multiple mounts, with multiple tests (into a switched, etherchannel environment to the F760) results in slower performance from the Sun. My next round of news servers in our cluster will be on non-PCI based hardware.

1 0

Re: what's a good NFS write speed in MB/sec?
by nathan＠dnase.hpw.pri.bms.com 05 Aug '99

05 Aug '99

My numbers from sgi origin2000 to sgi origin2000, with no router hops, came through at around 3Mbyte/sec over 100Mbit network and nfs. This was a for a transfer of a single 1GByte file. Interested in filer specs when communicating with origins, and also with gigabit ethernet hardware (presumably the origins can deal with the overhead?). nathan Matt Harrington <matt(a)ucsd.EDU> writes: > I'm evaluating a NAS filer similar to the ones sold by NetApp and Auspex. > This particular model is made by Nitech in Irvine, CA. These NFS vendors > speak about benchmarks in ops/sec. It's more intuitive for me to think of > benchmarks in terms of MB/sec throughputs for a large file write or read. > > My quick-and-dirty tests show that I can write at 1.8 MByte/sec over a > 100Mbit network using NFS v3. I can FTP at about 7 MByte/sec. > > My question is: do these numbers seem reasonable? If not, what aspects of > NFS should I tweak? > > ---matt > > > p.s. methods: > > to make a 100MB file: > dd if=/dev/zero of=/tmp/bigfile bs=1024 count=102400 > > time cp /tmp/bigfile /home/bigfile > > (where /home is the NFS server). > > -- N a t h a n O . S i e m e r s Bioinformatics Division of Applied Genomics Bristol-Myers Squibb Pharmaceutical Research Institute Hopewell Building 3B, P.O. Box 5400, Princeton, NJ 08543-5400 609 818-6568 siemersn(a)bms.com

2 1

Re: what's a good NFS write speed in MB/sec?
by Richard L. Rhodes 05 Aug '99

05 Aug '99

> Matt Harrington <matt(a)ucsd.EDU> writes: > > > I'm evaluating a NAS filer similar to the ones sold by NetApp and Auspex. > > This particular model is made by Nitech in Irvine, CA. These NFS vendors > > speak about benchmarks in ops/sec. It's more intuitive for me to think of > > benchmarks in terms of MB/sec throughputs for a large file write or read. > > > > My quick-and-dirty tests show that I can write at 1.8 MByte/sec over a > > 100Mbit network using NFS v3. I can FTP at about 7 MByte/sec. > > > > My question is: do these numbers seem reasonable? If not, what aspects of > > NFS should I tweak? > > > > ---matt THis is an interesting problem for NetApp. I purchased several NetApps for use on Oracle Servers for the Oracle DB. In evaluating all the info I too had problems relating nfs ops/sec to a disk subsystem throughput. NetApp wanted us to purchase a system on 30 day trial to see if it would do what I needed. I refused and told them that without an up front proof of concept there was no discussion of a trial purchase. So, our local tech rep brought a F6xx model (I forget) that we played with for half a day. With this box and 100BaseT connections to our RS/6k systems I got sequential writes of around 8-9mb/sec. This was much faster than one raid system I have that can only handle sequential writes at around 5mb/second, but not anywhere near the speed of a Hitachi Raid system I tested that could accept sequential writes at 25mb/sec (it had other problem that made it unusable). So, I've now got 2 F740 systems I'm looking at and so far like a lot. In using a single gigabit connection to a F740 I can easily get sequential writes of around 15mb/sec. At this point the Netapp is running CPU utilization of around +80% utilization. I've seen peaks of close to 18mb/s where the cpu utilization is pegged on 100%. What I've also been doing is running some standard benchmark tests against the netapp. While this provides very rough info, it's better than nfs ops/sec. Below are some results from a program called stkio ( http://www.stortek.com/StorageTek/software/freeware ): ----------------------------------------------------------- -- 1 process ---------------------------------------------- ----------------------------------------------------------- STKIO Version 1.0 Copyright 1997 StorageTek Corporation Run for 1 loops to 1 files/volumes number of processes is 1 IO type is seq writes file size is 2000 MB Initial transfer length = 4096 bytes Ending Transfer length will be 32768 bytes I/O processes terminate after 2097152000 bytes are transferred Statistics capture enabled 16.53 MB per second for 4KB (4232 IO's per second). Slowest IO 42429.75ms, Quickest IO 0.07ms, Mean 0.22ms 16.52 MB per second for 8KB (2114 IO's per second). Slowest IO 49188.87ms, Quickest IO 0.12ms, Mean 0.46ms 13.53 MB per second for 16KB (865 IO's per second). Slowest IO 39593.59ms, Quickest IO 0.24ms, Mean 1.13ms 17.48 MB per second for 32KB (559 IO's per second). Slowest IO 47646.34ms, Quickest IO 0.48ms, Mean 1.76ms ----------------------------------------------------------- STKIO Version 1.0 Copyright 1997 StorageTek Corporation Run for 1 loops to 1 files/volumes number of processes is 1 IO type is seq reads file size is 2000 MB Initial transfer length = 4096 bytes Ending Transfer length will be 32768 bytes I/O processes terminate after 2097152000 bytes are transferred Statistics capture enabled 15.97 MB per second for 4KB (4087 IO's per second). Slowest IO 2316.58ms, Quickest IO 0.03ms, Mean 0.23ms 18.54 MB per second for 8KB (2373 IO's per second). Slowest IO 370.41ms, Quickest IO 0.05ms, Mean 0.40ms 16.96 MB per second for 16KB (1085 IO's per second). Slowest IO 1754.96ms, Quickest IO 0.11ms, Mean 0.90ms 16.68 MB per second for 32KB (533 IO's per second). Slowest IO 416.97ms, Quickest IO 0.28ms, Mean 1.84ms ----------------------------------------------------------- STKIO Version 1.0 Copyright 1997 StorageTek Corporation Run for 1 loops to 1 files/volumes number of processes is 1 IO type is seq reads and writes file size is 2000 MB Initial transfer length = 4096 bytes Ending Transfer length will be 32768 bytes I/O processes terminate after 2097152000 bytes are transferred Statistics capture enabled 14.10 MB per second for 4KB (3609 IO's per second). Slowest IO 30118.43ms, Quickest IO 0.07ms, Mean 0.26ms 13.60 MB per second for 8KB (1740 IO's per second). Slowest IO 41456.73ms, Quickest IO 0.15ms, Mean 0.56ms 6.21 MB per second for 16KB (397 IO's per second). Slowest IO 2302.37ms, Quickest IO 0.42ms, Mean 2.49ms 6.99 MB per second for 32KB (223 IO's per second). Slowest IO 2177.81ms, Quickest IO 0.91ms, Mean 4.42ms ----------------------------------------------------------- STKIO Version 1.0 Copyright 1997 StorageTek Corporation Run for 1 loops to 1 files/volumes number of processes is 1 IO type is random writes file size is 2000 MB Initial transfer length = 4096 bytes Ending Transfer length will be 32768 bytes I/O processes terminate after 2097152000 bytes are transferred Statistics capture enabled 1.60 MB per second for 4KB (410 IO's per second). Slowest IO 38207.61ms, Quickest IO 0.03ms, Mean 2.42ms 4.34 MB per second for 8KB (554 IO's per second). Slowest IO 32236.26ms, Quickest IO 0.05ms, Mean 1.79ms 8.53 MB per second for 16KB (546 IO's per second). Slowest IO 39446.70ms, Quickest IO 0.11ms, Mean 1.82ms 11.47 MB per second for 32KB (367 IO's per second). Slowest IO 49895.58ms, Quickest IO 0.21ms, Mean 2.71ms ---------------------------------------------------------- STKIO Version 1.0 Copyright 1997 StorageTek Corporation Run for 1 loops to 1 files/volumes number of processes is 1 IO type is random reads file size is 2000 MB Initial transfer length = 4096 bytes Ending Transfer length will be 32768 bytes I/O processes terminate after 2097152000 bytes are transferred Statistics capture enabled 2.26 MB per second for 4KB (579 IO's per second). Slowest IO 635.95ms, Quickest IO 0.03ms, Mean 1.71ms 3.25 MB per second for 8KB (416 IO's per second). Slowest IO 553.14ms, Quickest IO 0.04ms, Mean 2.39ms 4.45 MB per second for 16KB (284 IO's per second). Slowest IO 545.42ms, Quickest IO 0.11ms, Mean 3.49ms 5.86 MB per second for 32KB (187 IO's per second). Slowest IO 533.81ms, Quickest IO 0.21ms, Mean 5.31ms ----------------------------------------------------------- STKIO Version 1.0 Copyright 1997 StorageTek Corporation Run for 1 loops to 1 files/volumes number of processes is 1 IO type is random reads and writes file size is 2000 MB Initial transfer length = 4096 bytes Ending Transfer length will be 32768 bytes I/O processes terminate after 2097152000 bytes are transferred Statistics capture enabled 1.55 MB per second for 4KB (397 IO's per second). Slowest IO 17135.13ms, Quickest IO 0.05ms, Mean 2.50ms 1.33 MB per second for 8KB (170 IO's per second). Slowest IO 17548.93ms, Quickest IO 0.10ms, Mean 5.84ms 1.47 MB per second for 16KB (93 IO's per second). Slowest IO 20197.14ms, Quickest IO 0.23ms, Mean 10.62ms 3.81 MB per second for 32KB (121 IO's per second). Slowest IO 24408.55ms, Quickest IO 0.47ms, Mean 8.18ms ----------------------------------------------------------- = 2 processes =============================================== ----------------------------------------------------------- STKIO Version 1.0 Copyright 1997 StorageTek Corporation Run for 1 loops to 1 files/volumes number of processes is 2 IO type is seq writes file size is 2000 MB Initial transfer length = 4096 bytes Ending Transfer length will be 32768 bytes I/O processes terminate after 2097152000 bytes are transferred Statistics capture enabled 14.07 MB per second for 4KB (3602 IO's per second). Slowest IO 3640.43ms, Quickest IO 0.04ms, Mean 0.54ms 14.08 MB per second for 8KB (1802 IO's per second). Slowest IO 6971.74ms, Quickest IO 0.06ms, Mean 1.09ms 14.32 MB per second for 16KB (916 IO's per second). Slowest IO 7378.41ms, Quickest IO 0.24ms, Mean 2.16ms 15.34 MB per second for 32KB (490 IO's per second). Slowest IO 14434.84ms, Quickest IO 0.45ms, Mean 4.04ms ----------------------------------------------------------- STKIO Version 1.0 Copyright 1997 StorageTek Corporation Run for 1 loops to 1 files/volumes number of processes is 2 IO type is seq reads file size is 2000 MB Initial transfer length = 4096 bytes Ending Transfer length will be 32768 bytes I/O processes terminate after 2097152000 bytes are transferred Statistics capture enabled 13.73 MB per second for 4KB (3519 IO's per second). Slowest IO 377.84ms, Quickest IO 0.03ms, Mean 0.55ms 17.47 MB per second for 8KB (2237 IO's per second). Slowest IO 447.69ms, Quickest IO 0.04ms, Mean 0.87ms 14.29 MB per second for 16KB (915 IO's per second). Slowest IO 451.40ms, Quickest IO 0.10ms, Mean 2.15ms 14.06 MB per second for 32KB (450 IO's per second). Slowest IO 418.53ms, Quickest IO 0.21ms, Mean 4.40ms ----------------------------------------------------------- STKIO Version 1.0 Copyright 1997 StorageTek Corporation Run for 1 loops to 1 files/volumes number of processes is 2 IO type is seq reads and writes file size is 2000 MB Initial transfer length = 4096 bytes Ending Transfer length will be 32768 bytes I/O processes terminate after 2097152000 bytes are transferred Statistics capture enabled 2.00 MB per second for 4KB (512 IO's per second). Slowest IO 1886.46ms, Quickest IO 0.07ms, Mean 3.88ms 2.93 MB per second for 8KB (375 IO's per second). Slowest IO 2520.66ms, Quickest IO 0.13ms, Mean 5.29ms 5.03 MB per second for 16KB (321 IO's per second). Slowest IO 353.10ms, Quickest IO 0.25ms, Mean 6.17ms 5.55 MB per second for 32KB (177 IO's per second). Slowest IO 1252.26ms, Quickest IO 0.59ms, Mean 11.21ms ----------------------------------------------------------- STKIO Version 1.0 Copyright 1997 StorageTek Corporation Run for 1 loops to 1 files/volumes number of processes is 2 IO type is random writes file size is 2000 MB Initial transfer length = 4096 bytes Ending Transfer length will be 32768 bytes I/O processes terminate after 2097152000 bytes are transferred Statistics capture enabled 1.65 MB per second for 4KB (422 IO's per second). Slowest IO 27679.15ms, Quickest IO 0.05ms, Mean 4.72ms 4.54 MB per second for 8KB (581 IO's per second). Slowest IO 32073.85ms, Quickest IO 0.09ms, Mean 3.42ms 8.55 MB per second for 16KB (547 IO's per second). Slowest IO 37631.32ms, Quickest IO 0.16ms, Mean 3.64ms 11.54 MB per second for 32KB (369 IO's per second). Slowest IO 48069.40ms, Quickest IO 0.33ms, Mean 5.40ms ---------------------------------------------------------- STKIO Version 1.0 Copyright 1997 StorageTek Corporation Run for 1 loops to 1 files/volumes number of processes is 2 IO type is random reads file size is 2000 MB Initial transfer length = 4096 bytes Ending Transfer length will be 32768 bytes I/O processes terminate after 2097152000 bytes are transferred Statistics capture enabled 5.81 MB per second for 4KB (1488 IO's per second). Slowest IO 648.85ms, Quickest IO 0.03ms, Mean 1.33ms 6.98 MB per second for 8KB (894 IO's per second). Slowest IO 1760.59ms, Quickest IO 0.05ms, Mean 2.22ms 8.78 MB per second for 16KB (561 IO's per second). Slowest IO 610.85ms, Quickest IO 0.10ms, Mean 3.54ms 11.62 MB per second for 32KB (372 IO's per second). Slowest IO 609.94ms, Quickest IO 0.22ms, Mean 5.35ms ----------------------------------------------------------- STKIO Version 1.0 Copyright 1997 StorageTek Corporation Run for 1 loops to 1 files/volumes number of processes is 2 IO type is random reads and writes file size is 2000 MB Initial transfer length = 4096 bytes Ending Transfer length will be 32768 bytes I/O processes terminate after 2097152000 bytes are transferred Statistics capture enabled ---------------------------------------------------------------------- Richard L. Rhodes e: rhodesr(a)firstenergycorp.com Ohio Edison Co. p: 330-384-4904 f: 330-384-2514

1 0

Re: NetApp/NDMP
by sirbruce＠ix.netcom.com 05 Aug '99

05 Aug '99

On 08/04/99 15:27:17 you wrote: > NDMP is the strategic direction for backup at > Network Appliance. We see NDMP as a winner for Network > Attached Storage (NAS) vendors and ultimately we > think this could also be very prevalent in Storage > Area Network (SAN) environments too. When Netapp has a hybrid NAS/SAN solution, I would expect straight "local" backup to a tape device on the SAN to be an option, via traditional dump, without NDMP involved. Bruce

1 0

NetApp/NDMP
by Marchi, Michael 05 Aug '99

05 Aug '99

Bruce, NDMP is the strategic direction for backup at Network Appliance. We see NDMP as a winner for Network Attached Storage (NAS) vendors and ultimately we think this could also be very prevalent in Storage Area Network (SAN) environments too. There is definite momentum building for the use of NDMP. Back-up solutions for NetApp which use NDMP are now offered from four large vendors and we see third party support for additional solutions expanding. The currently offered solutions include Legato (BudTool), Veritas (NetBackup), CommVault (ABARS)& Workstation Solutions (Quick Restore). Note however that NetApp's solutions are in fact broader than NDMP and we are open to considering other alternatives. Other current solutions include - backing up over NFS mounts & CIFS shares, and - RPC-based solutions such as the about to be released Legato Networker Client for NetApp. You may not know it, but to achieve multiprotocol backup over CIFS with current (unchanged) NT backup products such as ARCserve & Backup Exec, NetApp engineering developed a patent pending solution that allows unix permissions to be wrapped into the ACLs captured by the NT backup process. As to the Legato Java-based client about to be released, Legato and NetApp worked jointly to develop this multi-protocol backup solution. The product is currently being tested at beta sites and should FCS early September. Bruce, NetApp is committed to NDMP and will continue to work with our partners to further define, enhance, and expand acceptance of NDMP as an industry standard. And we, as a company, will also continue to perfect our implementation. /***************************************** Mike Marchi - Director, Enterprise Marketing Network Appliance, Inc. (http://www.netapp.com) 495 East Java Drive Sunnyvale, CA 94089 Phone: (408) 822-6283 Fax: (408) 822-4415 Email: mjm(a)netapp.com *****************************************/

2 1

Re: 5.3D20 and bug #16084
by sirbruce＠ix.netcom.com 04 Aug '99

04 Aug '99

On 08/02/99 12:31:38 you wrote: > >Wow, I check my mail and in two consecutive e-mails I lose two clicks of >faith in NetApps. I think the overall consensus is that Netapp filers are still great, but there are a few particular areas where they are less than robust. NDMP is one of those (another is NIS). However, I wouldn't let that drive you away. Just choose a non-NDMP backup solution for the meantime. In a few years maybe NDMP will be perfect and everyone will support if fully. Or maybe some other new great standard will come along. Bruce

3 2

5.3D20 and bug #16084
by Stoltz 04 Aug '99

04 Aug '99

Ok, so I've installed the latest and greatest development release that's supposed to fix our clustered_filer_reboots_randomly_during_NDMP_dumps problem, and now instead of randomly rebooting, our filer has gone the random_refusal of_NDMP_connections route. Which leads me to my point, has anyone else who installed this release to solve this problem seen similar results? Curious, Mark

7 8

RE: CIFS: No permission to rename files?
by Garrett Burke 04 Aug '99

04 Aug '99

Hi Benjy, Possibly the files are locked (by a misbehaving backup app?) Can your users create a new file and then rename it? Can your user with admin priv. (Full control on the files?) rename the files that the other users can't? Check the share permissions as well as the file permissions. GB > ---------- > From: Benjy Feen[SMTP:benjy@feen.com] > Sent: 04 August 1999 00:18 > To: toasters(a)mathworks.com > Subject: CIFS: No permission to rename files? > > "I didn't change anything!" :) > > On two of our toasters, both running 5.1.2R3P1, our CIFS-based users have > found that they're suddenly unable to rename files. One user, who has > administrator priviledges, doesn't have this problem. > > I wanted to post this short description before hauling off and gathering > the full set of evidence/data. Anyone know this issue offhand? > > Thanks! > > > Benjy Feen > benjy(a)feen.com > There is no spoon. >

1 0

RE: 5.3D20 and bug #16084
by Melvin, Grant 04 Aug '99

04 Aug '99

Hi Shaun, > This is exactly why I moved away from using NDMP, and why I would like to > find a backup solution that doesn't require it. Just a few days ago, when > I mentioned this, NetApp went on and on about how they understood they had > a problem and worked really hard to fix it and how wonderful the new NDMP > code written in JAVA was. And then we see these problems. I still stand by what I said, which was: I believe this effort has paid off and that we have fixed our issues in 5.2.*. For 5.3 we ported the NDMP server to run in the Java Virtual Machine & support V3. Results so far have shown some bugs, reported on toasters, but these have been fixed and we have a very stable product. > I have little faith in NetApp's ability to properly impliment this > protocol. Backups are the single most important function I manage as an > administrator, and NetApp seems hell bent on making that process a > nightmare for me, rather than providing me with a rock solid solution. Obviously, the challenge for NetApp is to restore your faith in our delivery of backup solutions, NDMP compliant or not. Seems that I have a few customers to convince of our dedication to effectively supporting NDMP. Since 5.3 shipped in April we have found 6 *NDMP* bugs, including one today :( [13914, 13442, 14897, 15997, 16061, 16949]. Our record should be better, but not all bugs affect everybody or all compliant applications. 2 other bugs which cause issues while running NDMP, i.e. the NDMP experience is flawed by other services it utilizes such as the jvm or dump & restore [13252, 16084] have also been reported. These are all either fixed in 5.3.2 or fixes will be available in a subsequent (08/23) 5.3.2D1 release from customer support, except 15997 which will be fixed in a future maintenance release (slated for end of October). FYI, Data ONTAP 5.2.3 & 5.3.2 are now available for download from NOW: http://now.netapp.com/cgi-bin/software/#ONTAP5 > Does the engineer or project manager responsible for NDMP monitor this mailing list? Benjy, I'm the development manager responsible for NDMP at Network Appliance and I certainly do monitor this mailing list. Thank you all for your feedback. Hopefully, my responses are helping you understand our current NDMP position. Cheers, Grant =========== grant(a)netapp.com ========== Grant Melvin === === Mgr, FS Recovery Group === === Network Appliance === |\ | __ ___ /\ __ __ === 495 East Java Drive === | \ | |__ | /__\ |__| |__| === Sunnyvale === | \| |__ | / \ | | (R) === California === === 94089 === === Tel:(408)822-6761 =========== Network Appliance ========== Fax:(408)822-4457/4525/4559

1 0

RE: 5.3D20 and bug #16084
by Melvin, Grant 04 Aug '99

04 Aug '99

Hi Michael, We've had 5 customers report this issue and it does only affect F5xx hardware as you've pointed out. Unfortunately, this bug is a weird hardware issue that is only tickled with a java application such as the 5.3.X NDMP server. Customer Support are working to create a patch on top of 5.3.2 that will resolve this problem. It should take about another 2 weeks for the D release to be complete, so expect it around 08/23. > i'm really wishing i had not decided to go down the ndmp path. Sorry to hear this. Hopefully with 5.3.2D1 and later we can provide a better customer experience with NDMP. That is our goal. Cheers, Grant -----Original Message----- From: mgx(a)spruce.lsd.ornl.gov [mailto:mgx@spruce.lsd.ornl.gov] Sent: Tuesday, August 03, 1999 5:52 AM To: toasters(a)mathworks.com Subject: Re: 5.3D20 and bug #16084 i have to agree here. after upgrading my F520's to 5.3.X and budtool to 4.6.X i have had nothing but nightmares with respect to my backups, leaving me with a large amount of heartburn. my backups are failing due to bug #13252. this is another ndmp/java problem. here is the problem summary: Problem Summary: The problem is inherent with any process who's stack is VM mapped and touches VM mapped pages. Problem has only been seen on F5xx hardware platform. In the case of 5.3, NDMP uses Java extensively and the Java Garbage collector has the VM Mapped stack. Thus this problem is most prevalent when: - running 5.3 - during NDMP - on F5xx hardware netapp does not have a solution (or an idea when there will be one) but there workaround is: Recommended Solution/Workaround: 13252 is OPEN The chance of this problem occurring during NDMP can be minimized by: 1. Turning off file history during NDMP backups 2. Reducing the size of the dump (no suggested size except the bigger it is, the more chance you may see the problem). i'm really wishing i had not decided to go down the ndmp path. On Mon, Aug 02, Shaun T. Erickson wrote: > > I have little faith in NetApp's ability to properly impliment this > protocol. Backups are the single most important function I manage as an > administrator, and NetApp seems hell bent on making that process a > nightmare for me, rather than providing me with a rock solid solution. >

1 0

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 August 1999