toasters

toasters@lists.teaparty.net

13520 discussions

RE: ndmpd errors
by Toal, Dave 10 May '01

10 May '01

-----Original Message----- From: Conner, Neil To: 'Toal, Dave' Sent: 5/10/01 7:12 PM Subject: RE: ndmpd errors Deleted all my snapshots (didn't have to reboot the filer) and same thing happened... Neil

1 0

Re: EMC IP4700 vs NetApp F740
by Chris_Van_Genderen＠NexFlash.com 10 May '01

10 May '01

Barry, I just re-read my message, and I meant to say that the performance figures for the EMC were pretty dreadful in your experiment. Sorry about the confusion. Regarding EMC's response with running multiple threads. That seems to imply that they are running a significant amount of overhead/operation, and that their system needs to run parallel processes internally to overcome that overhead. To apply this statement to our situation, it sounds like the bandwidth to any one machine may be limited to 40-50Mbits/s read and 20-25Mbits/s write. However, when multiple machines are using the network, the EMC box will probably scale quite nicely. Chris Van Genderen Software Engineer & Applications Manager NexFlash Technologies, Inc. chris_van_genderen(a)nexflash.com 408-969-4714 Barry Lustig <barry(a)lustig.com> To: Chris_Van_Genderen(a)NexFlash.com Sent by: cc: toasters(a)mathworks.com, (bcc: Chris Van Genderen/Santa barry(a)proxy.internal.i Clara/ISSIHQ) ssiusa.com Subject: Re: EMC IP4700 vs NetApp F740 05/10/01 12:02 PM Chris_Van_Genderen(a)NexFlash.com wrote: > > When did you perform your evaluation of the IP4700? Last week. > > On the F85 performance figures, the performance you are quoting seems > pretty bad. Is there an unusually small block size in your application, or > another reason you can account for such a difference? 95Mbits/sec throughput on a 100Mbits/sec connection is extremely good. It is running near the max rate of the connection. The 95Mbits was the data rate. That excludes the packet's header overhead. I'll have to check with the engineer who did the actual testing to find out what block sizes he was using. > > What was EMC's response regarding performance when you showed them your > data? They said that we should run multiple threads. The aggregate bandwidth abilities of the box could keep the links saturated, but the single threaded reads and writes ran into the limitations that I've mentioned. In our application, we need for the single thread to be able to read and write and high speed. We have a single data stream coming in off of a device that has to be written to the filer. barry > > Chris Van Genderen > Software Engineer & Applications Manager > NexFlash Technologies, Inc. > chris_van_genderen(a)nexflash.com > 408-969-4714

1 0

RE: ndmpd errors
by Toal, Dave 10 May '01

10 May '01

Neil, Any busy snapshots? -----Original Message----- From: Conner, Neil To: Toasters (E-mail) Sent: 5/10/01 6:26 PM Subject: ndmpd errors We just installed a second F740 and configured it for clustering. Both filers are running 6.0.1.R3. The original F740 has a tape library attached via SCSI and backups run fine on it using Veritas netbackup 3.4 patch 559 on Solaris 8. I'm trying to do a three-way backup of the new filer. On the master server, I set up authentication with "set_ndmp_auth" and I've verified that the master can connect to the new filer. When I run a backup of /vol/vol0, Veritas aborts with Error 99. The All Logs entry shows: 5/10/2001 3:05:33 PM squid tempest Warning WRN - Cannot backup filepath /vol/vol0, NDMP_HALT_INTERNAL_ERROR occurred (path may not exist), skipping The filer reports the following messages in syslog: Thu May 10 15:06:04 PDT [tempest: Java Thread:warning]: Ndmpd10: Top level IOException Thu May 10 15:06:04 PDT [tempest: Java Thread:warning]: Ndmpd10: IO exception: Socket closed. This is the output from ndmpd probe session: ndmpd ON. Session: 10 isActive: TRUE protocol version: 2 effHost: Local authorized: TRUE client addr: 134.89.10.149:41047 spt.device_id: none spt.ha: -1 spt.scsi_id: -1 spt.scsi_lun: -1 tape.device: not open tape.mode: Read only mover.state: Idle mover.mode: Read mover.pauseReason N/A mover.haltReason N/A mover.recordSize: 0 mover.recordNum: 0 mover.dataWritten: 0 mover.seekPosition: 0 mover.bytesLeftToRead: 0 mover.windowOffset: -1 mover.windowLength: -1 mover.position: 0 mover.connect.addr_type:LOCAL data.operation: None data.state: Idle data.haltReason: N/A data.connect.addr_type: LOCAL data.bytesProcessed: 0 Anybody see the problem? Neil

1 0

ndmpd errors
by Conner, Neil 10 May '01

10 May '01

We just installed a second F740 and configured it for clustering. Both filers are running 6.0.1.R3. The original F740 has a tape library attached via SCSI and backups run fine on it using Veritas netbackup 3.4 patch 559 on Solaris 8. I'm trying to do a three-way backup of the new filer. On the master server, I set up authentication with "set_ndmp_auth" and I've verified that the master can connect to the new filer. When I run a backup of /vol/vol0, Veritas aborts with Error 99. The All Logs entry shows: 5/10/2001 3:05:33 PM squid tempest Warning WRN - Cannot backup filepath /vol/vol0, NDMP_HALT_INTERNAL_ERROR occurred (path may not exist), skipping The filer reports the following messages in syslog: Thu May 10 15:06:04 PDT [tempest: Java Thread:warning]: Ndmpd10: Top level IOException Thu May 10 15:06:04 PDT [tempest: Java Thread:warning]: Ndmpd10: IO exception: Socket closed. This is the output from ndmpd probe session: ndmpd ON. Session: 10 isActive: TRUE protocol version: 2 effHost: Local authorized: TRUE client addr: 134.89.10.149:41047 spt.device_id: none spt.ha: -1 spt.scsi_id: -1 spt.scsi_lun: -1 tape.device: not open tape.mode: Read only mover.state: Idle mover.mode: Read mover.pauseReason N/A mover.haltReason N/A mover.recordSize: 0 mover.recordNum: 0 mover.dataWritten: 0 mover.seekPosition: 0 mover.bytesLeftToRead: 0 mover.windowOffset: -1 mover.windowLength: -1 mover.position: 0 mover.connect.addr_type:LOCAL data.operation: None data.state: Idle data.haltReason: N/A data.connect.addr_type: LOCAL data.bytesProcessed: 0 Anybody see the problem? Neil

1 0

RE: EMC IP4700 vs NetApp F740
by Traitel, Eyal 10 May '01

10 May '01

Yes, you can play on a filer with snap reserve value without any interference with the snapshot creations and/or performance. Eyal. ---------------------------------------------------------------------- eTraitel - I'm the new eBuzzword around !!! ---------------------------------------------------------------------- Filer Escalation Engineer CNA, MCSE, CSA, LCA, NetApp CA Network Appliance BV Hoofddorp, The Netherlands Office: +31 23 567 9685 Cellular: +31 6 5497 2568 ---------------------------------------------------------------------- Get answers NOW! - NetApp On the Web - http://now.netapp.com ---------------------------------------------------------------------- -----Original Message----- From: Ferd Berfl [mailto:ferd_berfl@yahoo.com] Sent: Thu, May 10, 2001 18:09 To: Paul Brosseau; toasters(a)mathworks.com Subject: RE: EMC IP4700 vs NetApp F740 that's a fixed or semi fixed, non-flexible disk space allocation for "copy on write" changed blocks, right? On the Network Appliance filer, isn't' that "reserve" more of an accounting mechanism than a physical disk space allocation? I thought you could use snapshots on the network appliance system without setting any reserve if you wanted. > -----Original Message----- > From: Paul Brosseau [mailto:paulb@netapp.com] > Sent: Thursday, May 10, 2001 9:01 AM > To: ferdberfl(a)netzero.net; toasters(a)mathworks.com > Subject: RE: EMC IP4700 vs NetApp F740 > > > Chris, > > Your description of how the IP4700's Snapshot copy-on-write > mechanism works > is right on. The original data is copied to a new location and > the new data > is written to the original block. Yes this compromises performance. Yes > you have to allocate physical disk space to accomplish this. No > you cannot > shrink the amount of disk space you have allocated for this process if you > find that it is too much. > > Paul Brosseau - Netapp SE > Former EMC SE > > -----Original Message----- > From: owner-dl-toasters(a)netapp.com > [mailto:owner-dl-toasters@netapp.com]On Behalf Of Ferd Berfl > Sent: Thursday, May 10, 2001 10:02 AM > To: toasters(a)mathworks.com > Subject: RE: EMC IP4700 vs NetApp F740 > > > re: snapshots, I thought that everyone else's snapshot functionality other > than Netapp's must be based on a "copy on write" method because > Netapp has a > patent on continuously writing new blocks. (their WAFL filesystem > intellectual property and patents). If you can't take advantage of the > method of writing modified blocks as new blocks and not touching the > original block pointed to by the snapshot, doesn't that mean that you have > to reserve some amount of storage, that is free blocks, for > holding the copy > on write changed blocks to maintain the snapshots? > > > > > -----Original Message----- > > From: owner-dl-toasters(a)netapp.com > > [mailto:owner-dl-toasters@netapp.com]On Behalf Of Barry Lustig > > Sent: Wednesday, May 09, 2001 5:30 PM > > To: Chris_Van_Genderen(a)NexFlash.com > > Cc: sirbruce(a)ix.netcom.com; toasters(a)mathworks.com > > Subject: Re: EMC IP4700 vs NetApp F740 > > > > > > Chris, > > > > I'm the person that started the F85 vs. IP4700 thread. Here is one > > data point. When we benchmarked the F85 it was able to do a single > > threaded read at 90-95 Mbits/sec and writes at 85-90 Mbits/sec. This > > was on a 100BaseT full-duplex connection to a linux box. When we tried > > the same benchmark with the IP4700 it showed 40-50 Mbits/sec read and > > 20-25 Mbits/sec write. This clinched the deal for the F85's for us. > > EMC compares the IP4700 to the F8xx line. If the system cannot even > > keep up with an F85, I think that EMC needs to take a look at what is > > going on. Also, you should check with EMC regarding their snapshot > > implementation. Netapp's snapshots don't have to copy old data when a > > data block is updated. A new block is allocated and then written. I've > > heard, but haven't verified that the IP4700's filesystem acts more like > > a copy on write system. First the old data block has to be copied to a > > new location then the modified data is written. If this is actually the > > case then the performance of the filesystem will be compromised. I know > > that there are EMC folks on this list. Maybe one of them can respond. > > > > barry > > > > > > Chris_Van_Genderen(a)NexFlash.com wrote: > > > > > > Bruce, > > > > > > One of the items that I did not mention was that > > > we are a start up company that is using the back-end > > > infrastructure of our parent company. I have been given > > > the task of not only buying a NAS device for company wide > > > storage, but also to build the entire network infrastructure and > > > server infrastructure for our new location. So, what ever we > > > purchase will need to go online immediately and support the > > > company in a new location. I don't have the "test-bed" to test > > anything. > > > > > > As you can also guess, via my title, I am not a MIS person either. So, > > > I've been going through a fairly steep learning curve in many areas. I > > > am weary about compatibility issues with NFS and our engineering/CAD > > > Sun machines. In this area, I feel because of their industry > > experience, > > > NetApp has the edge. I've talked with EMC on this issue, and they > > > re-assure me that the IP4700 will not have compatibility problems. > > > However, > > > this is much different than having users of the product claim > that their > > > are no compatibility problems. > > > > > > My gut feeling is to go with the F740 because of the existing > > installation > > > base, > > > and the maturity of the product. I'm just a little miffed that > > NetApp has > > > been > > > trying to use my inexperience and limited knowledgebase against > > me during > > > the sales process; it doesn't give me the feeling that I can > trust them. > > > > > > Chris Van Genderen > > > Software Engineer & Applications Manager > > > NexFlash Technologies, Inc. > > > chris_van_genderen(a)nexflash.com > > > > > > > > > "Bruce > > > Sterling To: > > <toasters(a)mathworks.com>, <Chris_Van_Genderen(a)NexFlash.com> > > > Woodcock" cc: (bcc: Chris > > Van Genderen/Santa Clara/ISSIHQ) > > > <sirbruce(a)ix.n Subject: Re: EMC > > IP4700 vs NetApp F740 > > > etcom.com> > > > > > > 05/09/01 03:45 > > > PM > > > > > > > > > > > > Most of what you seem to be weighing are nebulous > > > issues of who says what. Why don't you just find out > > > for yourself? > > > > > > Ask Netapp for an F760 to try out for 2 weeks. > > > > > > Ask EMC for an IP4700 *at the equivalent price > > > and disk capacity, with RAID* to try out for 2 weeks. > > > > > > See which has better performance for your users and > > > which you can administer easier. Build large RAID > > > groups, test simultaneous file sharing from NFS and > > > CIFS, fail drives, do rebuilds, etc. > > > > > > Bruce > > > > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

4 3

Galaxy and NDMP
by Jordan Share 10 May '01

10 May '01

We're currently planning to purchase a NetApp 720 in the next few weeks. Thus, we are evaluating our backup options for this product. Basically, what I want to know is if anyone has experience with CommVault's Galaxy product and using it with a (directly attached to the NetApp) Treefrog tape library. What we want to be able to do is take the tapes produced by backing up (the NetApp) via NDMP, and restore them to a non-NetApp target location. We want to do this so we can restore our data (in event of disaster) without having to have a NetApp to restore it onto. Anyone have any experience with this, or know if it is possible? I'm having little luck getting assistance from CommVault. :( Thanks, Jordan

1 0

NOW surveys
by Timothy Cook 10 May '01

10 May '01

Folks, I am one of those people who more often than not completes the NOW surveys, though I often wondered why I bothered. Earlier we had a rather lively thread discussing these surveys and ways to get more responses. ConGrats to Netapp for listening! I just received a $5 gift certificate for Amazon.com from NOW in appreciation for my response to the latest survey. It's good to see a company respond to their customers in such a manner.

1 0

Re: EMC IP4700 vs NetApp F740
by Chris_Van_Genderen＠NexFlash.com 10 May '01

10 May '01

Barry, I appreciate you sharing your experiences. When did you perform your evaluation of the IP4700? On the F85 performance figures, the performance you are quoting seems pretty bad. Is there an unusually small block size in your application, or another reason you can account for such a difference? What was EMC's response regarding performance when you showed them your data? Chris Van Genderen Software Engineer & Applications Manager NexFlash Technologies, Inc. chris_van_genderen(a)nexflash.com 408-969-4714

2 1

RE: EMC IP4700 vs NetApp F740
by Joe Luchtenberg 10 May '01

10 May '01

Giving the benefit of the doubt, perhaps the EMC reps were talking only about when the SnapView is initially created. However, they certainly utilize a "copy-on-first-write" procedure for subsequent changes to the active file system. For more details: http://www.emc.com/pdf/products/clariion/SnapView_DS.pdf The impact on performance, of course, depends entirely on your environment. In many cases it may be indistinguishable from NetApp because the rate of data change in the filesystem is relatively small. To conduct another fishing expedition for the EMC lurkers among us, I assume that with SnapView/IP (like TimeFinder) you can "split-off" a SnapView (like a BCV) for various purposes. True? This creates a capacity planning issue, but may be a valuable capability, depending on your requirements. Joe Joe Luchtenberg Dataline, Inc. 757.858.0600 757.285.1223 (cell) 757.858.0606 (fax) joe.luchtenberg(a)data-line.com www.data-line.com > -----Original Message----- > From: Martin Hughes [mailto:Martin.Hughes@Halliburton.com] > Sent: Thursday, May 10, 2001 12:45 PM > To: toasters(a)mathworks.com > Subject: RE: EMC IP4700 vs NetApp F740 > > > >Your description of how the IP4700's Snapshot copy-on-write > mechanism works > >is right on. The original data is copied to a new location > and the new > data > >is written to the original block. Yes this compromises > performance. Yes > >you have to allocate physical disk space to accomplish this. > No you cannot > >shrink the amount of disk space you have allocated for this > process if you > >find that it is too much. > > > Hmm, not according to a demo we had from EMC week before > last. I grilled > them pretty hard on that and they claimed that they updated > the inode file > only and did not copy blocks to another location. > > Well, we have an eval unit coming in next week and I'll do > some testing. > > Regards > > Martin > Enterprise Storage/Enterprise Server Group > <mailto:martin.hughes@halliburton.com> > cellphone: +1 713 303 9214 > office: +1 281 871 4124 > >

1 0

RE: EMC IP4700 vs NetApp F740
by Martin Hughes 10 May '01

10 May '01

>Your description of how the IP4700's Snapshot copy-on-write mechanism works >is right on. The original data is copied to a new location and the new data >is written to the original block. Yes this compromises performance. Yes >you have to allocate physical disk space to accomplish this. No you cannot >shrink the amount of disk space you have allocated for this process if you >find that it is too much. Hmm, not according to a demo we had from EMC week before last. I grilled them pretty hard on that and they claimed that they updated the inode file only and did not copy blocks to another location. Well, we have an eval unit coming in next week and I'll do some testing. Regards Martin Enterprise Storage/Enterprise Server Group <mailto:martin.hughes@halliburton.com> cellphone: +1 713 303 9214 office: +1 281 871 4124

2 1

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