toasters

toasters@lists.teaparty.net

13515 discussions

RE: Copy on write - Netapp vs. others
by Paul Timmins 14 May '01

14 May '01

Not to nit-pick... but what being described is the behavior of a log-structured file system (of which WAFL is one). There are many other implementations of log-structured file systems. IMO, calling that copy-on-write is dead-wrong, not merely confusing. There's no copy going on. The inode file is copied (checkpointed) when a snapshot is initiated, not when a write occurs. Just my two cents... Paul -----Original Message----- From: Eli Lopez [mailto:elopez@netapp.com] Sent: Sunday, May 13, 2001 4:38 AM To: Jay Soffian; toasters(a)mathworks.com Subject: Re: Copy on write - Netapp vs. others Hi Jay, You are right that the terminology is confusing. One way to look at it is to think of two ways of copy-on-write: when you are updating a block of a file you can: 1) Either write the NEW UPDATED block to a new location 2) Or move the OLD block to a new location AND THEN write the new updated block in place of the old one. Taking a snapshot with both methods involves copying the inode file BUT obviously there could be serious performance impact using the second method (for each update, the write request needs to 'wait' until the old block gets copied to a new location). Network Appliance's WAFL uses the first method which does not have any impact on performance and is (IMVHO) much more elegant. Thanks, Eli ______________________ Eli Lopez Systems Engineer Manager Network Appliance, Israel (+972) - 50 - 304 - 733 Eli.Lopez(a)Netapp.com ______________________ ----- Original Message ----- From: Jay Soffian <jay(a)loudcloud.com> To: <toasters(a)mathworks.com> Sent: Thursday, May 10, 2001 7:00 PM Subject: Re: EMC IP4700 vs NetApp F740 > "Ferd" == Ferd Berfl <ferd_berfl(a)yahoo.com> writes: > > > 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. > > WAFL uses copy-on-write. Here, straight from the horse's mouth: > > WAFL uses a copy-on-write technique to minimize the disk space that > Snapshots consume. > > http://www.netapp.com/tech_library/3002.html > > Now, Netapp's implementation may be unique, but to say that WAFL > doesn't use copy-on-write and to make a claim like "copy-on-write is > slow, Netapp doesn't use it" is bogus. > > j. > -- > Jay Soffian <jay(a)loudcloud.com> System Administrator > 408 744 7584 Loudcloud, Inc.

4 3

RE: Galaxy and NDMP
by Melvin, Grant 14 May '01

14 May '01

Hi Jordan, With a (directly attached to the NetApp) tape device you will need to run an NDMP-compliant application such as CommVault's Galaxy (or use rsh scripts) to run dump on the filer. Anyway the resulting format written to tape is in the BSD dump format which is compatible with Solaris' ufsrestore. To restore them to a non-NetApp target location you can perform a native (to Solaris) ufsrestore of the backup, but there will be a few hoops to jump through, such as, knowing where the backup images are on each tape and running the tapes through dd prior to ufsrestore. The reason for this last point is that NDMP backups even though they may cross tape boundaries are actually written as one very large (usually) data stream and therefore have to be read back that way which an NDMP restore on a filer achieves. If the data in the backup has mixed (Unix & NT) permissions then the NT permissions will be lost during a ufsrestore backup, but the data & unix permissions will be intact. Alternatively you can perform non-NDMP backups over CIFS which will capture the data + Unix & CIFS permissions. If you then restore on a filer it will restore the data + Unix & CIFS permissions. If you restore on an NT server you will get the data + CIFS permissions, but no Unix permissions. I'd go this way if you only have CIFS data or mixed data and I'd perform NFS backups if you only have NFS data. However, it really looks like the dependency is on the equipment at your disaster recovery location and in this case I'd go for filers! ;-D Hope this helps and I hope CommVault are listening. Cheers, Grant -----Original Message----- From: Jordan Share [mailto:iso9@phantasticant.com] Sent: Thursday, May 10, 2001 2:11 PM To: toasters(a)mathworks.com Subject: Galaxy and NDMP 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

2 1

RE: REMOVE
by Gregg Anderson 14 May '01

14 May '01

If you ever want to remove yourself from this mailing list, you can send mail to <lists(a)mathworks.com> with the following command in the body of your email message: unsubscribe toasters or, if from another email account unsubscribe toasters <your_subscribed_email_address_here> ________________________________________________ Gregg Anderson Sales Engineer - Network Management Services - Internet Ops S1 Community and Regional eFinance Solutions Group <http://www.s1.com/> Work 512.336.3156 Mobile 512.751.0779 Fax 512.615.1275 Delivering the Compelling eFinance Experience This electronic message transmission contains information from S1 Community and Regional eFinance Solutions Group that may be confidential or privileged. The information is intended to be for use solely by the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify us by telephone 512.336.3000 or by electronic mail immediately. -----Original Message----- From: Eicher, Scott [mailto:scotte@netperceptions.com] Sent: Monday, May 14, 2001 2:49 PM To: toasters(a)mathworks.com Subject: REMOVE PLEASE REMOVE ME FROM THE MAILING

1 0

REMOVE
by Eicher, Scott 14 May '01

14 May '01

PLEASE REMOVE ME FROM THE MAILING

1 0

remove
by Omar Fabián García 14 May '01

14 May '01

remove -- Ing. Omar Fabián García Ejecutivo de Cuentas LighTech mailto:ogarcia@lightech.com.ar Reconquista 1034. Piso 1 Tel:(54-11) 4311-4960 Capital Federal Fax:(54-11) 4311-3132 Buenos Aires - Argentina C1003ABV http://www.lightech.com.ar

1 0

"Hobbyist" licenses?
by Bill Bradford 14 May '01

14 May '01

Well, I havent found a way (yet) to make this F330 into a non- doorstop, and have no friends to quietly swipe a NFS license key off of. The NetApp sales rep that called me even suggested that "maybe you can run Linux on it?" Hrmph. 8-) So, any chance in hell for us people who happen to have older machines at home to get some kind of a "hobbyist use" or "restricted" NFS license so that we can make use of these machines? I'd be willing to sign something stating that I wont be using the filer in any kind of commercial / for-profit capacity (in fact, MP3s for my wife, and my important documents...) Bill -- Bill Bradford mrbill(a)mrbill.net Austin, TX

1 0

Testing Toasters List
by Sam Schorr 14 May '01

14 May '01

Hey, I haven't received new mail in awhile on this list. So, this is just a test to see if something is amiss with my mail. Sam Schorr

1 0

RE: Copy on write - Netapp vs. others
by Paul Timmins 14 May '01

14 May '01

I'll give you a 10 for good linguistics. [although, heck, I still don't agree, since there never is a copy of the data] The way I see it: Regarding log-structured, you are describing additions to standard filesystems to log prior to write (generally for reboot consistency), such as Sun's UFS w/ Logging in Solaris 7. That is not a log-structured file system. Do a quick search on log-structured file systems, and you'll see many other implementations. For example (of a paper): (apologize for the long url) http://citeseer.nj.nec.com/cache/papers2/cs/698/http:zSzzSzwww.eecs.harvard. eduzSz~margozSzpaperszSzusenix.193.pdf/seltzer93implementation.pdf Paul -----Original Message----- From: Traitel, Eyal [mailto:eyal@netapp.com] Sent: Sunday, May 13, 2001 10:43 PM To: Paul Timmins; 'Eli Lopez'; Jay Soffian; toasters(a)mathworks.com Subject: RE: Copy on write - Netapp vs. others Paul, I think this is only terminology issue. The word "copy" was probably used as a noun, not a verb, with the meaning that after the write, you have another copy of the same block - well, not exactly the same - one is the old, one is the new. Hence the word copy. On log structured fs - if WAFL was simple and not patented everyone could have just do it like us. This is not the case. Regular log based filesystems have to commit once in a while the log into the original, fixed locations on disk. WAFL does not have this limitation - that's the Anywhere from the word WAFL. 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: Paul Timmins [mailto:paul@ptimmins.com] Sent: Mon, May 14, 2001 04:06 To: 'Eli Lopez'; Jay Soffian; toasters(a)mathworks.com Subject: RE: Copy on write - Netapp vs. others Not to nit-pick... but what being described is the behavior of a log-structured file system (of which WAFL is one). There are many other implementations of log-structured file systems. IMO, calling that copy-on-write is dead-wrong, not merely confusing. There's no copy going on. The inode file is copied (checkpointed) when a snapshot is initiated, not when a write occurs. Just my two cents... Paul -----Original Message----- From: Eli Lopez [mailto:elopez@netapp.com] Sent: Sunday, May 13, 2001 4:38 AM To: Jay Soffian; toasters(a)mathworks.com Subject: Re: Copy on write - Netapp vs. others Hi Jay, You are right that the terminology is confusing. One way to look at it is to think of two ways of copy-on-write: when you are updating a block of a file you can: 1) Either write the NEW UPDATED block to a new location 2) Or move the OLD block to a new location AND THEN write the new updated block in place of the old one. Taking a snapshot with both methods involves copying the inode file BUT obviously there could be serious performance impact using the second method (for each update, the write request needs to 'wait' until the old block gets copied to a new location). Network Appliance's WAFL uses the first method which does not have any impact on performance and is (IMVHO) much more elegant. Thanks, Eli ______________________ Eli Lopez Systems Engineer Manager Network Appliance, Israel (+972) - 50 - 304 - 733 Eli.Lopez(a)Netapp.com ______________________ ----- Original Message ----- From: Jay Soffian <jay(a)loudcloud.com> To: <toasters(a)mathworks.com> Sent: Thursday, May 10, 2001 7:00 PM Subject: Re: EMC IP4700 vs NetApp F740 > "Ferd" == Ferd Berfl <ferd_berfl(a)yahoo.com> writes: > > > 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. > > WAFL uses copy-on-write. Here, straight from the horse's mouth: > > WAFL uses a copy-on-write technique to minimize the disk space that > Snapshots consume. > > http://www.netapp.com/tech_library/3002.html > > Now, Netapp's implementation may be unique, but to say that WAFL > doesn't use copy-on-write and to make a claim like "copy-on-write is > slow, Netapp doesn't use it" is bogus. > > j. > -- > Jay Soffian <jay(a)loudcloud.com> System Administrator > 408 744 7584 Loudcloud, Inc.

1 0

RE: Copy on write - Netapp vs. others
by Traitel, Eyal 14 May '01

14 May '01

Paul, I think this is only terminology issue. The word "copy" was probably used as a noun, not a verb, with the meaning that after the write, you have another copy of the same block - well, not exactly the same - one is the old, one is the new. Hence the word copy. On log structured fs - if WAFL was simple and not patented everyone could have just do it like us. This is not the case. Regular log based filesystems have to commit once in a while the log into the original, fixed locations on disk. WAFL does not have this limitation - that's the Anywhere from the word WAFL. 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: Paul Timmins [mailto:paul@ptimmins.com] Sent: Mon, May 14, 2001 04:06 To: 'Eli Lopez'; Jay Soffian; toasters(a)mathworks.com Subject: RE: Copy on write - Netapp vs. others Not to nit-pick... but what being described is the behavior of a log-structured file system (of which WAFL is one). There are many other implementations of log-structured file systems. IMO, calling that copy-on-write is dead-wrong, not merely confusing. There's no copy going on. The inode file is copied (checkpointed) when a snapshot is initiated, not when a write occurs. Just my two cents... Paul -----Original Message----- From: Eli Lopez [mailto:elopez@netapp.com] Sent: Sunday, May 13, 2001 4:38 AM To: Jay Soffian; toasters(a)mathworks.com Subject: Re: Copy on write - Netapp vs. others Hi Jay, You are right that the terminology is confusing. One way to look at it is to think of two ways of copy-on-write: when you are updating a block of a file you can: 1) Either write the NEW UPDATED block to a new location 2) Or move the OLD block to a new location AND THEN write the new updated block in place of the old one. Taking a snapshot with both methods involves copying the inode file BUT obviously there could be serious performance impact using the second method (for each update, the write request needs to 'wait' until the old block gets copied to a new location). Network Appliance's WAFL uses the first method which does not have any impact on performance and is (IMVHO) much more elegant. Thanks, Eli ______________________ Eli Lopez Systems Engineer Manager Network Appliance, Israel (+972) - 50 - 304 - 733 Eli.Lopez(a)Netapp.com ______________________ ----- Original Message ----- From: Jay Soffian <jay(a)loudcloud.com> To: <toasters(a)mathworks.com> Sent: Thursday, May 10, 2001 7:00 PM Subject: Re: EMC IP4700 vs NetApp F740 > "Ferd" == Ferd Berfl <ferd_berfl(a)yahoo.com> writes: > > > 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. > > WAFL uses copy-on-write. Here, straight from the horse's mouth: > > WAFL uses a copy-on-write technique to minimize the disk space that > Snapshots consume. > > http://www.netapp.com/tech_library/3002.html > > Now, Netapp's implementation may be unique, but to say that WAFL > doesn't use copy-on-write and to make a claim like "copy-on-write is > slow, Netapp doesn't use it" is bogus. > > j. > -- > Jay Soffian <jay(a)loudcloud.com> System Administrator > 408 744 7584 Loudcloud, Inc.

1 0

RE: ndmpd errors
by Chitre, Amol 14 May '01

14 May '01

Neil, Very early to determine the exact cause of your problems here. But taking a shot from my previous experiences with Veritas, 99 is generally when the file system path you are trying to backup is not appropriate. Could you check if the path exists or if its a directory? In case this persists, try with a different path and let me know.... Thanks, Amol. >-----Original Message----- >From: Conner, Neil [mailto:neil@mbari.org] >Sent: Thursday, May 10, 2001 3:26 PM >To: Toasters (E-mail) >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

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