toasters

toasters@lists.teaparty.net

13531 discussions

RE: NetApp/NDMP
by Melvin, Grant 05 Aug '99

05 Aug '99

Hi Bruce, I still foresee a role for NDMP in a hybrid NAS/SAN solution: 1. Scheduling backups 2. Maintaining catalog of backed up images 3. Changing tapes within a library Cheers, Grant -----Original Message----- From: sirbruce(a)ix.netcom.com [mailto:sirbruce@ix.netcom.com] Sent: Wednesday, August 04, 1999 9:47 PM To: michael.marchi(a)netapp.com Cc: toasters(a)mathworks.com Subject: Re: NetApp/NDMP 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

tape drives in a cluster
by kevin graham 05 Aug '99

05 Aug '99

Does anyone know if there's a way to modify the scsi id of the tape controller in a 760? It would be nice if our clustered 760's could share a tape drive, or pair of drives, especially given how there's a whole controller set aside for it.. ...kg..

1 0

ok, so what do you use?
by dnb＠ccs.neu.edu 05 Aug '99

05 Aug '99

Howdy- The whole backup discussion leads me to a (potentially loaded) question: what software does NetApp (the company) use to back up its data? Peace, dNb

1 0

RE: Adding a FC shelf in a cluster w/o downtime
by Mohler, Jeff 05 Aug '99

05 Aug '99

My initial feelings are 'bad things will happen'. I dont have any technical data to back that up, other than its not documented to do it that way. -----Original Message----- From: Jay Soffian [mailto:jay@cimedia.com] Sent: Thursday, August 05, 1999 10:05 AM To: toasters(a)mathworks.com Subject: Adding a FC shelf in a cluster w/o downtime We are going to be adding an additional FC shelf to our clustered F740's. Obviously, the safe way to do this is to halt both 740's, attach the A & B loops, then bring both filers back up. But, what I was wonder was, would it be possible to: - Attach the B-loop first. - Have the B-Loop Filer take over all th shelves (including the new shelf). - Attach the A-Loop. - Give back the shelves to the A-Loop filer. I don't think we'll do this as we're only talking about about maybe 2 minutes of downtime vs 30 seconds, but I was wondering if this is a feasible thing to do. Thoughts? j.

1 0

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

05 Aug '99

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. --- Thats because you cant. NFS operations are many things, file creation, removal, buffering, data, lookups, info..etc. Writing a 1Gb file wont create nearly the operations that creating 1GB of 10k files. 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%. --- This is about where you'll peg out Ive seen. Until the box has some serious CPU dedicated to RAID stripe calculations, and much MUCH more NVRAM..the platform is artificially limited. And if I understand correctly, your NVRAM caching becomes even less effective when you cluster. These are not BAD points about the filer at all, just places where improvements are taking place.

1 0

RE: Adding a FC shelf in a cluster w/o downtime
by Watanabe, Steven 05 Aug '99

05 Aug '99

> From: Jay Soffian [mailto:jay@cimedia.com] > We are going to be adding an additional FC shelf to our clustered > F740's. Obviously, the safe way to do this is to halt both 740's, > attach the A & B loops, then bring both filers back up. > > But, what I was wonder was, would it be possible to: > > - Attach the B-loop first. > - Have the B-Loop Filer take over all th shelves (including > the new shelf). > - Attach the A-Loop. > - Give back the shelves to the A-Loop filer. > > I don't think we'll do this as we're only talking about about maybe 2 > minutes of downtime vs 30 seconds, but I was wondering if this is a > feasible thing to do. Adding a disk shelf requires the FCAL cable to be unplugged while that shelf is being rewired. This requires the owning node to be HALTed at the time. It is possible to keep one member of the cluster alive during shelf rewiring. The approach is to HALT one node, failover to the other node, wire up the first node's A loop, and then bring that first node back to life. Then repeat the process, failing over and rewiring in the opposite direction.

1 0

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

Re: show_therm
by sirbruce＠ix.netcom.com 04 Aug '99

04 Aug '99

On 08/01/99 12:11:39 you wrote: > > >On Sat, 31 Jul 1999, Dave Hitz wrote: > >> One obvious concern on redesigning command UIs is >> breaking scripts, so we are especially interested in knowing which >> rc_toggle_basic commands people have built into scripts. > >Here is a short list of commands I've been caught using. I don't have any >of these in my scripts, but they are indispensable for me. >[various yp commands deleted] When they implemented yp/NIS, I told them to make these commands public. RFEs were opened. Netapp decided against it, so they were closed. Trot out the tired old "we're an appliance, it should be simple" explanation. >On a side note, is there a command to be used from the console or rsh that >allows one to log off the telnet session. This would be extremely usefull >as some of our admins telnet in from Windows making it relatively hard to >log them off. There was a bug/RFE opened on this as well, years ago. I think Netapp would find it more production, rather than doing another round of "tell us what you want" solicitation, is to go back and see what they got the last n times they asked "tell us what you want" and didn't do anything. Bruce

2 1

CIFS: No permission to rename files?
by Benjy Feen 03 Aug '99

03 Aug '99

"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: CIFS Remote Backup Options
by Garrett Burke 03 Aug '99

03 Aug '99

Hi Matt, No we haven't tried 5.2.2P1 or 5.3 yet to solve the oplock bug. The reason is that out filer is stable at the moment and we have found in the past that we end up with some stability problems when we install another release of OnTap. We have a workaround for the oplocks bug which doesn't bite us so hard at the moment (Having said that we will be upgrading to 5.3 sometime as NTP would be nice) GB > ---------- > From: Matt Day[SMTP:mday@netapp.com] > Sent: 31 July 1999 00:21 > To: Garrett Burke > Cc: toasters(a)mathworks.com > Subject: Re: CIFS Remote Backup Options > > >c) oplocks. This has caused us numerous problems. We now run the > backups > >with oplocks turned off, as there some sort of interaction between > ARCServe > >and the oplock code (we tried a few D releases but never got around it) > >which means that things run very, very slowly. Like, 2 days to run the > >backup! > > Hi Garrett, > > There is an oplock bug in 5.2.1 (burt12483) that sometimes delays the > delivery of oplock break messages -- I bet that's the performance > problem you're hitting with oplocks enabled. The fix for this bug is > available in 5.2.2P1 and 5.3. Have you tried either of those releases? > > Matt >

1 0

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

02 Aug '99

Hi Benjy, FYI, the fix for 16084 is targeted for a future release (slated for end of October) and should be made available in a 5.3.2 patch in the meantime. NetApp is working with Mark to determine what the "random_refusal_of_NDMP_connections" problem that he is seeing is. Cheers, Grant -----Original Message----- From: Benjy Feen [mailto:benjy@feen.com] Sent: Monday, August 02, 1999 10:32 AM To: toasters(a)mathworks.com Subject: Re: 5.3D20 and bug #16084 Wow, I check my mail and in two consecutive e-mails I lose two clicks of faith in NetApps. Are these critical NDMP problems limited to 5.3.X, or does 5.2.X have issues I should know about? Is thered a 5.3 release that gives me the NDMP functionality I need without giving me the NDMP bugs I don't? Does NetApp have any kind of document, internal or external, of the form: "How to use NDMP with NetBackup 3.2 without making your filers reboot randomly, or refuse backups, or catch fire"? On Mon, 2 Aug 1999, Stoltz wrote: > > 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 > Benjy Feen benjy(a)feen.com There is no spoon.

1 0

Re: Remote Backup Options
by Steve Kappel 02 Aug '99

02 Aug '99

>Speaking of remote backup, my backup team tells me that Veritas backups of >Filers via NDMP don't work with the current release (5.3.x) of DOT. Any >word on when (date please) this will be fixed? If already fixed, can >someone let me know so I could get the appropriate version from Tech. OnTap 5.3.2 will be qualified for local (not 3-way) backup/restores with NetBackup 3.2 very soon. 5.3.2 should be out "any day now". __________________________________________________________________________ Steve Kappel steve.kappel(a)veritas.com VERITAS Software steve.kappel(a)iname.com (Personal)

2 1

Re: Remote Backup Options
by Jason Middlebrooks 02 Aug '99

02 Aug '99

I have gotten it to work with DOT 5.3D14. I have done backups and restores. Jason tkaczma(a)gryf.net on 07/31/99 01:39:03 AM To: toasters(a)mathworks.com cc: (bcc: Jason Middlebrooks/Datalink) Subject: Remote Backup Options Speaking of remote backup, my backup team tells me that Veritas backups of Filers via NDMP don't work with the current release (5.3.x) of DOT. Any word on when (date please) this will be fixed? If already fixed, can someone let me know so I could get the appropriate version from Tech. Support? My whole organization (really, I'm not kidding) is anxiously awaiting SnapMirror which is available in 5.3.x. However, I can't install the new version if I can't backup the servers. Thanks Tom

1 0

Re: show_therm
by sirbruce＠ix.netcom.com 01 Aug '99

01 Aug '99

On 07/30/99 21:27:32 you wrote: >Netapp - why do you do these things >to me?!?!?!?!? > >Graham Graham - why would you rely on undocumented and unsupported commands and risk disappointing your management?!?!? Bruce

6 5

Re:ISP_2100: cmd opcode 0x28, retry count 0: command timeout, aborting request error
by raster＠netapp.com 01 Aug '99

01 Aug '99

>Can anyone shed some light on the error below? It looks like it is just a >media error which was recovered from, but I wanted verification. > Thank you, > Mike > > >Wed May 12 00:13:03 EDT [isp2100_timeout]: 8.45 (cmd opcode 0x28, retry >count 0): command timeout, aborting request >Wed May 12 00:13:03 EDT [isp2100_timeout]: isp2100_reset_device: device 8.45 >(1.45) Hi Mike, The above message sequence is a symptom of SCSI command timeout. As part of timeout recovery, the device in question is reset and all pending commands are reissued. Hope this helps. -- --------------------------------------------------------------------------- Radek Aster [ raster_at_netapp_dot_com ] | "I bike, therefore I am" http://www.nowhere.net/~raster/ | - Rene' DesBiketes ---------------------------------------------------------------------------

6 11

Re: show_therm
by sirbruce＠ix.netcom.com 01 Aug '99

01 Aug '99

>As you can see, we have created a bit of a mess for ourselves. Slowly >but surely we are going to dig our way out. I don't mean to be a skeptic but you've been giving this idea the same lip service for years. I'm sure you're committed to it, but the real challenge will come in sticking with it every release. Anyway, the real problem was the disconnect between engineering and support. As another customer pointed out, support started handing out this information at first as-needed for problem troubleshooting and then later in actual courses. This issue should have been seen coming. But until it is resolved, I do think that customers who rely on such commands are making a mistake. Even Netapp's high level of support is only going to get you so far if you make too many assumptions about unsupported stuff. Bruce

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