toasters

toasters@lists.teaparty.net

13515 discussions

Re: tape drives in a cluster
by Michael Salmon 06 Aug '99

06 Aug '99

+----- On Thu, 05 Aug 1999 10:43:51 PDT, kevin graham writes: | | 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.. I am interested in a related problem and I have found the following SCSI switches: http://www.digital-interact.co.uk/site/html/switches/switch_matrix.html http://www.peripheral-vision.com/switch.htm The Peripheral Visions switch looks particularly promising. /Michael

1 0

VERITAS announce support for 5.2.3 & 5.3.2
by Melvin, Grant 06 Aug '99

06 Aug '99

Hi, > Regarding certification Legato, Veritas & CommVault are all > currently testing our 5.2.3 & 5.3.2 maintenance releases, so > we seemed to have closed this loop too. Since there has been a lot of traffic on NDMP recently. I thought I'd let you know that VERITAS just informed us that they now support DATA ONTAP 5.2.3 & 5.3.2. ++++++++ > Any ETA on a certification announcement? Hi Grant, Both 5.2.3 and 5.3.2 are now qualified with NetBackup 3.2. 5.2.3 is now qualified with NetBackup 3.1.1. 5.3.2 is supported for local backup/restore only. Regards, Tom Nelson ++++++++ Cheers, Grant

1 0

RE: ok, so what do you use?
by Melvin, Grant 06 Aug '99

06 Aug '99

Hi, We use BudTool 4.6 (plus patches - don't think we've installed 4.6.1, but we might have) in IT on our corporate filers. A big part of the decision was that BudTool offers local, 3-way & remote (back to the NDMP client host) backups. In engineering we have an internal test department that adminsters a set of production filers. Here we run VERITAS NetBackup 3.2. Since we wanted to get exposure to multiple backup solutions within the organization. Cheers, Grant -----Original Message----- From: dnb(a)ccs.neu.edu [mailto:dnb@ccs.neu.edu] Sent: Thursday, August 05, 1999 10:26 AM To: toasters(a)mathworks.com Subject: ok, so what do you use? 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: Linux, Samba and CIFS
by Stephen Wu 05 Aug '99

05 Aug '99

We've upgraded to 5.3.2, but found several problems. Any advice would be much appreciated. - smbmount commands work, and you can verify that the Linux box is connected to the filer. - The ls commands return unexpected output. For example, ls -l on an smbmount returns [root@bombay InetPub]# ls -l ls: ~snapsho: No such file or directory ls: users1: No such file or directory total 0 The actual sub-directories in this directory are ~snapshot and users14. - the smbumount command also has problems [root@bombay InetPub]# smbumount /mnt/frick/InetPub Could not umount /mnt/frick/InetPub: Device or resource busy -Stephen -----Original Message----- From: Benn, Paul [mailto:paul.benn@netapp.com] Sent: Thursday, July 29, 1999 11:18 AM To: 'Sam Schorr'; Benn, Paul; 'toasters(a)mathworks.com' Cc: Stephen Wu; Mike Mcnelly Subject: RE: Linux, Samba and CIFS You might want to consider upgrading to Data ONTAP 5.3.2. The smbmount command works with that version. Out of curiosity, is there any reason that you would rather use CIFS than NFS to connect from a Linux box (assuming your filer is licensed for both)? Regards, Paul -----Original Message----- From: Sam Schorr [mailto:sschorr@homestead.com] Sent: Thursday, July 29, 1999 10:49 AM To: 'Benn, Paul'; Sam Schorr; 'toasters(a)mathworks.com' Cc: Stephen Wu; Mike Mcnelly Subject: RE: Linux, Samba and CIFS We are using Samba 2.0.3-8. the filers are running 5.2.1P2D6. -----Original Message----- From: Benn, Paul [mailto:paul.benn@netapp.com] Sent: Thursday, July 29, 1999 10:46 AM To: 'Sam Schorr'; 'toasters(a)mathworks.com' Cc: Stephen Wu; Mike Mcnelly Subject: RE: Linux, Samba and CIFS What are you using to mount the share? What version of Data ONTAP are you using? Regards, Paul -----Original Message----- We're trying to get a Linux box, using Samba, to mount an NT share to our filers. We have been, quite successfully, accessing the filers from the NT domain they are in using normal UNC share names. We have also, successfully, mounted NT shares from the Linux box using Samba. The failure seems to be in some area of authentication on the part of the filers that is somehow unique to them as other NT systems are quite happy talking to the Linux/Samba mount.

1 0

disk_fw_update
by kevin graham 05 Aug '99

05 Aug '99

I was reading the docs prior to upgrading to 5.2.3, and I realized that I get to upgrade everything, os, filer fw, and disk fw.. The thing that occured to me as unfortunate was from na_disk_fw_update(1): This command makes disks inaccessible for up to 2 minutes, so network sessions using the filer should be closed down before running it. I've only got 4 shelves, so its not a huge deal, but I could see this having a big impact in larger environments.. Obviously the disk has to be inaccesible during the period of the fw upgrade, but disabling file service necessary? The reason I ask is that the filer can already run short a disk following a failure, so why not copy this functionality so that disk_fw updates can be done without service disruption? ....just a'wonderin'.. ...kg..

2 1

Re: [Fwd: disk_fw_update]
by raster＠netapp.com 05 Aug '99

05 Aug '99

>I was reading the docs prior to upgrading to 5.2.3, and I realized that I get >to upgrade everything, os, filer fw, and disk fw.. > >The thing that occured to me as unfortunate was from na_disk_fw_update(1): > > This command makes disks inaccessible for up to 2 minutes, so network > sessions using the filer should be closed down before running it. > >I've only got 4 shelves, so its not a huge deal, but I could see this having a >big impact in larger environments.. > >Obviously the disk has to be inaccesible during the period of the fw upgrade, >but disabling file service necessary? The reason I ask is that the filer can >already run short a disk following a failure, so why not copy this >functionality so that disk_fw updates can be done without service disruption? Hi Kevin. You are correct that a RAID system protects against a single disk failure; the raid group is placed into degraded mode and the contents rebuilt onto a spare. Now, to address your point, yes, it's technically possible to place a raid group into "pseudo-degraded" mode where a disk is temporarily take offline but no reconstruction is started. Note, OnTap doesn't work this way and making it work this way would take quite a bit of doing. For one thing, "re-syncing" the disk which was temporarily taken offline and then brought back later would take quite a bit of book keeping and associated headaches. *If* the above machinery was in place, firmware updating could be made to work one-disk-at-a-time without any disruption of service. However, one has to ask oneself whether it's worth it? How often does one upgrade disk firmware? Hope this answers your question. Let me know otherwise. -- --------------------------------------------------------------------------- Radek Aster [ raster_at_netapp_dot_com ] | "I bike, therefore I am" http://www.nowhere.net/~raster/ | - Rene' DesBiketes ---------------------------------------------------------------------------

1 0

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

05 Aug '99

Actually it is documented in the "Fibre Channel StorageShelf Hardware Guide". There is a chapter on doing exactly this although the doc says attach A channel first. You can see it on-line on NOW: http://now.netapp.com/knowledge/docs/hardware/fcshelf.pdf Its in appendix A, entitled "Adding Hardware for a Cluster". I'm not surprised that you didn't find it. I'm the product manager for Clusters and I've reviewed every manual numerous times. I knew it existed somewhere but it still took me 15 minutes to dig it up. Unless your one of those people who reads every manual cover to cover you probably would never have known it existed. The Tech Pubs crew here has done major reorganizations of the manual set. They have put all the software manuals on line in HTML in addition to the pdf format. They are always looking for ways to improve the doc set and welcome comments from customers on things they can do to make the docs easier to use (It would be nice if you told them when they've done something you like too, but that might be pushing it). You can send comments via feedback on NOW or send e-mail to doccomments(a)netapp.com. When you run across issues like this, where you can't find something, a quick note saying what you wanted and where you looked might help the next time they reorganize the manual to put the information in a better place or create a better index or whatever. PS. In house we just rack the shelf and shut down, add the daisy chains, power up. It only takes a five minutes, but then we're pretty adept at cabling since we get so much practice, YMMV. Cheers Paul Norman, Product Manager Direct: (408) 822-6288 Network Appliance E-Mail: pnorman(a)netapp.com 495 East Java Drive Corp: (408) 822-6000 Sunnyvale, CA 94089 Web: WWW.NetApp.Com > -----Original Message----- > From: Mohler, Jeff [mailto:jeff.mohler@wilcom.com] > Sent: Thursday, August 05, 1999 9:42 AM > To: Jay Soffian; toasters(a)mathworks.com > Subject: RE: Adding a FC shelf in a cluster w/o downtime > > > 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. >

2 1

Adding a FC shelf in a cluster w/o downtime
by Jay Soffian 05 Aug '99

05 Aug '99

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 1

managing permissions in mixed qtrees
by Gregory M. Paris 05 Aug '99

05 Aug '99

Toasters, We have a new filer with NFS and CIFS. The plan is to move/merge all of the NT and UNIX homes (from NT and UNIX servers) onto mixed qtrees. Each user gets one and only one home directory. Conceptually simple. However, we now see one thing that may bite us in practice: Doing recursive mode/ACL changes in user home directories will have the effect of converting some UNIX-security files to NT-security files or vice versa (depending on whether the operation done from NT or UNIX). At a minimum this will cause confusion, but in some cases could break things -- most probably things that depend on NT ACLs that get wiped when somebody does chmod. I'd like to hear from other admins that have merged UNIX/NT home directories. Have you had this kind of problem? If so, have you found ways to work around it? Thanks i.a., Greg -- Gregory M. Paris CIS Engineering Systems Bose Corporation Email: paris(a)bose.com The Mountain Phone: +1 508 766-6080 Framingham, MA 01701-9168 FAX: +1 508 820-0173

1 0

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

Jump to page:

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